1

1.as
Mnogi teoretiari smatraju da je pronalazak raunara jedan od najvrednijih pronalazaka oveanstva
koji je u potpunosti promenio i unapredio ivot oveka. Moe se slobodno rei da gotovo da nema ni
jedne oblasti ljudskog stvaraltva u kojoj raunari nisu uzeli dominantnu ulogu. U takvim okolnostima
pojavili su se vani zahtevi za raunarsku nauku kao i njenu primenu u ljudskom stvaralatvu kao to
su:
Potreba za meusobnom razmenom informacija izmeu raunara.
Zahtev da se smanji cena i vreme razvoja neke aplikacije.
Zahtev da se smanje ukupni trokovi kako razvoja tako i uvoenja i obuke osoblja sa aplikacijom.
Potreba da se pored informacija razmenjuju i aplikativni programi nezavisno od hardvera i lokacije
raunara,
Svi ovi zahtevi, koji su se iskazali jo u ranim sedamdesetim godinama, reavani su dugo tako da
imamo puno razliitih reenja. Meutim sve su to bila parcijalna reenja koja su zadovoljavala zahteve
proizvoaa ali ne i korisnike tih reenja. Naime, u cilju zatite svojih investicija, razvoja i
proizvodnje, proizvoai raunarske opreme dosledno su se drali uvanja industrijske tajne
pokuavajui da na taj nain veu svoje korisnike samo za sebe. Takvi raunarski sistemi, koji su
napravljeni u specifinoj tehnologiji poznatoj samo proizvoau, sa neizbenim sistemskim softverom,
nazivaju se zatvoreni sistemi. Meutim ovakvi sistemi nisu moglu u potpunosti da zadovolje sve vee
i vee zahteve korisnika ovih sistema, tako da su vremenom obe strane i korisnici i dobavljai postajali
sve nezadovoljniji. Naime,sve vei zahtevi korisnika postajali su sve vei teret dobavljaa/proizvoaa
ove opreme, koji je sada, da bi zadovoljio zahteve, morao da sve vie ulae u razvoj novih tehnologija.
Sve te investicije nisu uvek donele i profit novog proizvoda, tako da su mnogi dobavljai poeli da
posluju sa gubitcima. Pored toga primena novih proizvoda i reenja, zahtevali su i odreeni vremenski
period za razvoj, testiranje i proizvodnju konanog proizvoda. Za sve to vreme korisnici su stalno
gunali traei da dobiju proizvod koji su papreno platili. U takvoj situaciji dobavljai su esto
isporuivali nedovoljno zavrene i testirane proizvode koji su jo vie izazivali nezadovoljstvo
korisnika. Sa druge strane korisnici, da bi mogli da ostvare profit, morali su da prate nove tehnologije i
da stalno ulau u nove proizvode koji nisu adekvatno zadovoljavali njihove zahteve kako po ceni i
vremenu, tako i po kvalitetu pouzdanosti i njihovog rada.
Do pojave otvorenih sistema raunarska industrija je bila vie zavisna od sopstvene tehnologije, nego
od zahteva trita. Vaila su dva osnovna principa i to: ljubomornog uvanja sopstvenog proizvoda i
prodaje na nain imam proizvod-treba ga prodati. Na slici broj 1. prikazani su marketinki porivi
koji su doveli do promene strategije u proizvodnji raunarskih sistema i velikog ulaska otvorene
strategije.
OTVORENI
SISTEMI
ZATVORENI
SISTEMI
Specijalni
korisnici
Istraivanje
Razvoj
Proizvoai
softvera
Proizvoai
hardvera
Proizvo
VAR
a

i
ure aja
Komercijalni
korisnici

Slika broj 1.
2
Danas je savim jasno da raunarska industrija mora pronai nain da se razvoj i upotreba
informacionih tehnologija mora odvijati potpuno sinhronizovano. Jedini nain da se to uradi je
uvoenje i primena meunarodnih standarda za informacione tehnologije koje e tano definisati
potrebe i zahteve trita, a koje trebaju da zadovolje svi budui proizvodi. U tom smislu potrebno je
jasno definisati tri osnovne karakteristike otvorenih sistema:
1. Portabilnost predstavalja prenosivost aplikativnog softvera izmeu razliitih raunara bez
dodatnih zahteva na menjanju izvornog koda.
2. Skalabilnost - zahteva da se aplikacije mogu izvravati na razliitim generacijama raunara, tj.
drugim rima aplikacija koja radi na PC 386 raunarima mora da radi i na Pentium IV raunarima.
3. Interoperabilnost omoguuje da postoji veza izmedju novih i starih tehnologija, tj. Nove
tehnologije mogu se instalirati i na starim reenjima bez nekog dodatnog ulaganja i promene cele
infrastrukture. Takoe, ona podrazumeva da raunari razliitih proizvoaa koji imaju razliiti
hardver i sistemski softver, mogu nesmetano da komuniciraju bez obzira na njihovu udaljenost i
raunarsku snagu.
Kada neki sistem zadovoljava ove tri nabrojane karakteristike: portabilnost, skalabilnost i
interoperabilnost, kao i kada postoje unapred doneti otvoreni meunarodni standardi, u kojima svako
zainteresovan moe da uestvuje, kao i kada su ti rezultati svima dostupni,kaemo da se radi o
komponenti otvorenog sistema. Skup vie ovakvih komonenti ini otvoreni sistem.

Kada razgovaramo o prednosti otvorenih sistema nad zatvorenim potrebno je da razmotrimo:
1. Performanse jasno je da su otvoreni sistemi sporiji ali su zato prilagodljiviji i gledano dugorono
mnogo isplativiji
2. Cena zbog vee konkurencije jasno je da je cena otvorenih sistema manja ali treba imati u vidu i
cenu prelaska sa zatvorenih na otvorene sisteme. Gledano dugorono i tu su u prednosti otvoreni
sistemi.
3. Izbor sve je vei broj kupaca koji znaju ta hoe da kupe pa je prema tome vei izbor, koji je
prisutan kod otvorenih sistema jedna velika prednost.
4. Progres kod otvorenih isstema to je uvek otvoren proces jer se oni stalno razvijaju i dopunjuju .
5. Prelazak jasno je da se cena prelaska sa zatvorenih na otvorene sisteme jednom mora platiti ali
kao to je ranije reeno dugorono se to isplati.
6. Sigurnost ovo je jedini faktor koji je diskutabilan jer kod otvorenih sistema je svakom sve
dostupno tj. sve se moe pronai u literaturi. Kako uvek ima ljudi koji ele da nakode drugima,
bilo da pokvare ili ukradu, ovo je jedini parametar koji ide u prilog zatvorenih sistema.


3
2 as Proces standardizacije
Danas u svetu postoje mnoge organizacije koje imaju vaan uticaj na razvoj standarda i u principu
mogu se podeliti na tri grupe: javne, korisnke i industrijske.
Kada se govori o standardima onda treba rei da postoje dve vrste standarda i to : de facro i de jure
koji predstavljaju latinske izraze za u stvarnosti i po zakonu, respektivno. De jure standardi su
javni standardi koji su stalno podloni otvorenom procesu u kome svako moe da uestvuje i iji su
rezultati svima dostupni. Ovakav standard se usvaja tek kada se o svim pitanjima dogovore svi
zainteresovani tj. kada se postigne konsenzus po svim pitanjima. De facto standardi su ustvari
standardi koje su propisali veliki proizvoai koji su svojom dominantnom ulogom na tritu uspeli da
nametnu svoje proizvode a samim tim i postave standarde za njih ( IBM PC, Intel x86, AT&T, UNIX i
td.) Moe se desiti da de facto standardi preu u javne standarde usled jakog pritiska trita da se to
uradi ( primer UNIX-a).
Na formiranje standarda puno puta pored strunih motiva utiu i neke drugi interesi, pre svega trini.
Ba zbog toga javne standarde moemo podeliti na minimalne, kompromisne i maksimalne.
Minimalni standard je standard koji obuhvata samo one osobine proizvoda o kojima se uesnici mogu
lako dogovoriti. On se javlja kao posledica postojanja vie dobrih proizvoda na tritu koji imaju dosta
istih ili slinih osobina. Meutim, izmeu tih proizvoda postoje i velike razlike koje se prevazilaze
velikom eljom da se i pored tih razlika doe do nekog opte prihvaenog javnog standarda. Ovakav
standard je za trite najloije reenje pa se ovakvi minimalni standardi prihvataju kao prelazno reenje
do zavretka kompletnog otvorenog procesa. Druga krajnost je maksimalni standard koji daje mnogo
bolji rezultat ali je kod njega problem to za nastajanje ovakvog standarda treba dui vremenski period
kao i vee promene na proizvodima koji se ve nalaze na tritu. Iz svega ovog dolazi se do
kompromisnog standarda koji su i najprisutniji na tritu.
Sve organizacije koje se bave izdavanjem javnih standarda upuene su jedne na druge tj. potrebna je
velika saradnja izmeu njih kako bi se izbeglo donoenje standarda koji bi se meusobno preklapali.
Na taj nain izbegava se mogunost pojavljivanja vie standarda koji bi definisali isti problem a na
razliite naine. Osnovno pravilo koje ovde vai je da se nikad ne definie neto zato ve postoji
standard ili definicija.
Donoenje nekog otvorenog standarda sastoji se iz nekoliko koraka i to:
1. RFT - izdavanja zahteva za standadizaciju novog proizvoda ili tehnologije: zahtev za novi
standard
2. DP - komentarisanja predloenog standadrda: izdavanje privremenog predloga,
3. DIS - izdavanja specifikacije: izdavanje privremenog standarda
4. IS i na kraju usaglaavnja svih pristiglih predloga: izdavanje pravog internacionalnog
standarda
ORGANIZACIJA
(OSF)
ZAINTERESOVANI
ZAINTERESOVANI
IS DIS DP
RFT
(Request for
technology)
Draft
Proposal
Draft
International
Standard
International
Standard
1
2 3 4

Slika broj 2. Proces donoenja standarda


4
Konceptualni model raunarskog sistema
Ovaj model podeljen je na 7 nivoa i to:
7. Korisniki interfejs
6. Aplikacija
5. Programski jezici
4. Softverski alati
3. Operativni sistem
2. Hardverske komonente
1. Mikroprocesor
Zajedniko aplikaciono okruenje
Potreba za skupom standarda koji e obezbediti potrebne osobine otvorenih sistema prirodno vodi ka
standardizaciji i okruenja u kojem se oekuje da e aplikacija biti razvijana i u kojem e raditi. Zato je
i X/Open konzorcijum zaduen da definie i razvije zajedniko aplikaciono okruenje CAE ( Common
Application Environment). Njegov cilj je da obezbedi portabilnost aplikacionog softvera definisanjem
tri osnovna principa koji se odnose na: zajedniki korisniki interfejs, zajedniki programerski interfejs
i zajedniki model za komunikacije. To podrazumeva jedinstveni pristup u komunikaciji izmeu
raunara i oveka, jedinstvenu sintaksu kod glavnih programskih jezika i omoguavanje svim
korisnicima da mogu da komuniciraju putem mree bez obzira na vrstu opreme kojom raspolau.
Kopletna definicija zajednikog aplikacionog okruenja je dosta velika i neiscrpna kategorija tako da
se ona stalno dopunjuje i proirava. Sve te definicije smetene su u seriju knjiga koje pojedinano
opisuju svaki standard i koje su poznate pod imenom X/Open Portability Guide (XPG). U njima se
definiu mnogi standardi koji se mogu razvrstati na sedea podruja:
- strategija prelaska na otvorene sisteme,
- operativni sistemi,
- upravljanje podacima,
- alati za razvoj aplikacija,
- programski jezici,
- internacionalizacija,
- mree i komunikacija,
- sigurnost i administracija sistema,
- interfejs izmeu oveka i raunara.

Moe se slobodno konstantovati da samo oni aplikacioni programeri koji se pridravaju svih ovih
standarda i preporuka mogu raunati na aplikaciju koja e biti ope prihvaena.

Raunarske mree
Raunarska mrea predstavlja jedan komunikacioni sistem preko koga se vri razmena informacija
izmeu vie korisnika na manjim ili veim rastojanjima. Jednu mreu moemo da posmatramo kroz
vie aspekata i to: njenu topologiju, protokoli za komunikaciju, elektrini interfejsi, tip modulacije i tip
noseeg signala, medujuma za prenos informacije i td.
Topologija mree predstavlja nain na koji su povezani korisnici i mrei. Najire mrene topologije su
: zvezda, magistrala i prsten (star, bus i ring)
Prenosni mediji(kanali) razlikuju se po irini pojasa, brzini prenosa i kapacitetu kanala. Sirina
pojasa(bandwith) je elektrina karakteristika kojom se definie opseg izmeu najnie i najvie
frekfencije unutar kojega signal moe de pree prenosni put bez izoblienja. Brzina prenosa (baud
rate) definie broj promena elemenata ili stanja signala u jedinici vremena a kapacitet kanala je
maksimalna brzina koju prenosni put moe da izdri a da se ne generie greka u prenosu.
Tehnike prenosa dele se na analogne ( koriste se digitalni signali za modulisanje noseeg signala
upotrebom aplitudne, fazne ili frekventne modulacije) i digitalna metoda prenosa gde se podrazumeva
prenos digitalnog signala na njegovoj osnovnoj frekvenciji bez modulacije.
Protokoli predstavljaju skupove sintaksniih i semantikih pravila kojima se odruje ponaanja
funkcionalnih jedinica prilikom odvijanja komunikacija. Njima se definie kako se neka informacija
5
isporuuje, kako se pakuje da sigurno doe do odredita , kojim putem da ide, kako se proveravaju i
otklanjaju greke u informacijama i td.
Pod adresom se u komunikacijama podrazumevaju nain kako predajni ili kontrolni vor bira vor
kome e poslati poruku. Adresa nije nita drugo ve identifikacija prijemne strane. Postoje logike i
fizike adrese. Fizika adresa je jedinstvena adresa koja se pridruuje uz svaki ureaj koji je vezan na
mreu. Uz adrese je usko vezan i pojam domena koji predstavlja skup poetnih adresa odreenih grupa
u nekoj veoj mrei.
Repeater(pojaalo)- vri regeneraciju signala na fizikom i link nivou i prosleuje ga dalej kroz
prenosni sistem.
Bridge(most)-razreava nekompatibilnost izmeu dve mree na niem nivou komunikacije na nivou
mrenog protokola.
Router(odailja)- slui da prevazie nekompatibilnost na nivou transportnog protokola.
Gateway- slui da povee dvr potpuno razliite mree kada su razlike prisutne i na gornjim nivoima
komunikacija to se javlja kada se lokalne mree povezuju u WAN.

Mreni hardver
Mree se prave i od hardvera i od softvera. Mreni hardver obezbedjuje fizike veze izmedju razliitih
vorova u mrei i tipino obuhvata:
Mrene kartice za spregu (NIC - Network Interface Cards), po jednu za svaki PC raunar;
Mredni uredjaje, kao to su vorita, mostovi, usmerivai i komutatori, koji su svi zajedno odgovorni za
povezivanje razliitih segmenata mree i za osiguravanje da se paketi informacija poalju na eljeno
odredite;
Mreni kablovi (oklopljeni bakarni provodnici slini telefonskim kablovima) koji povezuju svaku mrenu
karticu za spregu sa voritem ili prekidaem.
Mrene kartice za spreku (NIC)
Mrene kartice za spregu, koje se obino oznaavaju kao NIC, koriste se da poveu PC raunare sa
mreom. NIC obezbedjuje fiziku vezu izmedju mrenog medijuma i unutranje magistrale raunara, i
odgovorna je za omoguavanje "pristupnog metoda" mrei (to su OSI slojevi 1 i 2).
Veina mrenih kartica za spregu su projektovane za odredjeni tip mree, protokola i medijuma, mada neke
od njih mogu da opslue vie mrea. Kartice su raspoloive da podre gotovo sve mrene standarde,
ukljkuujui tu i najnovije okruenje Fast Ethernet. Mrene kartice za Fast Ethernet su esto u stanju da
podravaju 10/100 Megabita u sekundi i postavie se automatski odgovarajuu brzinu. Druga opcija je
puno dupleksno umreavanje, gde posebna veza do prekidaa omoguava da NIC radi dvostrukom
brzinom.
vorita/repetitori
vorita/repetitori se koriste da medjusobno poveu dva ili vie segmenata mree bilo koje vrste medijuma.
U veim konstrukcijama, kvalitet signala poinje da se pogorava kada segmenti predju neku maksimalnu
duinu. vorita obezbedjuju pojaanje signala koje je potrebno da bi se segment produio na veu
razdaljinu. Pasivna vorita jednostavno usmeravaju pakete podataka koje primaju preko porta od jedne
radne stanice na sve svoje preostale portove. Aktivna vorita, koja se ponekad takodje nazivaju i
"repetitori sa vie portova", regeneriu bitove podataka da bi odrala jak signal.
vorita se takodje koriste u topologijama zvezde kao to je mrea 10BaseT. vorite sa vie portova za
upredene parice dozvoljava da se vie segmenata taka-na-taku zdrui u jednu mreu. Jedan kraj linka
taka-na-taku je prikljuen na vorite, a drugi na raunar. Ako je vorite prikljueno na "kimu", tada
svi raunari na kraju segmenata upredenih parica mogu da komuniciraju sa svim matinim raunarima na
"kimi".
Vana injenica koju treba zapaziti o voritima je da ona samo dozvoljavaju korisnicima da dele Ethernet.
Mrea vorita/repetitora se naziva "deljeni Ethernet", to znai da se svi uesnici u mrei takmie za
prenos podataka na jednoj mrei (domen sukoba). Drugim reima, individualni uesnici na deljenoj mrei
e dobiti samo izvestan procent raspoloivog mrenog propusnog opsega. Broj i vrsta vorita u bilo kom
domenu sukoba za mreu 10BaseT Ethernet ogranieni su prema sledeim pravilima:

Tip mree Maksimalni broj Maksimalno
6
vorova
po segmentu
rastojanje
po segmentu
10BaseT 2 100m
10Base2 30 185m
10Base5 100 500m
10BaseFL 2 2000m

Dok repetitori dozvoljavaju lokalnim raunarskim mreama da se produe dalje od normalnih granica
rastojanja, oni ipak ograniavaju broj vorova koji mogu da se podre. Medjutim, mostovi, usmerivai i
prekidai dozvoljavaju lokalnim raunarski mreama da znaajno porastu zbog njihove sposobnosti da
podre potpune Ethernet segmente na svakom portu.
Mostovi
Mostovi su postali komercijalno raspoloivi u ranim 1980-im godinama. U vreme njihovog uvodjenja,
njihova funkcija je bila da poveu razdvojene homogene mree. Kasnije je premoivanje razliitih mrea -
na primer, Ethernet i Token Ring - takodje definisano i standardizovano. Mostovi su uredjaji za
komunikacije podataka koji u principu rade na Sloju 2 OSI referentnog modela. Kao takvi, oni se esto
nazivaju uredjajima za sloj linka podataka.
Mostovi preslikavaju Ethernet adrese vorova koji su na svakom segmentu mree i doz-voljavaju da samo
neophodan saobraaj prodje preko mosta. Kada most primi paket, on odredjuje segmente njegovog izvora i
odredita. Ako su ti segmenti isti, paket se isputa ("filtrira"); ako su segmenti razliiti, paket se sumerava
na ispravan segment. Pored toga, mostovi ne usmeravaju oteene pakete.
Mostovi se takodje nazivaju uredjajima za "memorisanje i prosledjivanje", jer oni pregledaju ceo Erthernet
paket pre nego to naprave odluke o filtriranju ili prosledjivanju. Filtriranje paketa i njihovo regenerisanje
omoguava tehnologiji premoavanja da podeli mreu u odvojene domene sukoba. To dozvoljava da se u
ukupnom projektu mree koriste vea rastojanja i vie repetitora.
Veina mostova su uredjaji sa samoobuavanjem; oni utvrdjuju korisnike Ethernet adrese na segmentu
izradjujui tabelu dok paketi prolaze kroz mreu. Ova sposobnost samoobuavanja, medjutim, dramatino
poveava mogunost pojave mrenih petlji u mreama koje imaju mnogo mostova. Petlja predstavlja
konfliktnu informaciju o tome na kom segmentu je smetena odredjena adresa i prisiljava uredjaj da
prosledi sav saobraaj.
Do sredine 1990-ih godina, komutaciona tehnologija kao evolucioni naslednik reenja sprezanja vie mrea
zasnovanih na mostovima. Bolja performansa po propusnoj moi, vea gustina portova, nia cena po portu
i vea fleksibilnost doprinele su pojavi komutatora kao tehnologije koja e zameniti mostove i biti
komplement tehnologiji usmeravanja.
Usmerivai
Usmeravanje je dostiglo komercijalnu popularnost sredinom 1980-ih godina - u vreme kada je sprezanje
mrea velikog obima poelo da zamenjuje dosta jednostavna, homogena okruenja koja su do tada bila
obrazac. Usmeravanje je in pomeranja informacija preko mrea, od izvora do odredita. Ono se esto
poredi sa premoavanjem, koje izvrava slinu funkciju. Glavna razlika izmedju ove dve tehnologije je u
tome to se premoavanje pojavljuje na Sloju 2 (sloj linka podataka) OSI referentnog modela, dok se
usmeravanje pojavljuje na Sloju 3 (mreni sloj). Ova razlika daje usmeravanju i premoivanju razliite
informacije koje oni koriste u procesu pomeranja informacija od izvora do odredita, tako da te dve
funkcije ispunja-vaju svoje zadatke na razliite naine.
Usmerivai koriste informacije unutar svakog paketa da bi ga usmerili iz jedne lokalne raunarske mree u
drugu i da komuniciraju medjusobno i dele informacije koje im dozvoljavaju da odrede najbolju putanju
kroz sloenu mreu od mnogo lokalnih raunarskih mrea. Da bi to izveli, usmerivai rade i odravaju
"ujsmerivake tabele", koje sadre razliite delove informacija o putanjama - zavisno od upotrebljenog
algoritma za usmeravanje. Na primer, pridruivanje odredita sledeem skoku kae usmerivau da dato
odredite moe optimalno da se dostigne ako se paket poalje odredjenom usmerivau koji predstavlja
"sledei skok" na putu ka konanom odreditu. Kada usmeriva primi dolazni paket, on proverava adresu
odredita i pokuava da pridrui tu adresu sledeem skoku.
Komutatori
Komutatori lokalne raunarske mree su proirenje koncepta premoivanja. Oni rade na Sloju 2 (sloj linka
podataka) OSI referentnog modela, koji upravlja tokom podataka, opsluuje greke u prenosu, obezbedjuje
7
fiziko (nasuprot logikom) adresiranje i upravlja pristupom fizikom medijumu. Komutatori obezbedjuju
ove funkcije koristei razliite protokole sloja linka - kao to su Ethernet, Token Ring i FFDI - koji
diktiraju specifine algoritme za upravljanje tokom, opsluivanje greaka, adresiranje i pristup medijumu.
Komutatori lokalnih raunarskih mrea mogu medjusobno da poveu etiri, est, deset ili vie mrea i
imaju dve osnovne arhitekture: prosecanje i memorisanje i prosledjivanje. U prolosti, komutatori za
prosecanje su bili bri, jer su ispitivali adresu odredita paketa samo pre njegovog prosledjivanja na njegov
odredini segment. Komutator sa memorisanjem i prosledjivanjem, sa druge strane, prihvata i analizira ceo
paket pre njegovog prosledjivanja ka odreditu.
Potrebno je vie vremena da se ispita ceo paket, ali to dozvoljava komutatoru da uhvati neke greke u
paketu izadri ga od daljeg prostiranja kroz mreu. Do poznih 1990-ih godina, brzina komutatora sa
memorisanjem i prosledjivanjem je uhvatila korak sa komutatorima za prosecanje, tako da je razlika
izmedju njih postala minimalna. Do tada se pojavio veliki broj hibridnih komutatora koji su davali
meavinu obe ove funkcije.
Primopredajnici
Primopredajnici se koriste za povezivanje vorova na razliite Ethernet medijume. Veina raunara i
mrenih kartica za spregu sadri ugradjeni primopredajnik za 10BaseT ili 10Base2, dozvoljavajui im da se
direktno poveu na Ethernet vez potrebe za spoljanjim primopredajnikom. Mnogi Ethernet uredjaji imaju
AUI konektor koji dozvoljava korisniku da ih povee na bilo koji medijum preko spoljanjeg
primopredajnika. AUI konektor se sastoji od 15-pinskog konektora, od koga je enski deo na strani
raunara, a muki na strani primopredajnika. Kablovi (10BASE5) takodje koriste primopredajnike za
povezivanje.
Za mree Fast Ethernet, razvijena je nova sprega zvana MII (Media Independent Interface - sprega
nezavisna od medijuma) koja nudi fleksibilan nain za podravanje veza brzine od 100 Megabita u
sekundi. MII je popularan nain da se poveu linkovi 100Base-FX sa uredjajima za Fast Ethernet
zasnovanim na bakarnim provodnicima.
Kablovi
Udruenje za industruju raunarskih komunikacija (CCIA) je 1985. godine zatrailo da Udruenje za
elektronsku industriju (EIA) razvije generiki kablovski standard za komercijalne zgrade koji bi bio u
stanju da prenosi sve tadanje i budue mrene sisteme preko zajednike topologije, koristei zajedniki
medijum i zajednike konektore.
Do 1987. godine vie proizvodjaa je razvilo opremu za Ethernet koja bi mogla da koristi telefonski kabl
od upredene parice, a 1990. godine je uveden standard 802.3I Ethernet 10BaseT (gde se "T" odnosi na kabl
od upredene parice). EIA je zajedno sa Udruenjem za industriju telekomunikacija (TIA) 1991. godine
konano objavila prvi standard za kablovske telekomunikacije nazvan EIA/TIA 568, ime je rodjen
strukturni kablovski sistem. On je bio zasnovan na Neoklopljenom kablu sa upredenim paricama
Kategorije 3 (UTP), a uskoro, posle mesec dana, pojavile su se specifikacije UTP vieg stepena, Kategorija
4 i 5.
Sledea tabela prikazuje razliite vrste UTP kablova koji se najvie koriste krajem 2000. godine:
Tip Karakteristike
Kategorija 1
Koristi se za telefonske komunikacije i nije pogodan za
prenos podataka
Kategorija 2
Moe da prenosi podatke brzinama do 1 Megabita u
sekundi
Kategorija 3
Koristi se u mreama 10BaseT i moe da prenosi
podatke brzinama do 16 Megabita u sekundi
Kategorija 4
Koristi se u prstenastim mreama asa etonom i moe da
prenosi podatke brzinama do 20 Megabita u sekundi
Kategorija 5
Moe da prenosi podatke brzinama do100 Megabita u
sekundi





8
as 3 TOPOLOGIJE LOKALNE MREE
Poslednjih 30-tak godina razvijeno je vie originalnih mrenih topologija koje su sve zavisile od
razliitih kriterijuma i zahteva koje su trebale da zadovolje. Pre razmatranja samih toplogija
potrebno je razjasniti dva pojma koja su vezana za topologiju mrea i to:
1. fizika topologija(physical topology ) koja podrazumeva raspored medijuma same mree tj.
fizikih vodova (bakarni ili optiki kablovi) i ureaja u samoj mrei.
2. logika topologija ( logical topology) koja podrazumeva logike puteve u samoj mrei kojima
se stvarno podaci kreu.
U veini savremenih lokalnih mrea koriste se sledee osnovne topologije:
1. topologija magistrale (bus topology)
2. topologija zvezde (star topology)
3. topologija prstena (ring topology)
4. topologija u obliku mree (mesh topology)
5. meovita topologija (hybrid topology)
Topologija magistrale
Jednostavna struktura magistrale bila je prva toplogija koja se koristila u Ethernet mreama. Ona se
sastoji od koaksijalnog kabla koji meusobno povezuje sve raunarske komponente koje se nalaze u
lokalnoj mrei. Koaksijalni kabli ima vie prikljuaka i svaki od njih se koristi kao taka povezivanja
raunarskog sistema. Prikljuci mogu biti direktno spojeni centralni provodnici koaksijalnih kablova ili
BNC rave (T konektori). Kod ovakve realizacije logika i fizika topologija se poklapaju. Poto se
ovde radi o tehnologiji zajednikog medijuma, javlja se potreba za postojanjem mehanizama koji e
regulisati saobraaj na tom mediju. Zato se ovde definiu dva pojma koja su vrlo bitna za odvijanje
saobraaja tj. razmene podataka izmeu ureaja na mrei i to su:
- algoritam za izbegavanje kolizije (collision avoidance) ili algoritam za detektovanje kolizije
(collision detection ).
- pojam emisije (broadcast ) koji definie jainu signala kako bi podaci nesmetano mogli da
dou do svakog ureaja na mrei
Toplogija magistrale se vrlo jednostavno realizuje i ona predstavlja dosta jevtino reenje jer su
trokovi istaliranja kablova niski. Ba iz tog razloga ona ima i neke nedostatke koji dosta ograniavaju
primenu ovakve topologije u lokalnim mreama:
- zahteva odgovarajue zavretke (terminatore) na svakom kraju magistrale kako bi se efikasno
priguili signali i spreila njihova refleksija ili ponovna pojava prethodnog prenosa. Ukoliko su
oni neodgovarajui ili ukoliko ih nema tada e saobraaj na mrei biti vrlo spor ili ga uopte
nee biti.
- sam kabli je izvor otkaza. Njegovo oteenje ili prekid imaju negativan uticaj na celu mreu.
- instalacija novi stanica na mrei zahteva privremeni prekid na mrei.
- bilo kakav problem na mrei se teko detektuje a samim tim i brzo otklanja, a sve to zahteva
prekid na mrei.
Zbog svih ovih nedostataka i ogranienja, topologija magistrale se obino primenjuje u najmanjim ili
najjednostavnijim instalacijama lokalnih mrea.
Topologija zvezde
Kod ove topologije svaki vor lokalne mree povezan je posebnim kablom sa centralnim mestom, koje
je obino razvodni orman. Svi kablovi ulaze u jednu mrenu komponentu poznatu kao hab (hub) ili
komutator (switch). Osnovna uloga ovog ureaja je da ponavlja ili komutira saobraaj ka ostalim
vorovima mree.
Ovde su oigledni nedostaci ovakve topologije: sama mrena komponenta je izvor otkaza a i zahteva
se obimno kabliranje koje nije tako jevtino.
Meutim ovakva topologija ima i velike prednosti u odnosu na topologiju magistrale koje se ogledaju
u sledeem:
- upravljanje mreom je skoncetrisano oko habova i komutatora. Veina ovih komponenti
poseduju svoju inteligenciju koja omoguava administratorima da vre nadgledanje protoka
9
saobraaja kroz ove ureaja a samim tim omoguavaju da se tano odrede mesta zaguenja i
greke u radu mree ve na nivou portova, a to znai brzo i efikasno otklanjanje problema.
- Inteligentni ureaji omoguavaju da se automatski onemogue portovi koji premauju pragove
upotrebe ili greke ime se dodatno poveava stabilnost mree.
- kablovska instalacija ima manji uticaj i ne remeti servise lokalne mree kada se dodaju ili
uklanjaju vorovi.
- prekid kabla ili neispravan konektor eliminie samo jedan vor ili segment a ne sve
komponente u lokalnoj mrei.
- elektrini zavretci ovde nisu ptrebni.
Danas je ovakva topologija najrasprostranjenija u gotovo svim fizikim realizacijama mrea.
Topologija prstena
Topologije prstena su neto sloenije za izvoenje u odnosu na topologije zvezde i topologije
magistrale. Ovde vorovi logiki komuniciraju u formaciji prstena ali se zato fizika realizacija
najee sprovodi u vidu zvezde. Ovde svaki vor komunicira samo sa neposrednim susedima
dolaznim i odlaznim. U ovoj topologiji kontrola pristupa vri se pomou tokena koji se prosleuje od
vora do vora i koji slui kao mehanizam arbitrae. Svaki vor eka svoj red da zatrai korienje
tokena koji se prosleuje od vora do vora dok ne stigne do odredinog vora. Kada ga ovaj primi, on
ga modifikuje kako bi potvrdio da ga je primio i prosledi ga dalje. Na kraju vor poiljalac prima paket
koji je obiao ceo krug, prima potvrdu da je podatak koji je on poslao primljen i ako je sve u redu
oslobaa token za prihvatanje i transport novog podatka.
Prednosti ove topologije su odmah vidljive:
- pristup kontrolisanim tokenom nudi iri koristan propusni opseg jer nema potrebe za
korienjem algoritma za detekciju ili izbegavanje kolizije.
- prenos paketa obavlja se u utvrenimvremenskim intervalima tako da svaki vor lako moe da
utvrdi potrebno vreme za prenos sledeeg podatka. Ovaj kvalitet prenosa je vrlo bitan u
proizvodnim okruenjima gde je vremenski raspored najvaniji.
- lako detektovanje greke u prenosu jer svaki vor preoznaje koji mu je dolazni a koji odlazni
vor.
Ovakva topologija iskoriena je kod FDDI (Fiber Distributed Data Interface) optiki prenos
podataka. Ovde se koriste udvojeni prstenovi gde su smerovi prosleivanja tokena meusobno
suprotni. Na taj nain dobija se komunikacija koja je otporna na greke.
Jedan od najveih nedostataka ove topologije je mala brzina zbog firmvera koji je neophodan kod
svake mrene kartice a koji nam upravlja prenosom tokena.
Topologija mree
Ova topologija podrazumeva preplitanje vie veza izmeu vorova. Osnovna zamisao je da se
obezbede vie puteva izmeu vorova mree kako bi se postigla vea pouzdanost i otpornost na
greke. Ovde razlikujemo potpune (full) i delimine (partial) mree. Potpuna mrea nije praktina jer
zahteva da svi vorovi na mrei budu vezani sa svakim vorom to u mnogome komlikuje kabliranje.
Trokovi kabliranja su veliki a negde oko 90 % svih fizikih puteva nikada nee biti korieni.
Delimina mrea je projektovana da obezbedi udvajanje samo onde gde je to neophodno. Na
projektantu sistema je da predvidi dodatno povezivanmje koje bi obezbedilo potreban propusni opseg i
otpornost na greke.
Meovita topologija
Povezivanjem mrenih ureaja habova i komutatora i korienjem svih do sada pomenutih topologija
dobile su se meovite topologije od kojih su najpoznatije: stablo, hijerahijska zvezda i beina zvezda.
Stablo predstavlja kombinovanu topologiju koja grupie radne stanice u zvezdu a te zvezde su
meusobno povezane sa linearnom magistralom.Glavni problem magistrale ovde je ukonjen jer radna
stanica ne moe da zaustavi saobraaj na celoj lokalnoj mrei. Radne stanice mogu da meusobno
komuniciraju ak i u sluaju da doe do prekida glavne magistrale. Danas se za sprovoenje ovakve
topologije koriste i razliiti fiziki mediji pa se tako za kabliranje magistrale koriste optiki kablovi a
za kabliranje zvezde UTP kablovi.
10
Hijerarhijska zvezda povezuje vie habova sa prikljuenim stanicama pomou centralnog haba.
Sinhronizovanje i adresni prostor su odluujui faktori o broju habova koji se povezuju u ovakvoj vrsti
topologije.
Usred napredtka tehnologije beinog prenosa pojavila se nova hibridna topologija beine lokalne
mree gde su stanice povezane u topologiji zvezde. Pristupne take (acess point) povezane su zvezdu a
sve radne stanice koje ele da komuniciraju moraju biti u blizini tih pristupnih taaka.

Vrste kablova
1. Koaksijalni BNC predstavlja kabli koji se sastoji od centralno postavljenog provodnika koji
je smeten u izolacioni materijal preko koga se nalazi metalni oklop. Kako ovaj kabli zadrava
sva elektomagnetna polja unmutar sebe potrebno je da se spoljni oklop uzemlji kako bi se
spreile smetnje u prenosu podataka. Koriste se dva tipa kabla i to tanki (thinnet)-10BASE-2 i
debeli (thicknet) kablovi-10BASE-5. Max. brzina do 10 Mbyte.
2. UTP (Unshielded Twisted Pair) telefonski kabl, upredena parica koja smanjuje kapacitivnost
izmeu ica i eliminie presluavanje izmeu njih. Veina kablova koje se koriste u lokalnim
mreama ima etri para provodnika. Taj kabli je postao standard i oznaava se sa EIA/TIA-
568B standard kabliranja. Max. brzine 100Mbyte-1Gbyte. Kategorija 5 do 100MHz, kategorija
6 do 250 MHz i kategorija 7 do 600 MHz.
3. Optiki kablovi su u mnogome razlikuju od bakarnih kablova jer se za prenos podataka koristi
tehnika svetlosti koja se prenosi kroz vlakna koja su debljine dlake. Optiki kablovi
omoguavaju ire propusne opsege i manje gubitke signala to nam omoguava prenose
podataka na razdaljinama od preko 2000m (kod bakarnih vodova to je bilo max.100m. Takoe
se postiu i znatno vee brzine prenos podataka koje se kreu preko 1Gbyte. Najvei
nedostatak bakarnih vodova je u tome da se sa poveanjem uestanosti signala poveavaju i
gubitci pa je tako gubitak na 100MHz mnogo vei nego na 10MHz. to kod optikih kablova to
ne postoji. Optiki kabli je i laki od bakarnog i to 25% do 50%.
4. Beine komunikacije oko 40Mbyte.



Mrea ravnopravnih raunara
U mrenoj arhitekturi ravnopravnih raunara (peer-to-peer, ili P2P), svaki raunar (radna stanica) ima
podjednake mogunosti i odgovornosti. Nema servera, a raunari su jednostavno povezani medjusobno u
radnoj grupi, da bi delili datoteke, tampae i pristup Internetu. To je praktino za radne grupe od dvanaest
raunara ili manje, to je esto u mnogim SOHO okruenjima, gde svaki PC raunar radi kao nezavisna
radna stanica koja pamti podatgke na svom sopstvenom vrstom disku, ali moe i da ih deli sa svim drugim
PC raunarima u mrei.
Softver za mree ravnopravnih raunara je ukljuen uveini modernih operativnih sistema za stone
raunare, kao to su Windows i Mac OS, bez potrebe da se kupuje specijalni "mreni" softver.
Klijent-server
Arhitekture mrea tipa klijent-server postale su popularne krajem 1980-ih i poetkom 1990-ih godina,
kakda su mnoge aplikacije prele sa centralizovanih miniraunara i velikih centralnih raunara na mree
personalnih raunara. Projektovanje aplikacija za distribuirano raunarsko okruenje zahtevalo je da one
budu podeljene na dva dela: klijenta (prednji kraj) i servera (zadnji kraj). Arhitektura mree na kojoj su one
bile implementirane odslikavala je ovaj model klijent-servera pomou korisnikovog PC raunara (klijenta)
koji se tipino ponaao kao maina koja postavlja zahteve i monije serverske maine - na koju je klijent
bio povezan preko lokalne ili regionalne raunarske mree - koja se ponaala kao maina koja obezbedjuje
traenu uslugu.
Njihova unutranja skalabilnost ini klijent-server mree pogodnim za poslovanje srednjeg i velikog obima,
gde se serveri po kapacitetu rangiraju u opsegu od vrhunskih PC raunara do velikih centralnih raunara,
ve prema potrebi. Klijent-server mree zahtevaju pored normalnog operativnog sistema i dodatni softver
posebnog Mrenog operativnog sistema (NOS - Network Operating System).
11
P2P raunarstvo
Do poetka 2000. godine dogodila se revolucija u potpuno novom obliku raunarstva izmedju
ravnopravnih raunara P2P (peer-to-peer). Osvetljeno izuzetnim uspehom velikog broja veoma dobro
reklamiranih aplikacija "P2P raunarstvo" - kako se ovaj novi pristup obino naziva - najavilo je novi
model raunarstva za doba Interneta i postiglo je, u kratkom vremenuu, znaajno privlaenje korisnika
velikih centralizovanih raunara i pripadnika industrije PC raunara:
Aplikacija Napster MP3 za deljenje muzikih datoteka je oivela u septembru 1999. godine i privukla je
vie od 20 miliona korisnika do sredine 2000. godine.
Do kraja 2000. godine, preko 100 kompanija i brojni istraivaki projekti bili su angaovani na P2P
raunarstvu.
Do poetka sledee godine, program SETI@home, koji koristi distribuiranu obradu za analizu
radioteleskopskih podataka, privukao je vie od 2,6 miliona korisnika koji su uloili preko 500000
godina vremena centralne procesorske jedinice lovu na vanzemaljsku inteligenciju.
P2P raunarstvo obezbedjuje alternativu tradicionalnoj arhitekturi klijent-server i moe jednostavno da se
definie kao deljenje raunarskih resursa i usluga pomou direktne razmene. Dok koristi postoje mree,
servere i klijentsku infrastrukuturu, P2P nudi model raunarstva koji je ortogonalan na model klijent-
server. Dva modela koegzistiraju, presecaju se i medjusobno komplementiraju.
U modelu klijent-server, klijent postavlja zahtev serveru na koji je prikljuen preko mree. Server, koji je
tipino samostalan sistem, odgovara na zahteve i preduzima potrebne radnje u vezi sa njima. U P2P
raunarstvu, svaki uesniki raunar - koji se naziva ravnopravnim uredjajem (peer) - deluje kao klijent sa
slojem serverske funkcionalnosti. To omoguava ravnopravnom uredjaju da deluje istovremeno i kao
klijent i kao server unutar konteksta date aplikacije. Ravnopravni uredjaj moe da unese zahteve, a moe i
da odgovori na zahteve sa drugih uredjaja u mrei. Sposobnost direktnih razmena sa drugim korisnicima
nudi brojne prednosti - tehnike i drutvene - kako individualnim korisnicima tako i velikim
organizacijama.
Tehniki, P2P raunarstvo daje mogunost da se iroko koriste veliki resursi na koje uesnici nisu direktno
prikljueni i koji bi inae ostali neiskorieni. Ovi resursi obuhvataju procesnu mo za izraunavanja
velikog obima i ogromni memorijski potencijal. P2P dozvoljava eliminaciju "uskih grla" pojedinanih
uzroka. P2P moe da se upotrebi za raspodelu podataka i upravljanja i za ravnoteu optereenja zahtevima
preko Interneta. Pored toga to pomae da se optimizuje performansa, mehanizam P2P moe takodje da se
upotrebi za eliminaciju rizika od jedne take otkaza. Kada se P2P koristi unutar preduzea, to moe da
zameni neke skupe funkcije centra podataka raspodeljenim uslugama izmedju samih klijenata. Memorija,
za dobijanje podataka i njihove rezervne kopije, moe da se smesti kod korisnika. Pored toga,
infrastruktura P2P dozvoljava direktni pristup i deljeni prostor, to moe da omogui sposobnost da-
ljinskog odravanja.
Privlanost P2P raunarstva je velikim delom posledica drutvenih i psiholokih inilaca. Na primer,
korisnici mogu lako da formiraju svojs sopstvene autonomne onlajn Internet zajednice i da ih koriste kada
ih zajedniki odaberu. Mnoge od ovih P2P zajednica e se stalno dinamiki menjati kako korisnici dolaze i
odlaze, ili su aktivni, odnosno neaktivni. Drugi korisnici e uivati u tome da zaobidju centralizovanu
kontrolu. U stvari, P2P raunarstvo ima mo da mnoge korisnike uini nezavisnim.
12
4 as. Nastanak klijent server tehnologije
Model klijent server sistema predstavlja prirodan nastavak razvoja otvorenih sistema koji su zadnjih
10-tak godina predstavljali dominantnu organizaciju raunarskih sistema i aplikacija. Zahvaljujui
novim tehnologijama kao to su objektno orjentisano programiranje kao i GUI (Graphical User
Interfaces), kao i sve veem razvoju personalnih raunara, polako je vrena selidba aplikacija sa
monih mikroraunara i mainframe-raunara na desktop raunare. Postoje etri uslova koja su
doprinela velikom razvoju klijent serverskih sistema:
1. veliki pad cena procesora i raunarskih komponenti,
2. ogormno poveanje resursa raunarskih komponenti, clok procesora, memorija
3. veliki broj prilagoenih softverskih standarda,
4. veliki razvoj objektno orjentisanih tehnologija.
Zadnjih godina svedoci smo, moemo slobodno rei ve istorijskog trenda razvoja hardware-a
raunara, koji postaju sve manji, bri, snaniji a jevtiniji.
Sa druge strane organizacije danas oekuju da za svoja ulaganja dobiju sve vee vrednosti i sve vie
podataka koji e biti pravovremeni i tani. Brzina dobijanja podataka je danas odluujui faktor kod
donoenja velikih poslovnih odluka. Novac koji treba uloiti u tehnologije koje e omoguiti
poslovodstvu da donese pravovremene odluke postaje sve vie minorni faktor. Mnogo vei faktor
predstavlalja kompletan reinenjering poslovnog procesa kao i cena i vreme potrebno da bi se sistem
razvio. Ne treba zaboraviti i kompletnu edukaciju ljudstva od koga se zahteva dodatan napor kako bi
savladalo nove tehnologije. Puno puta to moe da predstavlja i najvei izdatak za jednu organizaciju.
Otvoreni sistemi omoguuju organizacijama da uloe novac u jednostavna i relativno jevtina reenja
koja e im reiti njihove poslovne zahteve. Standardi koji su doneti u otvorenim sistemima jasno
definiu formate u kojim e se podaci razmenjivati, kako pristupati udaljenim monim serverima i
kako pozivati servise koji nisu dostupni na personalnim raunarima. Veliki broj razliitih tehnologija
kao to su: objetno orjentisani razvoj, relacione i objektno orjenitisane baze podataka, multimedija,
ekspertni sistemi, geografski informacioni sistemi(GIS), prepoznavanje glasa, tekstualni procesori i td.
Predstavljale su veliki izazov za poslovne organizacije koje nisu mogle da odole ovolikom izazovu
koji se nudio po vrlo malim cenama. Klijent server model organizacije omoguavao je idealnu
platformu koja je objedinjavala sve ove mogunosti u samo jednoj obinoj desktop maini.
Zahvaljujui razvoju svih ovih tehnologija dolo je do kompletnog zaokreta tj. reinenjeringa
poslovnog procesa. Organizacije su traile nove naine kako bi upravljale svojim biznisom a koji bi im
doneo vei profit.
Globalizacija Svet polako postaje jedna velika pijaca jer se mnoge barijere briu Kvalitet, cena ,
razliiti proizvodi i servisi postaju kljuni faktori i najvaniji marketinki prioriteti. Sve vie se zahteva
blii kontakt sa kupcem i zadovoljenje njegovih prohteva.
Decentralizacija upravljanja Kvalitet i fleksibilnost zahtevali su donoenje odluka od strane mnogih
individualaca koji su u direktnom kntaktu sa kupcima. Nove tehnologije su morale da omogue i
takvim osobama da donesu pravilnu odluku o kojoj e i uravn poslovodsvo biti brzo informisano.
Mreno upravljanjeKao se biznis vodio sa velikog broja decentralizovanih lokacija, tehnologija je
morala da omogui da se sve te decentralizovane lokacije poveu u jednu i da predstavljaju jednu
jedinstvenu centralizovanu jedinicu.
Dostupnost informacija Da bi neki proizvod imao dobru prou mora se obezbediti da informacije o
njemu budu dostupne svima. Kupac mora da oseti da ima sigurnost u neku organizaciju od koje kupuje
proizvod.
Niska cena Zahvaljujui standardizaciji proizvoda omogueno je velikombroju prizcoaa da se
oprobaju i izardi tako da je velika ponuda smanjila cenu proizvoda a poveala kvalitet.
Razliite hardveske platforme Zbog raznolikosti hardware-a trebalo je omoguiti da se svi oni
meusobno vide. Tj. da mogu da komuniciraji jedan sa drugim bez obzira na tip raunara-procesora.
Minimalno poznavanje tehnologije Zbog porasta broja ljudi koji su se ukljuivali u rad sa raunarima
trebalo je omoguiti jednostavan pristup svim tim informacijama kao i da se vreme obuke za rad svede
na najmanju moguu meru. Zato se i razvijene mnoge tehnologije pre svega vizuelnog pristupa
13
informacijama. Danas se sve vie razvijaju i nove tehnologije koje se svode na to da se raunarima
obraamo glasom.
Razliita softverska reenja Ogroman razvoj softvera koji je mora da
nahrani raunare sa odgovarajuim programima zahtevao je i razliite
softverske alate koji su opet morali da budu kompatibilni kako bi mogli da
sa meusobno sporazumevaju.

Razliite baze podataka Ogroman broj podataka razvio je i odgovarajue
softverske alate za unoenje, auriranje i pregled tih podataka. SQL
(Structured Query Language) predstavlja jedan od osnocnih postulata kod
baza podataka. Ne posroji ni jedna ozbiljnija baza podataka koja ne
podrava ovaj vid komunikacije sa njom.

4.1. Pojam klijent-server
Klijent-server je arhitektura gde su korisnik (klijent) i server (davalac usluga) odvojeni ili
neravnopravni. Najoitiji je primer pregledavanja Internet stranica. Korisnikov raunar i Internet
program su klijent oni zahtevaju, dok su raunar i baza podataka koji ine web stranicu server on
daje usluge. Klijent je obino aktivan korisnik, koji alje zahteve i eka dok se isti ne ispune, dok je
server pasivan, eka na zahteve te ih ispunjava i alje korisniku. Serveri su obino veoma jaka raunara
s dobrim konfiguracijama i karakteristikama zbog toga to istovremeno moraju preraditi mnogo
zahteva koji rastu iz dana u dan. Obino servere pokreu i posebni operativni sistemi za razliku od
obinih klijent operativnih sistema, serverski operativni sistemi su u vie segmenata bolji i sadre
naprednije opcije.
Klijent/server model je baziran na distribuciji funkcija izmeu dva tipa nezavisnih i autonomnih
procesa: servera i klijenta. Klijent je bilo koji proces koji zahteva specifine usluge od server procesa.
Server je proces koji osigurava usluge za klijenta. Klijent i server mogu biti smjeteni u istom raunaru
ili u razliitim raunarima povezanim preko mree.
U sluaju da su klijent i server procesi smjeteni u dva ili vie nezavisnih i umreenih raunara, server
proces moe osigurati usluge za vie od jednog klijenta. Pored toga, klijent moe zahtevati usluge i od
vie servera iz okruenja bez obzira na njihove lokacije ili fizike karakteristike raunara na kojima se
nalaze server procesi. Mrea slui povezivanju servera i klijenata zajedno osiguravajui medij kroz
koji klijenti i serveri komuniciraju.

Slika2. Model klijent- server (http://www.ahyco.ffri.hr/ritehmreze/images/fig1-1.gif, 27.03.2008.)
Klijent-server arhitektura i klijent-server model obrade podataka se javlja poetkom devedesetih
godina 20 veka, priznanje doivljava ve polovinom istog desetljea, a razvijen je kao rezultat
14
nastojanja da se to bolje iskoristi resurs osobnih raunara, kroz njihovu integraciju u jedinstven sistem
za obradu podataka.
Klijent-server model obrade podataka je model distribuirane obrade podataka, gdje se funkcije jednog
korisnikog programa raspodjeljuju na najmanje dva procesa koji meusobno komuniciraju. Ta dva
procesa obrade podataka su: klijentski i serverski. Logika komunikacije klijentskog i serverskog
procesa je sljedea: klijentski proces alje poruku serverskom procesu, traei odreenu uslugu, a
serverski proces izvrava traeni zadatak i alje poruku klijentskom procesu o rezultatu (uspehu ili
neuspehu) izvrenog zadatka.
Klijentski i serverski procesi su specijalizirani za izvravanje odreenih tipova zadataka i uvek
komuniciraju oni delovi procesa koji su nadleni za traeni zadatak. Oba procesa se mogu izvravati na
jednom raunaru, ali pun opseg mogunosti se realizira distribucijom ovih procesa na veliki broj,
fiziki dislociranih raunara. Tada je raunarkoji izvrava klijentski dio procesa klijent-raunaro, ili
krae klijent, a po analogiji, isto vai i za server.
Dakle, za punu primjenu klijent-server arhitekture, potrebna su najmanje dva raunara, povezana
komunikacijskom mreom, s instaliranim mrenim operativnim sistemom i uspostavljenom
komunikacijom. Elementi koji ine klijent-server sistem jesu:
jedan ili vie klijenata,
jedan ili vie servera,
klijentski procesi,
serverski procesi,
komunikacijski meusloj (komunikacijski hardver i softver).
2.2 Nain funkcioniranja klijent server
Tipian (ali ne i obavezan) scenario po kojem radi klijent/server arhitektura je sledei:
Server proces zapoinje na nekom raunaru (na kojem je smeten), pokree se, a zatim prelazi u sleep
mod i eka da ga neki klijent proces kontaktira i zatrai neku uslugu od njega.
o Klijent proces zapoinje na istom ili nekom drugom raunaru koji je preko mree povezan sa
raunarom na kome se nalazi server. Klijent procesi se esto pokreu od strane interaktivnih
korisnika koji zahtevaju izvrenje odreenih naredbi. Klijent proces alje zahtev putem mree do
servera traei odreenu uslugu od njega.
o Kada server proces zavri posao (servis) koji je od njega zatraen od strane klijenta, prelazi ponovo
u sleep mod i eka sledei zahtev za nekom uslugom.
o Klijent/server arhitektura se zasniva na hardverskim i softverskim komponentama koje spajanjem
na taj nain ine sistem. Ovaj sistem sadri tri komponente: klijent, server i komunikacioni
posrednik.
o Klijent je bilo koji raunarski proces koji zahteva usluge od servera. Klijent, poznat jo i kao
glavna aplikacija, odraava injenicu da je krajnji korisnik obino u
interakciji sa klijent procesom.
o Server je bilo koji raunarski proces koji eka na zahteve od klijenata i
osigurava potrebne usluge za klijente shodno pristiglim zahtevima.
Poznat je i kao pozadinska aplikacija.
Komunikacioni posrednik je bilo koji raunarski proces ijim posredstvom
komuniciraju klijent i server. Sastavljen je od nekoliko softverskih nivoa
koji pomau pri prenosu podataka i upravljakih informacija izmeu klijenta
i servera. Komunikacioni posrednik je obino povezan sa mreom. Svi
klijentovi zahtevi i odgovori servera putuju kroz mreu u obliku poruka koje se sastoje od informacija
za kontrolu i prenos podataka. Slika 3. Klijent- Server

Klijent Server tehnologija
Klijent predstavlja jednokorisniku radnu stanicu koja omoguava predstavljenje traenih informacija
u vidu izraunavanja, povezivanja ili servisa baze podataka koji se odnose na poslovne zahteve.
Server predstavlja radnu stanicu sa jednim ili vie procesora koji omoguava viekorisniki (multiuser)
rad, koji treba da omogui to bri odziv i davanje traene informacije klijentima.
15
Ideja ovog modela je da se napravi kooperacija procesa izmeu servera koji obezbeuju servise i
klijenata koji servise zahtevaju. Ova paradigma se koristi na nivou aplikacije podjednako kao i na
nivou operativnog sistema. Svaki proces u iterakciji igra ili ulogu servera ili ulogu klijenta. Sa druge
strane, proces koji se ponaa kao server moe biti zahtevati servis od drugog servera da bi izvrio neki
zadatak, time dobijajui i ulogu klijenta. Maina moe biti jedan klijent, jedan server, vie klijenata ili
servera ili meavina klijenata i servera.
Logika komunikacija izmeu klijenata i servera je bazirana na razmeni zahteva i odgovora i to na
sledei nain:
1. klijent alje zahtev serveru i blokira se.
2. server prihvata zahtev, obavlja traeni zadatak-posao i vara odgovor klijentu.
3. klijent prima odgovor i nastavlja izvravanje.
Fiziki, zahtevi i odgovori se prosleuju dotinom kernelu, i alju kroz komunikacionu mreu ciljnim
kernelima i procesima. Iz jednostavnosti ovog modela proizilazi potreba za samo dva komunikaciona
sistemska poziva kernelu: send (poalji) i receive (primi) poruku.
Vano pitanje je kako klijent locira server ako on promeni lokaciju ili postoji vie servera. Zbog
fleksibilnosti serveri se identifikuju preko imena. Serveri, nazvani vezujui serveri (binder servers)
spajaju klijente i servere. Procedura koja izvrava ovo spajanje je nazvana dinamiko povezivanje
(dinamic bindig).Kada se server startuje on alje povezivau podatke o svojoj lokaciji.Tada klijenti
preko povezivaa zanaju lokaciju odgovarajueg servera.Kao dodatak, povezivai mogu pomagati u
autentifikaciji klijenata za servere.
KOMPONENTE I ARHITEKTURA KLIJENT/SERVER SISTEMA
Klijent/server arhitektura se zasniva na hardverskim i softverskim komponentama koje interaguju
formirajui na taj nain sistem. Ovaj sistem sadri tri komponente: klijent, server i komunikacioni
posrednik.
o Klijent je bilo koji raunarski proces koji zahteva usluge od servera. Klijent, poznat jo i kao eona
aplikacija, odraava injenicu da je krajnji korisnik obino u interakciji sa klijent procesom.
o Server je bilo koji raunarski proces koji eka na zahteve od klijenata i obezbeuje potrebne usluge
za klijente shodno pristiglim zahtevima. Poznat je i kao pozadinska aplikacija.
o Komunikacioni posrednik je bilo koji raunarski proces ijim posredstvom komuniciraju klijent i
server. Sastavljen je od nekoliko softverskih nivoa koji pomau pri prenosu podataka i upravljakih
informacija izmeu klijenta i servera. Komunikacioni posrednik je obino povezan sa mreom. Svi
klijentovi zahtevi i odgovori servera putuju kroz mreu u obliku poruka koje se sastoje od
informacija za kontrolu prenos i podataka.
Za ilustraciju interakcije komponenata moe da poslui primer kada klijent zahteva servise od procesa
baze podataka. Izvrenje aplikacije je razdvojeno na dve glavne i nezavisne komponente, klijent i
server, a komunikacioni posrednik omoguava klijent i server procesima da rade zajedno.
Najpre klijent proces alje zahtev do komunikacionog posrednika. Komunikacioni posrednik
prosleuje SQL zahtev do server procesa za baze podataka koji prima zahtev, potvruje ga i izvrava.
Potom server alje selektovane podatke komunikacionom posredniku koji ih prosleuje i formatira za
klijent proces, a ovaj prima podatke i prikazuje ih korisniku. Klijent proces je odgovoran za interfejs
krajnjeg korisnika, neku proveru lokalnih podataka, neku obradnu logiku i prikaz podataka.
Komunikacioni posrednik obezbeuje da poruke izmeu klijenta i servera ispravno putuju kroz mreu i
stignu na svoje odredite. Obrada SQL zahteva se vri na serveru. Server proces potvruje izvravanje
zahteva i alje rezultat klijentu.

Komponente klijent/server arhitekture moraju da zadovolje neke osnovne principe kako bi
meusobno delovale ispravno. Ovi principi moraju biti jednoznano upotrebljivi u komponentama
klijenta, servera i komunikacionog posrednika. Pri razvoju i upotrebi klijent-server tehnologije treba se
drati sledeih principa, koji moraju biti ispunjeni i to:
1. Hardverska nezavisnost je postignuta kada klijentski, serverski i procesi komunikacionog
meusloja uspeno funkcioniu na razliitim hardverskim platformama (IBM, DEC, Apple itd.)
16
bez ikakve funkcionalne razlike, odnosno kada izmene u hardverskoj konfiguraciji sistema ne utiu
na funkcionisanje klijent-server sistema.
2. Softverska nezavisnost je postignuta kada klijentski, serverski i procesi komunikacijskog
posrednika mogu funkcionirati na razliitim operativnim sistemima (DOS, Windows, Unix, OS/2),
uz upotrebu razliitih mrenih protokola (TCP/IP, SPX/IPX) kao i da podravaju razliite
aplikacije (baze podataka, radne tabele, elektronska pota itd.).
3. Otvoren pristup servisima je ostvaren kada klijentski proces ima mogunost da, po potrebi, bez
ogranienja, koristi usluge svih serverskih procesa u mrei, nezavisno od lokacijske udaljenosti
klijenta i servera. Svi klijenti u sistemu moraju imati otvoren pristup svim servisima svih servera
koji postoje u mrei i to onoliko puta koliko oni to zahtevaju. Servisi ne smeju zavisiti od lokacija
klijenata i servera u mrei. Kljuna stvar je da se servisi obezbeuju na zahtev klijenata.
4. Funkcionalna distributivnost je ostvarena kada klijentski, serverski i procesi meusloja
predstavljaju nezavisne initelje u obradi podataka i imaju precizno definirane namene, zadatke i
granice. Funkcionalna distributivnost treba omoguiti "zamenjivost" delova softvera, to
podrazumijeva da tekua verzija nekog klijentskog, serverskog ili programa u meusloju klijent-
server arhitekture, moe zameniti novom, a da to ne utie na funkcionisanje ostalih komponenti
softvera. Celokupna obrada podataka je distribuirana izmeu klijenta i servera. Podela optereenja
obrade mora se povinovati sledeim zahtevima:
Klijent i server procesi moraju biti autonomni, sa jasno definisanim granicama i funkcijama. Ova
osobina omoguuje jasno definisanje funkcionalnosti obe strane.
Lokalno korienje resursa (i klijenta i servera) je maksimalno. Procesi klijenta i servera moraju
potpuno koristiti snagu obrade glavnog raunara. Ova osobina omoguuje dodelu zadataka
raunaru koji najvie funkcionalno odgovara.
Potrebno je da procesi budu takvi da mogu biti lako i to bolje izvreni na vie snanih
hardverskih platformi. Potrebno je jo da bude ispunjen i uslov prenosivosti softvera izmeu
razliitih maina bez potrebe da se intervenie na izvornom kodu, ve je potrebno samo izvriti
prevoenje i povezivanje kako bi softver odmah moga da se upotrebi.
5. Interoperabilnost i integracija zahtevaju da procesi klijenta i servera budu integrisani u
"bezavnu" formu sistema, tj. razliite aplikacije imaju mogunost razmene podataka izmeu
razliitih hardverskih platformi i operativnih sistema bez obzira na udaljenost, opremu, tip
operativnog sistema i dr. Izmene server procesa moraju biti transparentne za klijent procese.
6. Standardizacija ima za cilj da osigura to vii stepen hardverske i softverske nezavisnosti, kao i
nezavisnost korisnikog programa od podataka. Korisniki interface, pristup podacima i mreni
protokol, kao i drugi elementi klijent-server arhitekture trebaju biti pokriveni odgovarajuim
standardima. Svi principi moraju biti bazirani na standardima primenjenim unutar klijent/server
arhitrkture. Na primer, po standardima se mora upravljati korisnikim interfejsom, pristupom
podacima, mrenim protokolima, meuprenosnom komunikacijom, itd. Univerzalni standardi jo
uvek ne postoje ve ima mnogo razliitih standarda koji se mogu primeniti. Na primer, aplikacija
moe biti bazirana na ODBC (Open DataBase Conectivity) umesto IDAPI (Integrated Database
Application Programing Interface) za pristup podacim i moe koristiti SPX/IPX umesto TCP/IP
mrene protokole

Prednosti klijent server tehnologije
Osnovna prednost dvoslojne klijent-server arhitekture je ta to bazu podataka ini nezavisnom
od aplikacija, jer integritet baze podataka osigurava njenu nezavisnost od aplikacija koje nad njom
rade. Jedini mehanizam potreban za komunikaciju aplikacije sa bazom podataka je SQL upit, koji se
prosleuje direktno ili kroz neku raunarsku mreu. Ipak, znaajan deo aplikacije se vee za klijenta,
to prouzrokuje osnovne nedostatke ovakve arhitekture. Povezivanje dinamikog ponaanja sistema
(logike sistema) za klijenta, zbog estih izmena u korisnikom okruenju, prouzrokuje skupo
odravanje sistema a zbog estih izmena u tehnologiji korisnikih interface-a i skupo odravanje.
17
Osnovne prednosti koje nam klijent server arhitektura omoguava sastoje se u sledeem:
1. Pristup ogromnoj koliini podataka - ak se moe rei
pristup neogranienoj koliini podataka.
2. Integrisani servisi na jednom mestu ( E-mail, grafika,
baze podataka, tekstovi, kao primer prikazati benzinsku
pumpu.)
3. deljeni resursi na razliitim platformama
4. zamenljivost podataka i interoperatibilnost
5. maskirani fiziki pristup podacima putem lozinki
dozvoljava se ogranieni pristup podacima ( firewall)
6. nezavisne lokacije procesiranja i pamenja podataka
7. centralizovano upravljanje


18
5 as Klijent server komponente KLIJENT
U klijent server modelu, bilo koju radnu stanicu (desktop workstation) koju koristi jedan korisnik
smatramo klijent radnom stanicom ili samo klijentom. Ukoliko toj istoj stanici pristupaju istovremeno
vie korisnika simultano, tu istu stanicu nazivamo serverom. Iz ovoga proizilazi da u klijent server
modelu ne postoje neke tehnoloke razlike, sa stanovnitva raunara, izmeu klijenta i servera.
Za vreme poslednjih 30 godina performanse radnih stanica su dramatino menjale tj. napredovale. Za
istu cenu,performanse CPU poveale su se 500 puta (4,7MHz->2,4GHz), veliina RAM-a (operativne
memorije) 4000 puta ( 256kB -> 1GB) i kapacitet hard diskova 30000 puta (10MB-> 300GB). Ovako
veliki napredak tehnologije uinio je da aplikacije koje su se izvravale na desktop raunarima postanu
jako sofisticirane tj. u mogunosti su da reavaju jako teke i zahtevne probelme poev od
jednostavnog tekst editora pa sve do vrlo sloenih multimedijalnih problema. Sa druge strane ovakav
veliki razvoj tehnologije desktop raunara prouzrokovao je i veliki razvoj drugih raunarskih
tehnologija a pre svega komunikacionih (razvoj velikog broja protokola) i mrenih ( LAN i WAN
mree). Danas je prosto nezamislivo da imamo neki desktop raunar koji nije umreen sa nekim
drugim raunarom na bilo koji nain: bilo to direktnom vezom dva raunara, bilo u vidu lokalnih
mrenih sistema ili pak putem interneta.
Klijent je bilo koji proces koji zahteva usluge od serverovog procesa. Klijent zapoinje konverzaciju sa
serverom. Klijent sadri hardverske i softverske komponente i poeljno je da one poseduju sledee
karakteristike:
o Ne toliko snaan hardver
o Operativni sistem koji je sposoban da podri multitasking
o Grafiki korisniki interfejs (GUI Graphic User Interface)
o Komunikacione sposobnosti
Hardver klijenta je obino stoni raunar (PC ili radna stanica, a u poslednje vreme se koristi i X-
terminal koji jedan de potrebnog klijent/server softvera dri u ROM-u, a ostatak se puni u RAM
memoriju sa servera preko mree).
Klijent bi trebalo da poseduje operativni sistem sa neto malo multitasking mogunostima. Postoji
iroki opseg razliitih operativnih sistema koji mogu da zadovolje minimalne zahteva da bi bili
klijentsji operativni sistem. Od ve starih DOS/Windows operativnih sistema do dananjih WinXP i
Win 7 operativnih sistema koji su trenutno najkorienije klijent platforme. Mada DOS ima jaka
ogranienja u pogledu memorije i podrke multitaskinga, Windows 3.1 obezbeuje primitivne
multitasking osobine i GUI. WinXP kao samostalan operativni sistem podrava multitasking i sve vie
zamenjuje DOS/Windows kombinaciju. Ove osobine kao i mnotvo razvijenih aplikacija za ove
operativne sisteme ine ih vrlo pogodnim za klijent/server implementaciju. Kombinacija hardvera i
operativnog sistema mora obezbediti adekvatno povezivanje sa raznim mrenim operativnim
sistemima. Servisi mogu biti rasporeeni na razliitim mreama i klijent raunari moraju biti sposobni
da pristupe svim tim servisima. Zbog toga, bez obzira na popularnost DOS/Windows kombinacije i
Windows-a XP, kao bolja reenja za klijent operativne sisteme se javljaju OS/2, Unix ili Linux.
Klijent aplikacija se startuje pod nekim operativnim sistemom i povezuje se sa komunikacionim
posrednikom radi pristupa slobodnim servisima na mrei i ove aplikacije su uglavnom zasnovane na
grafikom korisnikom interfejsu sa namerom da se sakrije kompleksnost od krajnjeg korisnika.
Klijent aplikacija interaguje sa operativnim sistemom radi korienja multitaskinga i grafikog
korisnikog interfejsa koje on obezbeuje. Ona jo interaguje i sa mrenom softverskom
komponentom komunikacionog posrednika radi pristupa servisima. Hardverska komponenta
komunikacionog posrednikam (mrena kartica i mreni kabl) fiziki transportuje zahteve i odgovore
na zahteve izmeu klijenta i servera. Dok se zahtev izvrava na serveru, klijent je slobodan da izvrava
druge poslove.

Uloga klijenta
U klijent server modelu klijent je u osnovi potroa servisa kojima ga snabdeva jedan ili vie servera.
Ovaj model omoguuje jasnu podelu funkcija izmeu klijenta i servera jer server treba da omogui
odreene servise klijentu u odnosu na njegove zahteve. Vrlo je vano da se razume da radna stanica
19
moe da funkcionie kao klijent i kao server, sve u zavisnosti kako se posmatra ta stanica. Na primer u
LAN mreama jedna stanica moe da funkcionie kao klijent za jednog korisnika koji na njoj radi a
istovremeno kao print server za druge korisnike u mrei. Jedan od osnovnih servisa koji se izvravaju
na klijen radnoj stanici je prezentacioni servis. On podrazumeva ulazni i izlazni servis koji kontrolie
prihvatanje i prikazivanje podataka. Dananje tehnologije omoguile su grafiki korisniki servis (GUI
Graphical User Interface), a nove multimedijalne tehnologije koje su danas u velikom razvoju
omogui e nam u budunosti audio-vizuelni pristup podacima. Tehnika viestrukih prozora (
windowing enviroment) omoguuje klijentu korisniku da bude ukljuen u nekoliko simultanih sesija.
Tako funkcije kao to su unoenje teksta, sluanje muzike, praenje E-maila i grafiko prikazivanje
podataka mogu potpuno simultano da se odvijaju na jednom klijent raunaru. Normalno da bi sve ovo
mogli da pratimo potrebni su nam odgovarajui operativni sistemi koji podravaju multitasking rad
kao to su WIN2000, WINXP ili LINUX. Mogunosti kao to su DDE ( Dynamic Data Echange)
dinamika razmena podataka, OLE ( Object Level Embedding) i CORBA (Communicating Object
Request Broker Architecture) omoguuju prostu operaciju cut and paste izmeu tekst procesora, baza
podataka, tabelarnih prikaza, grafikih prikaza u razliitim viestrukim prozorima.
Klijent servis
Idealna klijent server platforma operie u jednom otvorenom sistemskom okruenju i koristi serverske
servise na bazi postavljenih zahteva ( tehnika zahtev/odgovor ) koji su svi bazirani na ranije dobro
definisanim i usvojenim standardima. Zahvaljujui ovim osobinama omogueno je da veliki broj
potpuno razliitih i hardverskih i softverskih reenja meusobno vrlo dobro sarauju i rade. Serveri
mogu da se dograuju i da menjaju svoj operativni sistem ili hardversku platformu a da se sa gledita
klijenta to uopte i ne oseti tj. nije potrebno da se menja aplikacija sa strane klijenta. Jedini uslov je da
se sve te promene odvijaju po unapred definisanim i usvojenim standardima. to se tie klijenta i tu je
pria ista. Klijenti mogu da menjaju takoe svoj operativni sistem, aplikaciju ili hardversku platformu
a da to server uopte i ne primeti. Tako sa gledita klijenta moemo da imamo obinu 386 mainu ili
neku RISC-baziranu mainu i da obe maine zahtevaju od servera isti servis.
Prvi klijent server sistemi nisu imali grafiko okruenje GUI (Graphical User Inteface). Sve
informacije koje su dolazile od strane servera bile su u obliku tekstualnih podataka koji su puno puta
bili dosta nepregledni. Dananji sistemi imaju kvalitet vie pa pored tekstualnih podataka imaju i GUI
prikaz i audio vizuelni prikaz koji podrazumeva i ton i sliku. Kolika je to prednost najbolje se ilustruje
kod sistema zatite prostora. Ta zatita se najee radi sa vie tehnikih sredstava kao to su kamere,
mikrotalasne barijere i razliitim vrstama senzora. Na svako naruavanje prostora automatski se
ukljue kamere i slika nam se prikae na ekranu monitora sa svim potrebnim prateim podacima u
vidu teksta. Na drugoj strani prednos ovakvog prikaza je u vrlo jednostavnoj i skraenoj obuci
personala za rad sa ovakvim sistemima. Neke studije su pokazale da primena GUI moe da povea
produktivnost i efikasnost i do 200 % vie u odnosu na obine tekstualne aplikacije. Fukcionalnost
klijentskog procesa moe biti i poveana na strani klijenta dodavanjem logike koja nije implementirana
u aplikaciju koja se izvrava na serveru. Lokalno sreivanje teksta, sposobnost davanja HELP
informacija, automatski ulaz podataka predstavljaju samo neke servise koji u mnogome unapreuju
klijent serverski proces. Ako se mnoge greke detektuju i otklone na strani klijenta, tada se u mnogome
poveava brzina serverske strane pa se samim tim i poveava funkcionalnost celokupnog klijent server
sistema.
Da vidimo sada kako se odvija ta komunikacija izmeu klijenta i servera. Klijent radna stanica zahteva
neki servis od servera. Kad god je taj server isti kao i radna stanica ili pak predstavlaj neki mreni
server aplikacioni format zahteva je isti. NOS (Netware Operative System) softver prenosi ili dodaje
specificirani zahtev od izvora do ciljnog servera na kome se izvrava neka aplikacija, IPC
(InterProcess Communication)
predstavlja generiki izraz koji se koristi da opie komunikaciju izmeu dva ili vie procesa koji se
izvravaju. U klijen server modelu ti procesi mogu biti na istom raunaru, na raunarima koju su
povezani u LAN mreu ili pak u WAN mrei. Najei servis koji NOS pokree u takvim sluajevima
je servis redirekcije. Ovaj servis prihvata pozive od klijentskog operativnog sistema i prenosi
preusmerava ih prema serverskom operativnom sistemu. Na taj nain zahtevi za direktorijume na
20
disku, disk fajlovima, printerima, printer redovima, serijskim ureajima, aplikacionim programima se
presreu putem redirekcionog softvera i preusmeravaju se prema korektnom serveru.
Dugi niz godina programeri su se trudili da razvijaju modularni kod koristei strukturnu tehniku i
logiku poziva podprograma. Danas se zahteva da ti podprogrami (subroutines) budu ipameni negde
kao objekti koji e sada biti dostupni svima ko eli da se koristi njima. Tehnika poznata kao RPC
(Remote Procedure Call) upravo omoguava ovakav vid programiranja. RPC zbog toga predstavlja
srce klijent server modela i sutini predstavlja program koji moe da pozove bilo koju proceduru u
mrei sa ciljem da zadovolji zahteve klijenta. Pri tome ak i ne mora da zna ni fiziko mesto gde se
traena procedura ili servis nalazi i izvrava. Klijent upuuje svoj zahtev i dobija odgovor preko samo
jedne send primitive, to znai da RPC troi samo jednu operaciju jezgra. Takoe u ovom mehanizmu
pojednostavljeno je baferisanje jer u istom baferu umesto zahteva u povratku moe da se smesti traeni
odgovor. RPC omoguava da se poziv i izvrenje zahteva moe odvijati na potpuno razliitim
operativnim sistemima i potpuno razliitim hardverskim platformama. Mnogi RPC omoguavaju i
servise translacije. Oni podrazumevaju da se vri prevoenje (translacija) podataka izmeu procesora
sa razliitim fizikim formatima podataka. Ti standardi se stalno usavravaju i prilagoavaju
zahtevima trita.
Vrste klijent servisa kojise odvijaju na klijentskoj strani:
Fax/Print servis NOS ( mreni operativni sistem) omoguuje klijentu da generie zahtev za
tampanjem bez obzira to je tog trenutka printer zauzet. Taj se zahtev prenosi putem NOS redirektora
i smeta u print server red kojim upravlja print server manager. Klijentska stanica moe da vidi status
print red u bilo koje doba i tako se informie kada e traeni servis biti omoguen tj. izvren. Veina
print servera obavetava klijensku stanicu kada se njen zahtev izvri. Fax servis se izvrava na potpuno
isti nain kao i print zahtev.
E-mail servis funkcionie na isti nain kao i gore opisani servis.
Window servis servis prozora oznaava da se na klijentskom raunaru mogu istovremeno otvoriti
vie prozora u okviru kojih se mogu izvravati razliite aplikacije. Mogunost da se aktivira, vidi,
pomera, smanji ili povea, sakrije odreeni prozor omoguena je ba zahvaljujii ovom servisu. Ovaj
servis je edan od osnovnih servisa u klijent server modelu jer je on u neposredom kontaktu sa servisom
poruka koji je zaduen da obavesti korisnika o dogaajima koji se deavaju na serveru. Kod pisanja
aplikacija nije potrebno voditi rauna o servisu prozora jer se on automatski prenosi na alikaciju.
Svaka aplikacija se pie tako da se predpostavlja da ona ima na raspolaganji jedan virtuelni prozor
putem kojeg ona komunicira sa korisnikom. Taj virtuelni prozor je poizvoljne veliine i moe biti vei
nego to je fiziki prozor. Aplikacija koja koristi GUI smeta podatke u taj virtuelni prozor, a servis
prozora sada vodi rauna o smetanju i prikazivanju tog prozora u realnim uslovima. To u mnogome
pojednostavljuje pisanje aplikacija jer programer nema potrebu da vodi rauna o servisu prozora. NOS
omoguuje klijentskoj radnoj stanici, bez obzira u kojoj se aplikaciji trenutno nalazila, da putem pop-
up prozora obavetava klijenta o nekim deavanjima na serverima kao to su: zavretak tampanja,
probel u ampanju, novoj poti u E-mail sanduetu, pristiglom FAX-u i td.
Remote Boot Service Neke aplikacije mogu da se izvravaju na klijentskim radnim stanicama bez bilo
kakvog lokalnog diska sa koga bi se uito opertativni sistem ili aplikacija. Primer X-terminala. Da bi to
moglo da funkcionie klijent mora da obezbedi odgovarajui softver koji se nalazi u EPROM memoriji
koja je u klijenskoj radnoj stanici i osnovna namena tog programa je da startuje IPL (initial program
load) tj. proces punjenja ili butovanja.
Backup Service Predstavlja servis koji se moe pozvati sa klijentske strane a koji se izvrava na
serveru kaoko bi se uradila zatita fajlova tkz. Backup-iranje.
Utility Service Operativni sistem omoguava lokalne funkcije kao to su: kopiranje, premetanje,
editovanje, uporeivanje i funkciju helpa koji se izvrava na lokalnoj radnoj stanici.
Message Service Poruke se mogu primati i slati potpuno sinhronizovano na mreu. Ovaj servis
omoguava baferovanje (skladitenje), pozadinsko prikazivanje (scheduling) i servis izbora poruka
(arbitration service) da bi mogao u potpunosti da izvri sve zahteve kojise stavljaju pred njim.
Network Service Klijentska radna stanica komunicira sa mreom putem vie servisa i API-a koji
kreiraju, alju, primaju i formatiraju mrene poruke. Da bi to sve moglo da se obavi neophodna je
21
podrka za komunikacione protokole kao to su: NetBIOS, IPX, TCP/IP, APPC, Ethernet, Token Ring,
X.25 i td.
Application Service Podrazumeva da mnoge aplikacije imaju sopstveni RPC kojim se koriste da bi
mogle da pozovu neke servise sa udaljenog servera.
Database Service Zahtevi za podacima iz baze podataka zasnivaju se na SQL sintaksi. SQL
predstavlja industrijski standardizovani jezik za uparvljanje bazama podataka.
Netware Mangment Service-Alerts Veina mrenih interfejs kartica (NIC-netware interface cards)
moe da generie alerte-upozoravajue poruke koje obavetavaku klijenta o pojavi greaka na mrei u
vrlo ranom stadijumu- na fizikom nivou. To je jako dobro jer je mogue problem razreiti u ranoj faze
pre nego to ta greka doprinese da ona bude katastrofalna.

22
6 as Programska podrka klijenta

Sve vei zahtevi koji su se postavljali pred programerima kod pisanja aplikacija kao i veliki
razvoj novih tehnologija zahtevali su od razvojnih timova veliko poznavanje svih tih tehnologija kao i
osobina najnovijih operativnih sistema na kojima su se te aplikacije izvravale. Sve su to bili krupni
zahtevi koji su u mnogome usporavali razvoj aplikacije. Prosto je nemogue bilo da se sa jednom
aplikacijom objedine sve te tehnologije kao i da se vodi rauna o upravljanju svi deljivim resursima
servera (kao to su memorija ili procesorsko vreme), da se vodi rauna o upravljanju kontekstom ili
rukovanju nitima. To bi zahtevalo da se svaka transakcija koja se deava u sistemu posebno programira
a takve aplikacije bi bile jako teke i skupe za odravanje. To je jedan od glavnih razloga to je razvoj
komponentnih modela postao popularan i doive veliki razvoj poslednjih godina. Komponente u
kojima je implementiran mehanizam izvravanja transakcija u mnogome oslobaaju programere od
ovog tekog zadatka i predstavljaju jedan od najefikasnijih naina da se brzo i kvalitetno naprave
aplikacije koje e u potpunosti zadovoljiti zahteve trita. Komonentni model razvijanja aplikacije
omoguava lake izmene a samim tim i jednostavno odavanje aplikacije. Sa druge strane vreme
potrebno za razvijanje, pisanje i implementaciju aplikacije se drastino smanjuje jer postoji veliki broj
ve razvijenih komponenti koje se mogu sa lakoom primeniti i iskoristiti. Ovakav pristup
impementaciji transakcija se naziva deklerativnim pristupom. Trenutno najpopularniji komponentni
modeli kod razvijanja aplikacije su COM+ (Component Object Model), EJB (Enterprise Java Beans) i
CORBA (Common Object Request Broker Architecture)
Pre nego to preemo na razmatranje ovih komponentnih modela potrebno je da ukaemo i na jo
nekoliko pojmova-tehnika koje su u mnogome doprinele razvoju ovakvih komonentnih modula tj. bili
su neophodni preduslovi koji su doprineli da se doe do ovakvih reenja na nivou globalne
distribuirane mree raunara. To su:
o Dynamic Data Excange (DDE) -predstavlja funkciju koja omoguava klijentu da
razmenjuje podatke izmeu razliitih aplikacija zahvaljujii jedinstvenom API-u. Na primer
grafiki prikaz nekog podatka moe biti povezan sa podacima u bazi podataka. Kako se ti podaci
menjaju tako se i grafiki prikaz menja.
o Object Linking and Embedding (OLE)- OLE predstavlja jedno proirenje DDE koje je
omoguilo da sa objekti kreiraju sa objektim softverskim komonentama. To znai da postoji
referenca izmeu objekata i odgovarajueg softvera kojim su te komponente formirane. Na
primer ako u nekom tekst dokumentu imamo neke slike koje su kreirane sa nekim grafikim
softverom (Corel ili Photoshop) kada god kliknemo na tu sliku, iako se nalazimo u okviru tekst
procesorra ( WORD ), automatski se otvara program kojim je ta slika formirana.Tu se pokreu
dva programa viewer(pregledanje) i launcher(izvravanje). Sa viwer-om korisnik moe da vidi
objekat sa jednim softverskim paketom dok radi u drugom paketu, a sa launcher-om on poziva
softverski paket koji je kreirao taj objekat i na raspolaganju su mu sve funkcije tog paketa. OLE
je 1992 god. razvio Microsoft koji je kasnije 1995 god. prerastao u COM (Component Object
Model). Od 1996 godine COM poinje sa podrkom distribuiranog procesiranja i dobija ime
DCOM (Distributed COM).
o Distributed Computing Environment (OSF DCE)- predstavlja komunikacioni
mehanizam koji nam dozvoljava kako rad tako i razvoj distribuiranih aplikacija baziranih na
klijent server modelu. Filozofija klijent server sistema podrazumeva veoma visok nivo
komunikativnosti izmeu raunara bez obzira na njihovu veliinu, hardversku platformu ili vrste
operativnog sistema tj. softverske aplikacije koja se na njima izvrava. Bez obzira na razliite
ciljeve i okruenja na kojima se te aplikacije izvravaju sve one imaju neke zajednike osnove
koje moraju da zadovolje a to su: - RPC (Remote Procedure Call) je osnovna premisa
distribuiranih heterogenih komunikacija. Ranije smo ve govorili o RPC kao servisu-programu
koji predstavlja srce klijent server modela. Meutim, RPC se moe posmatrati i kao protokol na
nivou prezentacije ISO OSI modela standardizovanog komunikacionog okruenja. Tako
posmatrani PRC moe se opisati preko pet osnovnih komponenti i to: stubovi, protokol za
uspostavljanje veze (binding protocol), reprezentacija podataka, transportni protokol, upravljaki
23
protokol kao to je prikazano na slici br 1.
Da bi
se ove nabrojane komponente mogle da objasne potrebno je da razvoj i upotrebu distribuirane
aplikacije posmatramo kroz tri faze: vreme potrebno za kompilaciju, vreme uspostavljanja veze i
vreme poziva. Podrazumeva se da se programiranje klijent server modula vri na nain kao da e
oba modula biti linkovana tj. povezana zajedno. Server implementira poseban interfejs napisan u
nekom opisnom jeziku (IDL interface description language) iji se opis onda procesira
proizvodei dva stuba: klijentov i serverov stub. Klijentov stub se linkuje sa klijentom koji ga
sada vidi kao server i obrnuto server posmatra svoj stub kao klijent. Mehanizam stubova odvaja
klijenta i srevera od detalja uspostavljanja veze (a to je proces kada se klijent pridruuje serveru)
i transporta (kada se argumenti i podaci stvarno razmenjuju izmeu klijenta i servera). RPC
mehanizam takoe ovde upravlja sinhronizacijom, kodiranjem podataka, timeout-ima( proble
kada raunar iz nekog razloga ne odgovori unutar nekog predvienog vremena zbog pada
raunara ili preoptereenja mree) i zatitnim informacijama.
- administracija imena resursa je od izuzetne vanosti jer distribuirani sistemi upotrebljavaju
imena da opiu razliite resurse kao to su raunari, fajlovi, adresari, programi, korisnici i td.
Osnovni zahtev je da se ova imena mogu identifikovati na jedinstven nain u celom
distribuiranom sistemu ma kakav on bio heterogen i razuen. Koegzistentnost imena se zahteva i
onda kada se promeni lokacija nekom od ovih resursa. Ba iz tog razloga, sa obzirom na
potencijalno veliki broj resursa, jasno je da kreiranje i upravljenje resursima mora biti
maksimalno pojednostavljeno.
- reenje mora biti nezavisno od broja raunara u mrei,
- reenje mora da obezbedi zatitu integriteta podataka.Jasno je da u jednom distribuiranom
raunarskom sistemu zatita podataka mnogo kopleksija nego kod samostalnih raunarskih
sistema. Posebni serveri zatite, kriptovanje podataka, sistem autentinosti, lozinke, specijalni
protokoli i mnogi drugi mehanizmi su razvijeni da bi se obezbedila potpuna zatita podataka.
Zahvaljujui OSF DCE komunikacionom mehanizmu obezbeen je jedan potpuno novi ambijent
za razvoj aplikacija u distribuiranim mrenim okruenjima. Omogueno je da se vrlo sloeni
programi mogu razvijati na vie razasutih lokacija irom sveta. U veoma kratkom vremenu,
koristei svaki za sebe najbolje lokane resurse (znanje i opremu) kao i prilazei ve razvijenim
programima na drugim lokacijama, programerima je omogueno da razvijaju jako mone i
24
sloene aplikacije. Koristei RPC, klijent moe pozvati proceduru na udaljenom sistemu na nain
kao da je to lokalni poziv procedure. RPC sa sobom nosi potrebne argumente i vraa rezultat.
Server sada predstavlja udaljeni ekvivalent biblioteke procedura, dok je klijent program-
aplikacija koja poziva te procedure. Problem povezivanja klijenta i servera se odvija na
posebnom serveru na kome se izvrava proces povezivanja. Ako se zna da RPC troi samo
nekoliko milisekundi ( u zavisnosti od kvaliteta mree i njene optereenosti), a sve ostalo vreme
je isto kao i u lokalnim uslovima, onda je jasno zato je ovakav komponentni pristup reavanju
probelma doiveo ovoliki procvat.

25
7 as
S obzirom da se sistemi zasnovani na distribuiranim objektima razvijaju ve decenija unazad, na tritu
postoji veliki broj razliitih platformi (tehnologija) za implementaciju vieslojne arhitekture. Pri
odabiru distribuirane tehnologije treba obratiti panju na sledee parametre:
- prenosivost (portabilnost) klijentske i serverske platforme
- prenosivost programskog jezika
- performanse pri izvravanju
- jednostavnost razvoja
- sigurnost
Rezultati testiranja sa razliitim komunikacionim modelima za udaljeno pozivanje komponenata do
danas su rezultirali nekoliko najpoznatijim tehnologijama o kojima e biti daljer rei.

7.1 Componet Object Model (COM+/ DCOM )
COM+ predstavlja evoluciju starije tehnologije COM (Component Object Model). COM je
specifikacija za objekte koja definie interfejs preko koga razliiti objekti mogu da komuniciraju.
COM je nezavisan od programskog jezika ukoliko implementira COM interfejs. Teoretski moe da se
implementira na razliitim operativnim sistemima, meutim nijedan drugi operativni sistem nije
prihvatio COM objekte osim Microsoft Windows-a. Da bi se omoguilo da COM objekti sa razliitih
sistema meusobno razmenjuju informacije, COM specifikacija je proirena i nastao je DCOM
(Distributed COM). DCOM poseduje znatno kompleksniji model konfiguracije i sigurnosti.
Za potpuno razumevanje COM+ komponentnog modela prvo je potrebno razjasniti Windows DNA
(Distributed interNet Aplication architecture).Windows DNA je platforma koja opisuje kako razvijati
vieslojne, skalabilne distribuirane aplikacije visokih performansi za rad u mrei. Cilj DNA je
dobavljanje enterprise level reenja. Srce DNA je integrisani programski model baziran na COM+.
Drugim reima DNA je put za obezbeivanje enterprise based reenja Microsoft-a.

Alati COM+ Sistemski servisi
Administracija

Prezentacioni sloj Mreni servisi
DHTML, Forme

Sloj poslovne logike
WEB Server (IIS), Zatita
Transakcije (MTS)

Sloj pristupa podacima Osnovni servisi
DBMS, File system, mail, txt

Kao to je prikazano na slici Windows DNA se sastoji od tri sloja:
1. Prezentacioni sloj - predstavlja sloj koji je odgovoran za prikupljanje informacija od korisnika,
vrenje osnovnih provera unetih podataka, njihovo slanje sloju poslovne logike, primanje rezultaa
od sloja poslovne logike i prezentacija dobijenih rezultata korisniku u razumljivom formatu. Ovaj
sloj sainjavaju VB, HTML, DHTML, Win32 aplikacije, klijent-server skriptovanje, java apleti,
ActiveX kontrole i td.
2. Sloj poslovne logike ovo je sloj odgovoran za primanje podataka od prezentacionog sloja,
iterakciju sa slojem za pristup podacima radi procesiranja podataka i slanje obraenih informacija
prezentacionom sloju. Ovaj sloj obezbeuje poslovna pravila i servise koji pomau tokom pisanja
skalabilnih aplikacija. Ovi servisi su vrsto integrisani jedan sa drugim i sa operativnim sistemom i
dostupni su preko COM-a. Oni ukljuuju sledee:
a. Web servise, putem Microsoft Internet Information Server-a (IIS)
b. Transakcionog i servisa komponenti, putem Microsoft Transaction Server-a (MTS).
c. Asihronih i servisa redova, putem Microsoft Message Queue Server-a (MSMQ).
d. Serverskog skriptovanja, putem Active Server Pages (ASP).
3. Sloj za pristup podacima Ovaj sloj direktno interaguje sa podacima koji obino egzistiraju u bazi
podataka kao to su SQL Server ili Oracle. Ovaj sloj je odgovoran za smetanje, pronalaenje i
26
odravanje podataka kao i integrititeta podataka. Pristup podacima preko Windows DNA naziva se
Universal Data ACCess (UDA). UDA je skup modela sistemskog i aplikacionog nivoa zvanih
OLE-DB, ADO i RDO.
Prvi poetak razvoja COM+ objekata datira jo od 1992 god. kada je Microsoft razvio OLE (Object
Linking and Embedding) koji je kasnije (1995) nazvan COM (Component Object Model). 1996 COM
poinje sa podrkom distribuiranog procesiranja i dobija ime DCOM (Distibuted COM). Istovremeno
Microsoft razvija novi transakcioni server koji dobija naziv Microsoft Distributed Transaction
Coordinator (MTDC) koji je 1997 unapreen u Microsoft Transaction Server (MTS). 1997 Microsoft
razvija jo jedan server koji dobija ime Microsoft Message Queue Server (MSMQ). Nakon svih ovih
proizvoda, 1999, Microsoft kombinuje sve dotada razvijene servise u integrisano runtime okruenje
COM+. Drugim reima, COM+ je integrisano okruenje koje programerima obezbeuje pristup COM,
MTS, MSMQ i drugim servisima. Na prvi pogled moglo bi se rei da je COM+ kombinacija COM-a i
MTS-a, no COM+ je mnogo vie od toga. COM+ je proirena verzija COM-a sa dve glavne razlike.
Prvo on ukljuuje proirenu i nadgraenu verziju MTS-a MTS 3, i etiri glavna servisa ukljuujui
MSMQ, Load Balancing, Event Services i IMDB. Sve ove komponente i servisi rade zajedno radi
obezbeivanja integrisanih enterprise reenja. Na kraju, moe se rei da COM+ predstavlja:
COM+ = COM + MTS (nadgraena verzija) + Servisi
Dakle, COM+ predstavlja jedno integrisano runtime okruenje koje u sebi kombinuje sve do sada
razvijene tehnologije distribuirane obrade od strane Microsofta i to:
- COM objekte,
- MTS (Microsoft Transaction Server)
- MSMQ (Microsoft Message Queue Server) slui da bi se podrao queuing servis, koji
omoguuje klijentu da moe automatski izvriti pozive metoda osim ako komponenta nije
ofline. MSMQ pozive metoda snima i stavlja u redove ekanja automatski uvek kada je
komponenta dostupna. Ovaj servis je naroito koristan za online aplikacije koje se moraju
izvriti do kraja. Na primer online bankarstvo, rezervacija avionskih karata i td.
- Load Balancing koji predstavlja mehanizam za distribuciju klijentskih poziva ka vie servera.
Prva potreba distribuiranih aplikacija je skalabilnost. Drugim reima, mreni saobraaj i broj
klijenata ne sme da utie na perfomanse aplikacije (to je u nemogue u realnim uslovima).
COM+ omoguuje korienje dve vrste load balancing-a dinamiko i statiko. COM+
podrava load balancing na nivou komponenti. Kada klijent uputi zahtev za specifinom
komponentom, prvo se konektuje na load balancing ruter koji sadri informacije o serverima.
Ovaj ruter nakon toga prosleuje zahtev dostupnim serverima. Ako je server dostupan, klijent
dobija instancu komponente na serveru. Najbolja stvar u ovome je da ako server pone da
sputa sistem, COM+ automatski rutira klijentski zahtev ka drugom serveru. Windows 2000
ima ovaj servis i naziva se Clustering service.
- Object pooling je vrsta recikliranja objekata. Kada klijent zavri sa radom sa instancom
komponente, umesto unitavanja instance (oslobaanja memorije zauzete instancom
komponente), COM+ je reciklira. Kada neki drugi klijent uputi zahtev za instancom iste
komponente, COM+ vraa recikliranu instancu. Poto je skup instanci komponente uitan u
memoriju, one su neposredno spremne za korienje od strane klijentskih aplikacija.
- Just-In-Time Activation U COM+ -u kada klijent prosledi zahtev za kreiranje instance objekta,
COM+ obezbeuje da klijent referencira kontekst objekta umesto da referencira objekat.
Klijent dobija referencu na objekat tek kada pozove metodu tog objekta. Ova tehnika se naziva
Just-In-Time Activation (pravovremena aktivacija). Pretpostavimo da imate hiljadu klijenata
koji ele da instanciraju odreenu komponentu ali samo nekoliko od njih eli da da pozove
neku metodu te komponente. U tom sluaju, javio bi se veliki overhead ako bi se kreirale
instance komponente za svakog klijenta.
- Event Services iji je zadatak da obrauje dogaaje izmeu dva objekta. U COM-u, dogaaji
su se mogli obraivati na dva naina, prvi je bio korienje povratnog mehanizma interfejsa
gde klijent implementira neki interfejs koji koristi komponenta. Dogaaji ili notifikacije su tada
bivali inicirani pozivanjem preko klijentskog interfejsa. Drugi nain je Connectable Objects,
27
koji koristi standardni COM IconnectionPoint interfejs. Kada dva modula komuniciraju, jedan
prosleuje informacije a drugi ih prima. U COM+ modul koji prosleuje informacije naziva se
Publisher, a modul koji prima informacije naziva se Subscriber. U COM-u je postojalo
nekoliko problema koji su reeni u COM+ -u:
Publisher i Subscriber su bili tesno povezani zbog potrebe za poznavanjem definicija
interfejsa jedno drugog u vreme kompajliranja .
Dodavanje Publisher-u podrke za multi-kasting ili poveani broj izlaza zahtevalo je mnogo
kodovanja.
Arhitektura je samo opisivala set interfejsa. Programeri su i dalje morali da implementiraju te
interfejse.
Connection point interfejsi su kreirani bez podrke za distribuirana okruenja i nisu bili
efikasni u tim scenarijima.
- IMDB (predstavlja robustan, kratkotrajni i izvrni ke koji poveava performanse distribuiranih
aplikacija). IMDB koristi OLE_DB i ADO i obezbeuje brz pristup podacima koji se nalaze u
bazama podataka. Umesto uitavnja u runtime modu, IMDB uva bazu i keu.
- Role-Based Security predstavlja nain da pridruite razliita prava pristupa komponenti
razliitim korisnicima ili grupama korisnika. Na primer, moete napraviti komponentu koja e
menaderu projekta omoguiti da ita, pie ili menja specifikaciju projekta, dok e programeri
moi samo da itaju specifikaciju. Prava pristupa se mogu odreivati korienjem COM+
kataloga ili programskim putem (programiranjem).

7.2 Common Object Request Broker Architecture (CORBA)
Veliki razvoj PC raunara kao i pad njihove cene, doveo do velikog razvoja mrenih tehnologija.
pocetkom 90-ih godina. Meutim, velika raznolikost umreenih sistema kao to su razliiti hardver
raunara, razliita mrena oprema kao i veliki broj mrenih protokola doveo je do jako oteanog
razvoja mrenih aplikacija. Sa ciljem da premosti jaz izmeu programa koji su bili pisani na razliitim
programskim jezicima, izvravali se na raunarima na kojima su se izvravali razliiti operativni
sistemi, koji su bili povezani preko razliitih mrenih tehnologija koricenjem razliitih mrenih
protokola, nastao je standard CORBA Common Object Request Broker Architecture. CORBA je prvi,
najvaniji i pre svega najambiciozniji middleware projekat pokrenut u istoriji. Proizvod je
konzorcijuma OMG (Object Management Group) koji broji preko 700 clanova (to pojedinaca to
velikih softverskih kompanija). CORBA je papir, tj. specifikacija na preko hiljadu strana. Prva
specifikacija CORBA modela datira od 1991 god. i do danas je doivela nekoliko razliitih verzija.
CORBA je bila veoma popularna sredinom devedesetih, pre nagle ekspanzije Internet-a. OMG je sporo
reagovao (pre svega zbog velikog broja lanova) i nisu na vreme odgovorili na zahteve trita koje se
preorijentisalo prema WEB-u i zbog toga su bili pregaeni. Razlozi zbog kojih CORBA nije postala
ono za ta je bila namenjena lee u sledeim injenicama:
- skup razvoj aplikacija
- CORBA je esto suvie komplikovana
- mnoge implementacije su pune raznih propusta (bug-ovi, sigurnosne rupe, itd.)
Meutim, sigurno je da je glavni razlog polakog posustajanja CORBA-e nedovoljno brzo praenje
zahteva trita. Tritu je bio potreban otvoren standard koji bi omoguio komunikaciju izmeu
razliitih aplikacija kroz otvoreni Internet. CORBA komunikacija koristi vie portova i zato ne prolazi
kroz zatitne zidove (firewall). Bez obzira to su CORBA poruke bile binarne i iz tog razloga su se
prenosile jako brzo, prva tehnologija koja je znaajnije zapretila CORBA-i je bila SOAP (Simple
Object Access Protocol), koji je izdat 1999. godine. SOAP koristi XML poruke koje se lako prenose
Internet-om i itljive su i za raunare i za ljude. Iako su XML poruke tekstualne, to znai da koliina
prenetih podataka nije optimalna, SOAP je brzo nadirao zbog lakoe upotrebe i lakog prolaenja kroz
Internet (korienjem HTTP protokola bez problema prolazi kroz veinu firewall-ova).
Sledei dogaaj koji je isto doprineo gubitku trinog uceca je bio kada se 2000. i 2001. izduvao
Internet balon i kada su mnoge kompanije koje su koristili CORBA-u nestale sa trita. Danas CORBA
ima jako mali deo trinog ucea, bez obzira na njene mnogobrojne pozitivne karakteristike.
28

CORBA je nezavisna od jezika i implementirana je na veem broju platformi nego COM. Meutim,
postoje nekompatibilnosti izmeu implementacija razliitih proizvoaa. CORBA predstavlja object
bus koji omoguava klijentu da poziva metode sa objekta na serveru uz nezavisnst programskog jezika
i lokacije objekta. Interakcija je omoguena preko ORB (Object Request Brokers) komponenata na
klijentu i na serveru a komunikacija se odvija preko IIOP (Internet Inter-ORB Protocol). Mogunosti
CORBA objekata definisane su pomou IDL (Interface Definition Language).
Ve smo rekli da CORBA predstavlja industrijski standard koji je definisao OMG (Object
Management Group). OMG pokuava da pretvori u stavrnost ideju o mogunosti da se komponente
softvera mogu koristiti ako su ve jednom napisane, ili da se mogu kupiti gotove od drugih
proizvoaa. Ovaj standard definie interfejs koji bi trebalo da omogui da komponente napisane u
razliitim jezicima meusobno sarauju. To je ostvareno definisanjem seta metoda koje su vidljive za
ostale komponente. Od poetka se polo sa predpostavkom da komponente mogu da budu postavljene
na razliitim vorovima u mrei. Bez obzira da li su na istom serveru ili su distribuirane kroz mreu,
komponente komuniciraju zahvaljujui uslugama ORB (Object Request Broker). Klijent i server
komponente slobodno komuniciraju kroz mreu i pozivaju udaljene funkcije. To je upravo ono to je
neophodno za ostvarenje koncepta aplikativnog servera kao srednjeg sloja u kome izvrenje posla
aplikacije zavisi od ispunjenja zahteva upuenog serveru koji je zaduen za logiku aplikacije. CORBA
dakle predstavlja model koji potpuno podrava ideju troslojne arhitekture, koja po prirodi ima
aplikaciju distribuiranu izmeu klijenta, aplikativnog servera i servera baze podataka. Ve smo
napomenuli da sve koponente u arhitekturi CORBA komuniciraju putem ORB-a. ORB ima
mehanizam za poziv udaljenih procedura (RPC), kojim za komponente potpuno maskira mreu i sve
komunikacione tehnologije ispod, ime omoguava da se pozivi funkcija vre kao da su lokalni bez
obzira gde se nalaze. Ni klijent ni server na taj nain vie ne moraju brinuti o lokaciji, jeziku na kome
je komponenta pisana niti o nainu na koji se vri transport podataka kroz mreu. ORB moe biti
implementiran kao proces na host-raunaru kome klijent pristupa, kao proces na nekom centralnom
raunaru kroz koji klijent i server komuniciraju, ili kao servis operativnog sistema. U komunikaciji se
koristi IIOP protokol (Internet Inter-ORB Protocol) a za definiciju interfejsa izmeu dva CORBA
objekta koristi se IDL (Interactive Development Language) specifikacija tj. interaktivni generator
programa. IDL specifikacija je kompajlirana pomou IDL kompajlera u svakom ciljnom jeziku i on
treba da omogui impementaciju svih ovih metoda koji treba da budu potpuno nezavisno od vrste
interfejsa. Ovde je jezik vezan za razliite programske jezike (C, C++, Java, Smalltalk, Ada95,
COBOL ). Ako je potrebno najednostavnije definisati CORBA specifikaciju moe se rei da ona
predstavlja mogunost da se na jednom desktop raunar omogui da mogu da se razmenjuju objekti
koji se nalaze na raunarima u mrei bez obzira na hardversku i softversku platformu na tim
raunarima. Drugim reima mogue je da neki tekst procesor koji se izvrava na windows desktop
raunaru ukljui u okviru sebe neku grafiku koja se generisala na nekom LINUX raunaru koji se
nalazi u mrei.
Primena
CORBA je specifikacija koja teoretski dozvoljava da dva CORBA programa komuniciraju bez ikakvih
promena iako su:
- pisana na razliitim programskim jezicima (npr. C++ i Java)
- izvravaju se na razliitim operativnim sistemima (npr. Windows i UNIX)
- koriste razliite mrene protokole (npr. TCP/IP i Modbus)
- izvravaju se na razliitom hardveru (npr. Intel 32 bitni procesori i Alpha procesori)
- koriste razliite mrene tehnologije (npr. 100 Mbps Ethernet i token ring mrea)
Na ovako sloene zahteve CORBA odgovara tako, to se useli izmeu operativnog sistema i
aplikacije i sakrije sloenost operativnog sistema (a zajedno sa OS-om sakriva sloenost mrenih
protokola, hardvera raunara i mrenog hardvera). CORBA je izbor onih, kojima je potrebna brzina i
nezavisnost od isporuioca hardvera, proizvoaa operativnog sistema i/ili mrene tehnologije. Oni
koji se odlue za CORBA-u ne moraju da trpe politiku proizvoaa kada doe do prelaska na sledeu
verziju operativnog sistema/hardvera. Kada odreeni OS ili hardver postane nedostupan, CORBA
29
bazirane aplikacije se uz neznatne modifikacije mogu preneti na drugi hardver/operativni sistem. Kod
CORBA-e se podaci prenose binarno. Ovakav tip prenosa je puno bri od prenosa tekstualnih sadraja
(npr. XML poruke kod SOAP-a). CORBA danas jedino na tritu embedded sistema ima porast
trinog ucea. Sem te oblasti postoje instalacije u:
- rezervacije avio karata
- komunikacija izmeu e-commerce aplikacija
- telefonskim kompanijama (transakcije)
- finansijskim sistemima
I mplementacije
Kao to je vec ranije reeno, CORBA je samo papir, tj. specifikacija na vie od hiljadu stranica
teksta. Ova specifikacija je bila ispred svog vremena kada je izala (poetkom devedesetih godina
dvadesetog veka) i softverska zajednica je sa entuzijazmom prihvatila ovaj novi standard. Krenulo se u
pisanje veeg broja implementacija. Implementacija je fizika realizacija CORBA specifikacije koja
radi na jednom ili vie operativnih sistema i/ili na odreenoj hardverskoj platformi. U poznatije
CORBA specifikacije spadaju omniORB 2.6, TAO 3.0, ORBit2 2.4, MICO 3.0, IIOP.NET 2.3,
Visibroker 2.6 i orbacus 2.6.
Arhitektura

Slika 7.1. Opta arhitektura CORBA-e
Prikazana slika je relativno loa, ali se najvaniji elementi lepo vide:
- Object impl server. Preciznije: serverski objekat
- Client klijent, koristi usluge servera
- Object Request Broker sloj koji sedi na operativnom sistemu i sakriva njegovu sloenost
- ORB Interface API preko koga i klijent i server pristupaju ORB-u
- IDL Skeleton kod dobijen prevoenjem IDL-a. Mapiranje tipova (tzv. marshaling) i bazne
klase koje serverski objekat treba da implementira
- IDL Stubs poput IDL Skeleton-a, slui za mapiranje tipova
- Object adapter povecava portabilnost serverske implementacije jer omoguava pisanje koda
servera koji je nezavisan od koricene CORBA implementacije
Postoje dve verzije object adapter-a:
- BOA (Basic Object Adapter) i
- POA (Portable Object Adapter)
POA je novijeg datuma i prakticno razdvaja implementaciju serverskog objekta od objekta koji
obraduje zahteve (servant). Od svih objekata sa slike 1., programer koji radi na razvoju CORBA
aplikacije pie samo klijenta i implementaciju serverskog objekta.

Enterprice J ava Beans (EJ B)
Predstavlja distribuirani, transakcioni, serverski komponentni model. EJB nije proizvod ve
specifikacija koju je izdao Sun Microsystems za Java Platformu. EJB je nezavisna od platforme, ali ne
i od jezika. Svi EJB objekti moraju biti napisani u jeziku Java. Za komunikaciju izmenu razliitih
30
sistema, EJB koristi varijantu IIOP nazvanu RMI preko IIOP (Remote Method Invocation over IIOP).
Daljinsko pozivanje metoda (RMI)
Pre nego to preemo na objanjavanje EJB specifikacije potrebno je objasniti RMI Remote Method
Invocationss metod udaljenog poziva). Neto slino kao to je RPC (Remote Procedure Call) u
klijent server modelu to je RMI u Java modelu. On omoguava Java Java komunikaciju i pozivanje
metoda iz udaljenih Java aplikacija od strane Java apleta, Java IDL jezika (jezik kojim se definiu
interfejsi po CORBA standardu i preko ORB-a (Object Request Broker) pozivaju metode u
programima napisanim u bilo kom programskom jeziku koji podrava CORBA standard) i JDBC (Java
DB Connectivity) koji predstavlja veoma monu tehnologiju u upravljanju bazama podataka tj. to je
prvi standardizovan set objekata i metoda za interakciju sa bazama podataka i predstavlja sastavni deo
Java Entrprise API-a.. RMI mehanizam vam omoguava da uradite neto to zvui jednostavno. Ako
imate pristup objektu na drugoj maini, moete da pozovete metodu udaljenog objekta. Naravno,
parametri metode moraju nekako biti prosleeni drugoj maini, server mora biti obaveten da izvri
metodu, i povratna vrednost mora biti vraena nazad. RMI rukuje ovim detaljima. Na primer, klijent
traei informaciju o nekom proizvodu moe da postavi upit Warehouse objektu na serveru. On poziva
udaljenu metodu, find, koja ima jedan parametar: Customer objekat. Metoda find vraa objekat
klijentu: Product objekat (slika 7.2).

Slika 7.2
U RMI terminologiji, objekat ija metoda pravi daljinski poziv se naziva klijentski objekat. Daljinski
objekat se naziva serverski objekat. Vano je zapamtiti da se klijent/server terminologija odnosi na
samo jedan poziv metodi. Raunar na kome se izvrava Java kod koji poziva udaljenu metodu je
klijent samo za taj poziv, a raunar koji sadri objekat koji obrauje poziv je server samo za taj poziv.
Skroz je mogue da se uloge kasnije obrnu. Server prethodnog poziva moe i sam da postane klijent
ako pozove daljinsku metodu objekta koja se nalazi na drugom raunaru.
RMI je protokol rezervisan samo za Javu.. Sve ove tehnologije pruaju jaka sredstva za pisanje
distribuiranih, vieslojnih i viekorisnikih klijent server aplikacija za pristup relacionim bazama
podataka. Java programeri su dobili snano orue koje im omoguava da primene koncept nezavisna
platforma-nezavisna baza. Java apleti i aplikacije sada mogu podjednako lako pristupati bilo kojoj
bazi podataka na bilo kojoj platformi. Iako je u nazivu JDBC pomenuta baza podataka ona ne
predstavlja bazu podataka u uem smislu rei. Naprotiv ona predstavlja mnogo iri pojam kao to su
oblik, lokacija ili organizacija podataka. Korienjem odgovarajueg drajvera omogueno je da se
31
podaci koji se dobijaju iz klasine baze podataka ili iz audio-video signala sa satelita, potpuno isto
tretiraju i obrauju.
Za razliku od RMI tehnologije ija je implementacija sastavni deo Java jezika, EJB specifikacija ne
proiruje nijednu odreenu implementaciju, ve dozvoljava proizvoaima da sami prave sopstvene
implementacije. Specifikacija je dovoljno precizno definisana tako da obezbedi da se softver koji
koristi EJB tehnologiju moe instalirati u razliita EJB okruenja bez modifikacije. Dobra strana je to
ovakav pristup omoguuje da se poslovna logika potrebna aplikaciji moe razvijati bez potrebe da se
brine o okruenju u kome e se ona izvravati. Sana EJB specifikacija definie model serverskih
komponenti za razvoj vieslojnih arhitektura sa distribuiranim objektima. Vano je primetiti da se EJB
ne bavi klijentskom stranom ve definie okruenje u kome ive EJB komponente. EJB arhitekturu
ine EJB server i EJB kontejner. Funkcije EJB servera i kontejnera nisu strogo razdvojene. U principu
je zamiljeno da EJB server i kontejner budu nezavisni jedan od drugog to bi omoguilo izgradnju
EJB okruenja kombinovanjem komponenti razliitih proizvoaa. Za sada u praksi to nije mogue
tako da svaki proizvoa nudi svoj par server/kontejner koji se ne moe razdvojiti.
JDBC je otvorio velike mogunosti komunikacije sa bazama podataka preko Intraneta i Interneta. U
saradnji sa RMI i CORBA, primena JDBC u vieplatformskom i viebaznom okruenju postaje
praktino neograniena. Koristei sigurnosne mehanizme Jave, sistem postaje veoma upotrebljiv na
Internetu, pa zato i ne udi pojava velikog broja baza podataka na WEB-u. Ovakva tehnologija
omoguava da zaposleni nosei svoj notebook sa Java enabled browser-om, pristupaju podacima iz
baza svoje kompanije sa bilo koje take na planeti, to je otvorilo nesluene poslovne mogunosti.
Podatak da se danas u svetu najvie trae programeri sa znanjem COM+, JDBC, RMI i CORBA
tehnologija dovoljno govori u kome e se pravcu razvijati distribuirano upravljanje bazama podataka.
Enterprise JavaBeans 3
EJB predstavlja jednu od nekoliko Java API specifikacija za Java EE platformu. EJB standard
definie model serverskih komponenti koje enkapsuliraju poslovnu logiku i koriste se za modularan
razvoj vieslojnih arhitektura sa distribuiranim objektima. EJB specifikaciju originalno je razvio 1997.
godine IBM, da bi njen dalji razvoj preuzeo Sun Mycrosistems (EJB 1.0 i 1.1). Kasnije verzije EJB
specifikacije razvijane su kroz JCP (Java Community Process) i definisane su odgovarajuim JSR
dokumentima (EJB 2.0 JSR 19, EJB 2.1 JSR 153, EJB 3.0 JSR 220). Aktuelna verzija, EJB 3.0,
kompletirana je 2006.godine a na njenom razvoju radila je ekspertska grupa koju ine Sun, IBM,
Apache, BEA Systems, Oracle, Sybase i drugi.
EJB 3.0 specifikacija podeljena je u tri dela:
1. EJB osnovni zahtevi dokument koji definie interfejse isporuioca servisa (SPI Service
Provider Interface) izmeu instance bean-a i kontejnera, protokole, veze kontejnera i
komponenata, razne servise koje kontejner treba da obezbedi bean-u, i druge detalje vezano za
razvoj i pakovanje svih vrsta EJB komponenti.
2. EJB 3.0 pojednostavljen API dokument koji predstavlja prirunik za upoznavanje sa onim
delovima prethodnih verzija EJB specifikacije koji su znatno uproeni u cilju lakeg razvoja i
korienja EJB komponenti.
3. JPA (Java Persistence API) dokument koji specificira razvijanje i manipulisanje
perzistentnim entitetima koje karakterie POJO (Plain Old Java Objects) stil. Iako je JPA
sastavni deo EJB specifikacije, izvesno je da e se njen dalji razvoj u budunosti odvijati
nezavisno, obzirom da se perzistentni entiteti mogu koristiti u bilo kojoj vrsti Java aplikacija,
ne samo u EJB aplikacijama.
Kako je EJB rezultat sporazumnog razvoja standardnog naina kreiranja i korienja serverskih
distribuiranih komponenti, u kom su uestvovali i brojni proizvoai aplikacionih servera, EJB
komponente se mogu izvravati na gotovo bilo kom aplikacionom serveru. Drugim reima,
proizvoai aplikacionih servera su implementiranjem EJB specifikacije odabrali da osiguraju svoje
poslovanje pruajui vii nivo kvaliteta, umesto vezivanja korisnika za svoje proizvode
nestandardnim, proizvoakim servisima komponenti.
32
EJB specifikacija definie arhitekturu serverskih komponenti za sloj poslovne logike.
Komponenta se u ovom kontekstu moe opisati kao zatvoren entitet koji se moe uvek iznova koristiti
od strane iste, ili potpuno druge aplikacije, sve dok su zadovoljena pravila semantike. Komponenta
mora biti spakovana zajedno sa svim potrebnim informacijama kako bi mogla da prui nezavisnu
postojanost izvan okvira originalne aplikacije, sa mogunou viestruke upotrebe. Poslovna ili
sistemska aplikacija se zatim moe realizovati tako da sadri brojne softverske kompenente koje su
portabilne, mogu se koristiti vie puta i od kojih je svaka zaduena za obezbeivanje odreene
funkcionalnosti.
EJB komponente su serverski orijentisane, namenjene za izvravanje sloenih algoritama ili
sigurno izvoenje transakcionih operacija. Serverske komponente se izvravaju u okruenjima koja
moraju biti raspoloiva (24x7), otporna na greke, transakciona, viekorisnika i sigurna. Aplikacioni
serveri obezbeuju takvo okruenje za EJB komponente, kao i servise potrebne za njihovo
funkcionisanje.
Korienje EJB komponenti na vie naina pojednostavljuje razvoj velikih, distribuiranih
aplikacija. Na prvom mestu, obzirom da EJB kontejner obezbeuje servise sistemskog nivoa bean-u
(kao to su upravljanje transakcijama i sigurnosni servisi), programer moe da se fokusira na reavanje
problema vezanih za poslovnu logiku. Kao drugo, poto bean-ovi sadre pravila poslovne logike, a ne
klijenti, programer klijentske aplikacije moe da se usredsredi na prezentacioni aspekt. Kao rezultat,
klijent je veoma rastereen to je veoma bitno za klijentske aplikacije koje su ugraene u razne vrste
ureaja sa ogranienim resursima (npr. mobilni telefon, palm top). Najzad, budui da su EJB
komponente prenosive, nove aplikacije mogu koristiti postojee bean-ove. Ove aplikacije se mogu
izvravati na bilo kom Java EE-kompatibilnom serveru koji implementira standardne API
specifikacije.
Tipino, EJB komponente izvravaju sledee zadatke:
Implementacija poslovne logike na primer, slanje konfirmacionog mejla prilikom potvrde
narudbine, putem JavaMail APIa; izraunavanje trokova u online kupovnoj listi; utvrivanje
privilegija menadera pri pokuaju odobravanja narudbine.
Pristup bazi podataka na primer prilikom poruivanja knjiga, transfera novca izmeu dva
bankovna rauna, ili pozivanja memorisane procedure. Jedan od mnogih naina pristepena bazi
podataka posredstvom EJB komponenti je i korienje JDBC interfejsa.
Integracija sa drugim sistemima na primer pozivanje transakcionog CICS sistema (Customer
Information Control System) pisanog u C jeziku za utvrivanje izloenosti riziku novom
korisniku osiguranja.
1.1. Vrste EJ B komponenti
Postoje dve vrste EJB komponenti - session i message-driven, dok je trea vrsta koja je bila
definisana u okviru ranijih verzija EJB specifikacije kao EJB entity komponente, danas opisana JPA
specifikacijom kao izdvojena celina pod jednostavnim imenom - entiteti. Definisanje neke komponente
na jedan od ovih naina je deklarativno dovoljno je u konfiguraciji komponente napisati kojoj vrsti
pripada. U nastavku teksta na poetku je dat kratak opis EJB komponenti koje su orijentisane na
poruke, a detaljnije se opisane session komponente i entiteti.
1.1.1. EJB komponente orijentisane na poruke
Komunikacija putem poruka predstavlja alternativu RMI protokolu. Razmena poruka se vri
preko dodatnog meusloja (MOM - Message Oriented Middleware) izmeu poiljaoca i primaoca
poruka. Poiljaoc je nakon slanja poruke slobodan da nastavi sa drugim zadacima, dok se srednji sloj
brine o samoj isporuci poruke primaocu. Na primer, prilikom online kupovine knjiga, mogue je
nastaviti sa pretraivanjem sajta tokom procesa autorizacije kreditne kartice. Ukoliko se proces zavri
regularno, kupac e biti obaveten o uspenoj narudbini konfirmacionim mejlom.
33
Vrsta EJB komponenti koja je orijentisana na poruke (MDB Message-Driven Beans)
kombinuje funkcionalnost session komponenti sa JMS (Java Messaging Service) oslukivaem,
omoguavajui na taj nain asinhronu razmenu poruka izmeu EJB komponenti.
Klijentima nije omoguen pristup MDB bean-ovima putem poslovnog interfejsa, zapravo, ne
postoji nain da klijent uopte identifikuje MDB bean i ostvari komunikaciju sa njim. Jedini nain
interakcije klijenta sa bean-om jeste kroz srednji sloj baziran na porukama, kao to je JMS. Zalihama
MDB instanci upravlja EJB kontejner, koji prima poruke od srednjeg sloja i dodeljuje ih slobodnim
bean-ovima.

slika 1. ivotni ciklus MDB komponente
ivotni ciklus MDB instance ukljuuje dva stanja: stanje kada instanca jo ne postoji (Does Not
Exists) i stanje kada se instanca nalazi u zalihama i spremna je za korienje (Ready). Kontejner moe
odluiti da, u cilju utede resursa, ukloni neki bean iz zaliha pozivanjem metode remove().
1.1.2. EJB session komponente
Session komponente generalno reprezentuju akcije u poslovnom procesu. One predstavljaju
privremenu komunikaciju sa klijentom, i implementiraju pravila poslovne logike, na primer u sluaju
bankarskih transakcija, narudbina, kontrole zaliha ili operacija nad bazom podataka. Mogu se koristiti
samo od strane jednog klijenta u istom trenutku, a po zavretku sesije, session bean sa svim svojim
podacima nestaje. Session komponente mogu biti realizovane na dva naina: session komponente bez
stanja i session komponente sa stanjem.
Session komponente bez stanja (Stateless Session Bean) predstavljaju distribuirane objekte koji
nemaju pridruene podatke o stanju, stoga dozvoljavaju konkurentan pristup. Ouvanje vrednosti
atributa u okviru jedne instance nije garantovano, ali je memorijsko premaenje tokom odravanja
veze sa pozivajuom aplikacijom znatno manje u odnosu na session komponente sa stanjem. Na
primer, prilikom verifikacije kreditne kartice, bean zaduen za verifikaciju e prvo uzeti podatke o
broju kartice, roku vaenja kartice, nosiocu kartice i iznosu na kartici. Zatim e nakon provere, bean
vratiti da/ne odgovor, zavisno od validnosti kreditne kartice. Po okonanju ovog zadatka, bean je
slobodan da uslui narednog klijenta i nema vie nikakve podatke o prethodnom.
Obzirom da nijedan atribut instance ne uva klijent-specifine podatke, EJB kontejneru je
omogueno da kreira zalihu (pool) session bean-ova. Zbog ove osobine, session komponente bez
stanja su izuzetno skalabilne u sluaju velikog broja korisnika, a takoe obezbeuju i dobre
performanse poto ne postoji potreba da kontejner pomera bean iz memorije i skladiti podatke na
disku.
ivotnim ciklusom session bean-ova upravlja kontejner, a na slici 14 je prikazan ivotni ciklus
jedne session komponente bez stanja.
34

slika 2. ivotni ciklus session komponente bez stanja
Postoje samo dva stanja u sluaju session komponente bez stanja: stanje kada instanca ne postoji
(Does Not Exists) i stanje kada je instanca spremna za korienje (Ready). Nakon to kontejner kreira
novi bean pomou metode newInstance(), on poziva metode za postavljanje okruenja unutar bean-a
setSessionContext(). Time je omoguena tranzicija u drugo stanje, kada je bean spreman za korienje.
Klijent onda moe koristiti poslovne metode bean-a. Kontejner poziva preDestroy() metodu kada
instanca vie nije potrebna, to ima za posledicu povratak bean-a u poetno stanje (radi jasnije analize
ivotnog ciklusa, uloga pool-a bie zanemarena).
Session komponente sa stanjem (Stateful Session Bean) sadre i podatke o stanju, odnosno prate
sa kojom aplikacijom interaguju tokom sesije i pamte svoje stanje izmeu poziva od strane istog
klijenta. Kontejner skladiti i obnavlja session komponente sa uspostavom stanja prilikom pomeranja
iz radne u dugotrajnu memoriju. Zbog ovih osobina, EJB komponente sa stanjem unose vee
premaenje u sistem i manje su skalabilne od stateless bean-ova. Tipina primena ovog tipa session
komponenti je prilikom online kupovine, gde svaki kupac ima svoj nalog i pri svakom prijavljivanju,
detalji o njegovoj korpi za kupovinu se od strane bean-a povlae iz baze.

slika 3. ivotni ciklus session komponente sa stanjem
Sa slike 15 se vidi da ova vrsta session komponenti ima i tree stanje stanje kada je bean
pasivan (Passive). Tranzicija iz stanja Ready u stanje Passive deava se kada kontejner perzistira
podatke iz bean-a u sekundarnu memoriju a sam bean smesti u pool, pozivanjem metode
35
prePassivate(), u cilju oslobaanja resursa. Kada klijent ponovo pozove neku od poslovnih metoda tog
bean-a, kontejner obnavlja sadraj bean-a a zatim ga, pozivanjem metode preActivate()budi iz
pasivnog stanja i bean je ponovo spreman da opslui zahteve klijenta.
1.2. EJ B kontejner
EJB komponente smetene su unutar kontejnera na aplikacionom serveru. Specifikacijom je
definisan nain na koji se obavlja interakcija izmeu EJB komponente i njenog kontejnera, kao i
interakcija klijentskog koda sa kontejnerom. Najvanija funkcija kontejnera jeste da obezbedi sigurno,
distribuirano, transakciono okruenje koje je kao takvo pogodno za egzistenciju EJB komponente
unutar njega. EJB kontejner se ponaa kao posrednik izmeu klijenta i bean-a. Zahvaljujui
kontejneru, bean je potpuno izolovan u odnosu na klijenta i ne moe mu se direktno pristupiti. Kada
klijentska aplikacija pozove udaljenu metodu EJB komponente, kontejner je prvo presree kako bi
utvrdio da su pravila vezana za perzistenciju, transakcije i sigurnost adekvatno primenjena na svaku
operaciju koju klijent eli da izvri.
Kontejner vodi rauna o vie bean-ova istovremeno, na slian nain kao to Web server
opsluuje vie servleta. Kada bean nije u upotrebi, kontejner ga smeta u pool kako bi mogao da ga
koristi novi klijent. EJB komponenta u potpunosti zavisi od kontejnera; na primer, ukoliko joj je
potrebna JDBC konekcija ili servis koji prua druga EJB komponenta, kontejner e joj to obezbediti.
EJB komponenta komunicira sa kontejnerom na tri naina: pozivanjem callback metoda, pomou
EJBContext interfejsa, ili JNDI interfejsa.
Callback metode. Svaki session bean moe da implementira EnterpriseBean interfejs koji
definie razne callback metode. Svaka od ovih metoda obavetava bean u trenucima kada
dolazi do promena stanja u njegovom ivotnom ciklusu, a kontejner ih poziva kako bi
obavestio bean da se sprema da ga aktivira, perzistira njegovo stanje u bazi podataka, zavri
transakciju, ukloni ga iz memorije. Callback metode omoguavaju bean-u da zavri poslove
koji su u toku, pre ili nakon dogaaja koji sledi.
EJBContext. Svakom bean-u se pridruuje EJBContext objekat, koji predstavlja njegovu
direktnu vezu sa kontejnerom. Interfejs EJBContext obezbeuje metode za interakciju sa
kontejnerom tako da bean moe putem njih zahtevati informacije o svom okruenju, na primer
informacije o klijentu, ili status transakcije.
JNDI interfejs predstavlja standardno proirenje Java platforme za pristup imenovanim
servisima kao to su LDAP, NetWare, sistemi datoteka itd. Svaki bean automatski ima pristup
specijalnom imenovanom sitemu ENC (Environment Naming Context). ENC sistemom
upravlja kontejner a bean mu pristupa putem JNDI interfejsa. JNDI ENC omoguava bean-u da
pristupa resursima kao to su JDBC konekcije, druge EJB komponente, i specijalna osobine i
servisi koje pruaju te komponente.

36
slika 4. EJB kontejner sa pripadajuim EJB komponentama razliitih vrsta
Poslovni (business) interfejs navodi metode koje nudi EJB komponenta, kako bi one bile vidljive
klijentima. Zavisno od lokacije klijenta, business intefejs se dalje moe podeliti na lokalni i udaljeni.
1.3. Entiteti i menader entiteta
Entiteti predstavljaju perzistentne objekte koji ne nestaju po zavretku komunikacije sa
klijentom, i vie klijenata moe istovremeno deliti jedan entitet. ivotni vek im je vezan za ivotni vek
podataka koji predstavljaju, a ne aplikacije koja ih koristi. Njima su tipino predstavljeni podaci
uskladiteni u jednom redu tabele u bazi podataka. Takoe, entiteti imaju atribute za potrebe
identifikacije (koji odgovaraju primarnim kljuevima u tabeli) koji mogu biti prosti ili sloeni, a mogu
imati i definisane veze sa drugim entitetima. Poslovna logika implementirana kroz session
komponente, a uz pomo servisa za perzistenciju, vodi rauna da podaci iz entiteta budu trajno
sauvani.
U okviru JPA dela EJB 3 specifikacije koji se bavi entitetima i nainom njihove perzistencije,
definisani su interfejsi neophodni za izvoenje operacija nad entitetima. Entiteti se razlikuju od EJB
komponenti po tome to reprezentuju podatke koji se skladite u bazi. Takoe, entiteti se mogu
koristiti i u J2SE aplikacijama, za razliku od session ili MDB bean-ova. Menaderu entiteta, koji
implementira potrebne interfejse za perzistenciju definisane JPA specifikacijom, delegirani su svi
zadaci vezani za kreiranje, itanje, izmenu i brisanje entiteta. Bez menadera, entitet nije nita drugo
do regularan, plain old, Java objekat (POJO), dok sam menader predstavlja instancu klase
EntityManager.
Kada menader entiteta referencira jedan entitet, za taj objekat se kae da je upravljan (managed)
od strane menadera. Set upravljanih instanci entiteta pod nadlenou jednog menadera u datom
trenutku predstavlja kontekst perzistencije (persistence context). U jednom vremenskom trenutku
samo jedna Java instanca sa istim identifikatorom moe postojati u okviru konteksta perzistencije.
Interfejs EntityManager obezbeuje metode za tri tipa opracija:
upravljanje ivotnim ciklusom entiteta,
sinhronizacija sa bazom podataka,
pretraga entiteta i izvravanje upita.
1.3.1. Upravljanje ivotnim ciklusom entiteta
ivotni ciklus jedne instance entiteta odreen je sa dva glavna aspekta koji se odnose na vezu
instance sa specifinim kontekstom perzistencije, i sinhronizaciju stanja instance sa stanjem u bazi
podataka. Menader entiteta razlikuje etiri stanja u ivotnom ciklusu entiteta:
Nova instanca (New). Instanca entiteta je kreirana u memoriji ali joj jo uvek nije dodeljen
identifikator ili kontekst perzistencije. U ovom trenutku stanje entiteta jo uvek nije
sinhronizovano sa stanjem u bazi i menader ne zna za postojanje novog entiteta.
Upravljana instanca (Managed). Entitet poseduje identifikator i kontekst perzistencije. Promene
na entitetu e biti sinhronizovane sa bazom kada se transakcija uspeno izvri (commited) ili u
sluaju eksplicitno zahtevane sinhronizacije pomou flush() operacije. Entitet dolazi u
upravljano stanje na mnogo naina: pozivima persist(), merge() ili refresh() metoda, kao i u
sluaju da je entitet rezultat pretrage ili upita.
Neupravljana instanca (Detached). Entitet i dalje poseduje identifikator ali nije vie asociran sa
kontekstom perzistencije i menader vie njim ne upravlja.
Uklonjena instanca (Removed). Entitet je jo uvek vezan za kontekst perzistencije ali je
rasporeen za uklanjanje iz baze podataka.
37

slika 5. Tranzicije stanja entiteta
Operacijom remove() mogu se rasporediti za uklanjanje iz baze podataka jedino entiteti koji se
nalaze u upravljanom stanju. Pomou ove operacije podaci u bazi se rasporeuju za uklanjanje, to e
se zaista i desiti kada se transakcija uspeno izvri, ili kada se pozove operacija flush().
Pomou operacije merge() mogue je neupravljanim entitetima ponovo dodeliti kontekst
perzistencije. Entitet dolazi u Detached stanje po prestanku postojanja konteksta perzistencije ili kada
se isporui klijentu kao serijalizovan objekat.
1.3.2. Sinhronizacija sa bazom podataka
Izmene na lokalnim entitetima se obino sinhronizuju sa bazom podataka u vreme potvrivanja
transakcije (commit). Meutim, ponekad je vano izvriti sinhronizaciju pre potvrivanja operacija
transakcije. Na primer, izmene entiteta mogu uticati na rezultate upita u okviru iste transakcije. U tom
sluaju, neophodno je obaviti sinhronizaciju pre izvravanja upita.
Izvravanje prevremene sinhronizacije kontrolie se postavljanjem flush reima rada za eljene
metode korienjem anotacija, ili globalno za kontekst perzistencije pomou setFlushMode() operacije.
Dostupne opcije vezane za flush reim rada ukljuuju COMMIT za sinhronizaciju samo u vreme
potvrivanja transakcije, i AUTO za sinhronizaciju stanja entiteta i u vreme potvrivanja transakcije i
pre izvravanja upita.
Operacija flush() obavlja sinhronizaciju stanja svih entiteta u okviru konteksta perzistencije sa
entitetima u bazi ali ne ukljuuje i auriranje lokalnih entiteta na osnovu njihovog stanja u bazi. Za
potrebe auriranja, mora se eksplicitno pozvati operacija refresh().
1.3.3. Pretraga entiteta i izvravanje upita
U cilju identifikacije entiteta koje prethodi referenciranju instance istog, potrebno je ili direktno
adresirati individualan entitet korienjem primarnog kljua, ili izvriti upit koji e kao rezultat vratiti
set entiteta na osnovu zadatih uslova.
Menader entiteta obezbeuje metodu find() za potrebe adresiranja entiteta na osnovu primarnog
kljua. Ova metoda e kao rezultat vratiti upravljan entitet odgovarajue klase u sluaju ispravno
navedenog identifikatora, u suprotnom, rezultat e biti null vrednost.
U veini sluajeva identifikator entiteta nam je nepoznat, ili nam je potrebno vie od jednog
rezultata, ili je neophodno postaviti jedan ili vie uslova za pronalaenje entiteta; odnosno, potrebno je
formulisati upit. Postoje brojni nain za definisanje pretrage koje nudi interfejs EntityManager, ali su
generalni koraci pri tom uvek isti:
pravljenje nove javax.persistance.Query instance od strane menadera,
postavljanje parametara upita i gornju granicu veliine rezultujeeg seta (ako je potrebno),
38
izvravanje upita.
Prvi korak obavlja menader entiteta, dok druga dva koriste Query interfejs. Mogue je odabrati
korienje upita pisane u EJB-QL (EJB Query Language) jeziku ili nativnom SQL-u. EJB-QL je
objektni upitni jezik koji je po sintaksi veoma slian SQL-u. Osnovna razlika izmeu EJB-QL i SQL
jezika jeste u tome to EJB-QL koristi entitete za model podataka i garantuje kompletnu portabilnost
izmeu heterogenih baza podataka. SQL, i pored toga to predstavlja ISO standard, esto ne ispunjava
zahteve portabilnosti usled velikog broja razliitih proizvoakih dodataka i SQL dijalekata koji
postoje.
Postoje dve vrste EJB-QL upita koje se mogu koristiti dinamiki i statiki. Metoda
createQuery() koristi se za kreiranje dinamikih upita, odnosno upita koji su definisani u okviru koda
koji implementira poslovnu logiku aplikacije. Metoda createNamedQuery() slui za upotrebu statikih,
ili imenovanih upita, koji se definiu pomou @NamedQuery anotacije i mogu se pozivati vie puta
pomou imena upita.
Naveden je primer korienja ove dve metode za dobijanje spiska svih radnika:
/* kreiranje dinamikog upita */
Query query = manager.createQuery("SELECT r FROM Radnik r");

/* kreiranje imenovanog upita */
@NamedQuery(
name="sviRadnici",
query="SELECT r FROM Radnik r");

/*pozivanje imenovanog upita*/
radnici = manager.createNamedQuery("sviRadnici");
1.4. Metapodaci
Svakom entitetu su pridrueni metapodaci u odreenoj koliini koji ga opisuju. Ovi metapodaci
omoguuju sloju za perzistenciju da prepozna, interpretira i upravlja na odgovarajui nain entitetom
od uitavanja, preko izvravanja do uklanjanja. Koliina metapodataka koji su zaista neophodni da bi
se opisao entitet je zapravo mala, meutim, kao i u svim sofisticiranim tehnologijama metapodacima je
mogue specificirati sve relevantne detalje. Metapodaci entiteta mogu biti specificirani na jedan od tri
naina pomou XML deskriptora, XDoclet komentara ili pomou anotacija. Uprkos razlikama u
sintaksi mogue je svakim od navedenih pristupa postii isti nivo konfiguracije.
1.4.1. Anotacije
Anotacije predstavljaju osobinu programskog jezika koja omoguava struktuiranim i tipiziranim
metapodacima da budu deo izvornog koda. Pojam anotacija uveden je u Java SE 5, i predstavlja
kljuni deo EJB 3.0 i Java EE 5 specifikacija. One se mogu koristiti kao alternativa standardnim XML
deskriptor fajlovima, ili u kombinaciji sa njima. Definicije metapodatka unutar Java koda
upotrebljavaju se, u razliitim oblicima, od samog nastanka Java jezika. Prvi primer bili su Javadoc
tagovi u okviru komentara koji su se koristili za generisanje API dokumentacije u HTML formatu.
Ideja je bila da se metapodaci nalaze u specijalnom obliku komentara unutar koda, koje zatim posebni
kompajleri ili nezavisni alati obrauju i upravljaju dobijenim informacijama. Najistaknutiji predstavnik
ove tehnike jeste popularni XDoclet alat, koji je zapravo pretprocesor izvornog koda.
Bitno je istai da su u okviru Javadoc/XDoclet pristupa metapodaci smeteni unutar komentara,
to znai da ih ne obrauje Java kompajler. Metapodaci se ne kompajliraju u regularnu klasu i dostupni
su samo u vreme kompajliranja. Sintaksa i semantika metapodataka se ne proverava od strane
kompajlera, to moe uzrokovati kasno otkrivanje greaka.

39
SOAP (Simple Object Access Protocol) je kompletno kreiran na postojeim, proverenim i iroko
prihvaenim tehnologijama kao to su HTTP i XML. SOAP koristi XML za prenos podataka izmenu
aplikacija, a poto je XML univerzalni standard, sve platforme mogu da pristupe i obrade informaciju.
Poto koristi HTTP, jednostavno prolazi kroz port 80, tako da firewall-ovi ne predstavljaju problem.
Pristup razliitim aplikacijama na raznim platformama sa SOAP-om postaje jednostavan, Java
aplikacija na Unix-u jednostavno moe da poziva metode COM objekta na Windows serveru.
Klijentska aplikacija na iMac-u pristupa objektu na mainframe raunaru. Sve ovo postaje transparentno
i ne zahteva bilo kakvu posebnu administraciju. SOAP je moda nekad bio jednostavan, ali je i on
postao kompleksan, dok je prikupljao sve vie osobina koje ima CORBA. XML protokol ima prednost
u tome to je manje vie itljiv za ljude tako da je neto laki za debagovanje. Sa druge strane XML
procesiranje predstavlja svojevrsno usko grlo za performanse. Sve u svemu, CORBA je mnogo
efikasniji, premda je SOAP bolje prilagoen mrenoj arhitekturi. Ako se oba objekta koji komuniciraju
meusobno implementiraju u javi onda je sva uoptenost i kompleksnost CORBA-e ili SOAP-a
nepotrebna. Sun je razvio jednostavniji mehanizam, nazvan Remote Method Invocation (RMI),
specijalno za komunikaciju izmeu java aplikacija.

HTML (HyperText Markup Language)
HTML je jednostavan jezik koji se koristi za izradu hipermedijskih dokumenata od kojih se sastoji
WEB. Temelji se na oznakama (tags) kojima se oblikuje izgled dokumenta koji se sastoje od teksta,
slike, zvuka, filma i drugih meusobno povezanih objekata. Razvijen je poetkom devedesetih godina
na temeljima SGML jezika (Standard Generalized Marup Language) kojim je definisana sintaksa
elemenata za oznake. Evolucijom tehnologija razvijao se i proirivao, pa je od jezika sa statikim
hipertekstualnim osobinama prerastao u jezik pogodan za iterakciju korisnika i WEB servera i prikaz
dinamikih multimedijalnih objekata. Danas razvojem dinamikog HTML-a (DHTML) postaje
nezamislivo kreiranje stranica koje ne sadre dinamike objekte i napredne komponente kao to su
naredbe skriptnih jezika. Upotreba HTML jezika podrazumeva korienje struktuiranih tekstualnih
datoteka u kojima se nalaze podaci i oznake jezika koje prepoznaju odreene aplikacije na strani
klijenta i pravilno ih interpretiraju (na primer WEB itai). Moderni Web itai (Microsoft Internet
Explorer, Netscape Navigator ili Opera) naprednim osobinama diktiraju razvoj HTML i DHTML te
olakavaju interpretaciju i kvalitet stranica. Obogaen ugraenim skript-programima koji se izvravaju
na strani klijenta ili servera, HTML predstavlja odlian jezik za prezentaciju kako strunih i poslovnih
tako i zabavnih sadraja. Ukartko svaki HTML dokument se sastoji od odreenih oznaka (tag) i
tekstualnih podataka. Svaki dokument se sastoji od sekcije zaglavlja i sekcije tela.
<HTML>
<HEAD> </HEAD>
<BODY> </BODY>
<HTML>
XML (eXtensible Markup Language)
Danas, kada funkcionalnost poslovnog softvera u sve veoj meri zavisi od njegove sposobnosti da se
integrie i razmenjuje informacije sa drugim poslovnim softverima, od vrhunskog znaaja je postojanje
i kontinuirani razvoj standarda za razmenu podataka. Ovi standardi postoje da bi komunikaciju i
integraciju poslovnih softvera uinili efikasnom i prepoznatljivom i smanjili napor u implementaciji
odgovarajuih interfejsa. Moe se rei da je tehnoloki razvoj, naroito u segmentu razvoja interneta,
odnosno weba, danas ustanovio jedinstvenu tehnologiju za modeliranje struktura podataka koje se
razmenjuju izmenu poslovnih softvera. Ta jedinstvena tehnologija je XML jezik.


Najednostavnije reeno XML predstavlja proirivi jezik za oznaavanje. To je prost i fleksibilan jezik
zasnovan na SGML-u(Standard Generalized Marup Language). Prestavlja jezik za oznaavanje koji
moe da se pokrene na bilo kojoj platformi, operativnom sistemu ili okruenju i napravljen je tako da
dizajnerima prua mehanizme za bolje opisivanje njihovog sadraja. Prvobitno je razvijen za
izdavake kue i njihove projekte, ali je kasnije razvijen za efikasnu i laku razmenu podataka na
40
Webu. XML to radi na taj nain to dozvoljava dizajnerima da napiu sopstvene definicije tipova
dokumenata (documet type definitions DTD) koje opisuju skupove oznaka i atributa koji mogu da se
koriste za opisivanje specifine vrste sadraja. DTD-ovi su pravila vladanja jezika za oznaavanje koja
definiu koji elementi oznaavanja mogu biti upotrebljeni za opisivanje dokumenata.XML je dovoljno
robustan i proiriv da moe da opie ne samo sadraj ve i metapodatke. Metapodaci su informacije
koje opisuju druge informacije. Primer metapodataka su kataloke oznake knjiga u biblioteci. Svaka
kartica ili stavka u raunarizovanom katalogu jeste informacija koja prua informaciju o drugom
izvoru informacija.Unutar svoje ljuture XML prua ire znaenje opisivanja sadraja dokumenata ili
mehanizma za opisivanje metapodataka, koristei metod koji e raditi na svim raunarima, bez obzira
na platformu i operativni sistem. Na taj nain XML e uiniti da se potroai i proizvoai informacija
lake pronau tj. mnogi poslovi vezani za pretraivanje ili razmenu informacija mogu se
automatizovati pomou XML-a., pruajui opti okvir za predstavljanje informacija.
XML jezik za modeliranje strukture podataka
XML (eXtensible Markup Language) jezik predstavlja standardni nain za modeliranje struktura
podataka u elektronskom poslovanju. Iako je prvobitno namenjen primeni u web aplikacijama, postao
je standard za predstavljanje podataka u poslovnim procesima, prihvaen u potpunosti od strane
najveih proizvonaa softvera i razvojne zajednice. Ideja je bila da se stvori jezik koji e i ljudi i
raunarski programi moi jednostavno da itaju. XML definie optu sintaksu za oznaavanje podataka
pomou odgovarajuih tagova koje imaju poznato ili lako razumljivo znaenje. Format koji
obezbenuje XML za raunarske elemente moe se prilagoditi najrazliitijim oblastima, kao to su
elektronska razmena podataka, uvanje podataka, odvajanje podataka od prezentacije, vektorska
grafika, sistemi glasovne pote, izrada novih specijalizovanih jezika za oznaavanje. Osnovna svrha
XML-a je da olaka deljenje podataka kroz razliite informacione sisteme, posebno kroz one sisteme
koji su povezani sa Internetom. XML je nastao iz potrebe da se same informacije sa HTML strana
fiziki odvoje od naina na koji se prikazuju unutar web strana (dizajna). Sam HTML je zasnovan na
SGML-u (Standard Generalized Markup Language), opirnijem meta jeziku koji je postojao i pre
pojave Web-a. SGML definie gramatiku za sve markup jezike dokumenata. SGML dokumenti nose
svoju gramatiku definiciju sa sobom u obliku Document Type Definition-a (DTD) datoteka. DTD
datoteke definiu sve oznake (tagove) koje se koriste u jednom dokumentu kao i njihovu sintaksu.
Struktura XML datoteke je hijerarhijska sastoji se od otvorenih i zatvorenih tagova, unutar kojih su
drugi tagovi. Tagovi su opisani u DTD (Document Type Definition) datoteci, koja predstavlja
svojevrsnu gramatiku jezika. Za razliku od SGML-a, HTML-a i drugih markup jezika, XML
dozvoljava korisniku slobodno kreiranje gramatike jezika. Iz tog razloga se za formiranje strukture
podataka, mogu koristiti i prirodni jezici. Za tumaenje XML strukture i transformaciju u odrenenu
strukturu podataka, koriste se tzv. parseri, programski moduli, napisani u odgovarajuem jeziku.

Slika 16. Primer XML dokumenta
Iako XML ne zahteva striktnu specifikaciju gramatike dokumenta, dobra je praksa da se ona formira,
da bi odgovarajui parseri mogli da izvre validaciju dokumenta opisanog XML datotekom. Najvanije
prednosti korienja XML standarda za modeliranje podataka u poslovnim web aplikacijama su:
- Samodokumentovanje. Korienje prirodnih jezika za opis strukture podataka. Kriva uenja XML
jezika je mnogo strmija od uenja predstavljanja struktura podataka npr. U relacionim bazama. Jedan
od osnovnih ciljeva XML specifikacije je integrisanje nove tehnologije za opis podataka u najkraem
moguem roku.
- Veliki stepen konzistentnosti sa HTML jezikom jezikom web-a. Poznavanje HTML jezika
dramatino ubrzava usvajanje XML.
41
- XML je danas usvojen kao de fakto i de jure standard za EDI (Electronic Data Interchange).
On omoguava ouvanje konzistentnosti dokumenata prilikom razmene i ukida potrebu za
prevodiocima u i iz razliitih formata.
- XML reprezentacija kompletne baze ili nekog njenog dela moe posluiti za backup, nezavistan
od RDBMS (sistema za upravljanje relacionim bazama podataka), ili za migraciju podataka sa
jednog sistema na drugi (npr. Oracle > SQL Server). Migracija se moe izvesti na dva naina,
pisanjem koda koji e vriti svaku pojedinanu migraciju ili uz pomo takozvanog centralnog XML
hub-a. Prednost centralnog hub-a je u tome da su za dodavanje novog formata baze potrebna samo dva
nova konvertora, dok je istovremeno bez hub-a, za est sistema prikazanih na drugoj slici potrebno 30
filtera.

Slika 17. Backup podataka iz relacionih baza primenom XML-a
- Nezavisnost prikaza XML u odnosu na web browser, kod browser-a koji podravaju XML. U
ovom trenutku, najnovije verzije gotovo svih vodeih browser-a podravaju XML. Ovo je posebno
vano ukoliko je potrebno da se podaci iz baza prezentuju na Internetu, gde postoje razliiti browser-i,
za razliku od korporativnih mrea (intraneta), gde je browser uglavnom unificiran. Trenutno je najei
nain za prikaz XML-a na Internetu korienje XSLT-a (XML Style Language Transformation) za
konverziju XML-a u HTML (simultana konverzija).
42
8 as Klijent server komponente SERVER

ta je to Server ? Sa hardverske strane, najprostiji odgovor na ovo pitanje je da je to raunar koji
istovremeno mogu da koriste vie korisnika, a sa softverske strane Server je bilo koji proces koji
obezbeuje servise za klijente. On je reaktivan jer uvek eka na zahteve klijenta. Ne postoje neka
ogranienja niti neki posebni uslovi koji su potrebni da se neki raunar pretvori u server. Poeljno je da
raunar koji radi kao server bude mnogo snaniji od uobiajenih klijent raunara zato to server
procesi moraju da zadovolje konkurentne zahteve vie klijenata. Ovi raunari obino imaju veu
procesorsku snagu (ne retko i vie snanijih procesora), vei kapacitet operativne memorije i vei
kapacitet diskova nego raunari klijenata.
Ono to opredeljuje da neki raunar bude proglaen serverom predstavlja softver tj. operativni sistem.
Zato se za server bira raunar u zavisnosti od zahteva aplikacije koja treba na njemu da se izvrava. Da
bi jedna klasina klijent server aplikacija mogla da se najbolje izvrava, potrebno je konfigurisati
raunar-server tako da operativni sistem na njemu podrava sledee uslove:
o deljivu memoriju (shared memory),
o nezavisne aplikacije (application isolation),
o multitasking sa pravom preeg prioriteta (preemptive multitasting).
Operativni sistem na serveru mora da omogui i kontrolie da vie korisnika moe istovremeno da
pristupi zajednikim resursima kojima taj server raspolae. On ne sme da dozvoli da se zbog
nedostupnosti nekog resursa, koji je zauzeo neki proces, blokira neki drugi proces i tako stopira
izvrenje tog procesa. Princip prioriteta je jedan od glavnih arbitranih faktora koji stoji na
raspolaganju operativnom sistemu kod odluivanja koliko vremena i kom procesu treba dodeliti neki
resurs. Isti princip je vezan i za deljivu memoriju, s tim da se ovde treba voditi rauna da ne doe do
meanja memorijskog prostora dva ili vie procesa koji se istovremeno izvravaju u memoriji (problem
se jo vie komplikuje ako imamo dva ili vie procesora).
Aplikacije koje se izvravaju na serveru pored toga to dele zajednike resurse moraju da ispunjavaju
i jo jedan uslov: izvravanje jedne aplikacije ne sme da se mea u izvravanje druge aplikacije.
Operativni sistem je taj koji treba da vodi rauna da ne doe do toga i tako obezbedi da se greka u
izvravanju jedne aplikacije ne manifestuje u izvravnju ostalih aplikacija koje se izvravaju na isom
serveru.
Multitastig sa pravom preeg prioriteta mora da obezbedi da se svi procesi na jednom serveru
izvravaju u odreenim vremenskim razmacima tj. da se svako procesu dodeli odreeni kvant vremena
(mali vremenski preiod) u okviru koga taj proces raspolae glavnim procesorom u serveru. Ne sme se
dozvoliti da neki jednostavan proces zauzme sve resurse u sistemu i tako sprei izvravanje ostalih
procesa. Definisanje relativnog prioriteta razliitih procesa koji se izvravaju na serveru je posao
operativnog sistema a oni zavise od vrste i svrhe zadataka koji ti serveri treba da izvre. Kod klasinih
klijent server aplikacija definisanje tih prioriteta je znatno vanije nego to je kod file server aplikacija.
Za razliku od klijent server aplikacija kod file server aplikacija izvrava se samo jedan proces vezan za
file servis pa tako nema potrebe za nezavisnu aplikaciju (appication isolation) i multitasking
(preemptive multitasking).
Ve smo napomenuli da ne postoji neka strikno odreena hardverska tehnologija za proizvodnju
servera. To se isto odnosi i na servere koji treba da zadovolje klasinu klijent server arhitekturu.
Primarna karakteristika takvih servera je da on mora da podri viestruke simultane (istovremene)
zahteve klijenata, koji zahtevaju servisiranje svojih zahteva. Zato, takvi serveri moraju da omogue
podrku za multitasking kao i da omogue nesmetanu podelu i dodelu svog memorijskog prostora
razliitim procesima. Proizvoai procesora kao to su Intel, AMD, IBM, DEC VAX i RISC procesori
( Sun SPARC, IBM/Motorola, Power PC, DEC Alpha) potpuno ravnopravno uestvuju u izboru
hardverske platforme koja e biti odgovarajua za servere u klijent server arhitekturi. Kao server
platforme se mogu koristiti jai PC raunari, RISC raunari ili veliki raunari ako je u pitanju
upravljanje velikikim bazama podataka ili upravljanje velikim mreama i sl. Od njih se oekuje da
budu odgovorni u upravljanju serverskog sistema za prihvatanje spoljanjih zahteva, njihovo
obraivanje i vraanje traenih podataka onim klijentima koji su ih i traili. Sve to moraju da odrade u
43
potpunoj sinhronizaciji kako bi bilo omogueno da se pravovremeno i pravilno odgovori spoljanjim
zahtevima. Sve to mora da prati potpuna bezbednost i nezavisnost u prihvatanju i slanju potrebnih
podataka. Vrlo je bitno da se u tom velikom broju zahteva koji stiu i odgovarajuih odgovora mora
zadrati integritet tih podataka kako bi oni valjano i kompletno stigli do odredita. Zadnjh godina sa
velikim razvojem objektno orjentisanih tehnologija (OOT), koje su u mnogome diktirale razvoj
operativnih sistema i razvojnih okruenja, serveri su postali svuda prisutni (ubiquitous). Tu vai
pravilo 3A koje kae anything (bilo ta), anywhere (bilo gde) i anytime (bilo kada). Drugim reima to
bi znailo da serveri treba da budu potpuno transparentni da ne zavise od tehnologije izrade, mesta gde
se oni postavljaju tj. gde se nalaze korisnici(users) ili razvijaoci(developers) kao i da budu uvek
dostupni. Kako se jedan raunarski proces moe jasno podeliti na klijent i server komponente, za
server procese moemo da kaemo da vae sledei principi:
o Lokaciona nezavisnost, to znai da server proces moe biti smeten bilo gde u mrei.
o Optimizacija resursa server proces mogu deliti vie klijenata.
o Skalabilnost, to znai da server proces moe biti startovan na vie snanih platformi.
o Server procesi bi trebalo da rade u plug-and-play okruenju.
Od savremenih server maina zahteva se:
podrka multiprocesiranju, disk poljima, mehanizmima obrade viestrukih niti (multithreading) i
efikasno upravljanje memorijskim podsistemim.
Podrka disk poljima podrazumeva pristup redudantnim jeftinim diskovima (poznatim kao RAID
diskovi) to uvodi pouzdanost u radu sa diskovima u smislu oporavaka od greaka (otkaz nekog diska).
Mehanizam viestrukih niti omoguava da se procesi podele na vie nezavisnih izvrnih poslova, ime
se obezbeuje da aplikacije mogu izvravati vie simultanih zadataka. "Nit" predstavlja najmanji
proces koji sistem moe planirati za izvrenje.
Podrka memorijskim podsistemima podrazumeva primenu ECC (Error Correction and Detection
Code) mehanizma kao i proveru pariteta da bi se izbegao gubitak podataka koji od servera putuju ka
klijentu o obratno.
Kada su u pitanju serveri potrebna je izatita od problema u napajanju elektrinom energijom to se
obino obezbeuje ureajem za neprekidno napajanje. Potrebno je obezbediti mogunost za proirenje
CPU-a, memorije, diska i periferija.
Za operativni sistem servera se najee bira operativni sistem sa mrenom podrkom (Windiows NT
ili Unix), ali to nije obavezno. Ide se na to da se odvoje server procesi i mreni operativni sistem jer u
tom sluaju server raunar se rastereuje za izvravanje zahteve koji do njega stiu preko nekog
mrenog raunara koji sada preuzima obavezu da zahteve prosledi do servera.
Server aplikacija se startuje pod operativnim sistemom i interaguje sa komponentom komunikacionog
posrednika radi oslukivanja klijent zahteva za servisima. Ova aplikacija ne mora biti zasnovana na
grafikom korisnikom interfeju. Kada zahtev bude primljen, server procesi ga lokalizuju (odreuju
adresa klijenta koji je poslao zahtev). Server zna kako treba da obradi zahtev tako da mu klijent
saoptava samo ta, a ne i kako treba uraditi. Kada se obradi zahtev, odgovor se alje klijentu preko
komunikacionog posrednika.

Uloga servera
Vrlo je vano da se razume da je server jedna vrsta prostornog koncepta a ne opis fizike
implementacije neega. I funkciju klijenata i funkciju servera mogue je obezbediti na istom fizikom
sredstvu. Sa gledita peer to peer (svi raunari su ravnopravni u mrei raunara) povezivanja, svaki
raunar moe potencijalno raditi kao klijent i kao server u zavisnosti da li prua ili zahteva neki servis.
Glavna odlika servera upravo je pruanje razliitih servisa-usluga drugim raunarima meu kojima se
istiu: aplikacini, fajl, print, fax, e-mail, komunikacioni, database, security(servis zatite),
image(video), WEB, sistemski i mreni upravljaki servisi. U narednim sekcijama objasniemo
pojedinano svaki od ovih servisa koji u potpunosti odreuju namenu i ime nekog servera.
Aplikacioni serveri omoguuju da se na klijenskoj radnoj stanici prikazuju poslovni rezultati koji
zavise od vie procesa-aplikacija koje se izvravaju na razliitim raunarima-serverima koji su
postavljeni na potpuno odvojenim i fiziki nezavisnim mestima. U klijent server modelu zahvaljujui
44
IPC ( InterProcess Communication ) zahtevima omogueno je da se ti rezultati u potpunosti ili
delimino prikazuju na vie razliitih klijent radnih stanica i to u razliitim prikazima i formatima.
Kolekcija aplikacionh servera mora raditi u jednoj zajednici u potpunoj sinhronizaciji kako bi mogli da
dobijemo potpunu informaciju. Jedan od primera aplikacionog servera je aplikacija koja je zaduena za
plaanje radnika u nekoj firmi. Na jednom serveru izvravae se aplikacija koja je zaduena da
prikazuje zarade radnika na drugom e se izvravati aplikacija koja izraunava zaradu, na treem
aplikacija koja rauna odbitke i td. Na svim tim serverima mogu da se izvravaju aplikacije pisane u
razliitim programskim jezicima, na razliitim operativnim sistemima, razliitim hardverskim
platformama i mogu da koriste usluge razliitih database servera. Klijent aplikacija poziva sve te
servise ne ulazei u to koja je tehnologija primenjena na tim serverima ili pak gde se ti serveri
geografski nalaze. Objektne tehnologije su omoguile tehniku osnovu za aplikacione servere tako da
oni u potpunosti mogu da odgovore na viestruke klijentske zahteve.
File serveri slue za upravljanje datotekama i omoguavaju zapisivanje podataka koji nisu database
orijentisani. Njegova je uloga da vodi rauna o slobodnom prostoru koji je potreban za pamenje
podataka, da taj prostor dodeljuje podacima kao i da organizuje pamenje podataka na nain koji e
kasnije omoguiti lako pronalaenje tih podataka. Za tu namenu file server se koristi funkcijom
katalaga-adresara koja mu omoguava da se podaci pamte u vidu imena fajlova ili direktorijuma
(folderima). Duina tih imena varira od vrste operativnih sistema koji se izvravaju na serverima i idu
od 8 (DOS) do 256(WIN XP) karaktera. Klijent povezan na mreu moe pamtiti datoteke na file
serveru kao da je to njegov lokalni disk. Kada klijent zahteva podatke iz neke datoteke, File server mu
prosleuje celu datoteku koju klijent dalje pretrauje i obrauje.
Print serveri imaju osnovni zadatak da prihvate podatke za tampanje od klijenata za odreene
tampae, da ih smeste u red, dodele im neki prioritet, aktiviraju odgovarajui drajver za tampa i da
ih preko tog drajvera odtampaju na traenom tampau. Print server takoe mora da poseduje
odreenu logiku koja e podravati jedinstvene karakteristike za svaki tampa. To podrazumeva da u
sluaju da se javi neka greka sa nekim tampaem ili dokumentom koji se tampa (lo tampa,
tampa nije ukljuen, nestao papir na tampau i td.) obavesti klijenta koji je zahtev uputio sa
instrukcijama za reavanje nastalog problema. Ovaj servis se obezbeuje tako to se jedan ili vie
tampaa poveu preko nekog raunara sa klijentima. Klijent moe pristupiti bilo kom tampau kao
da je direktno povezan sa njim. On alje serveru podatke koje treba odtampati, podaci se privremeno
smetaju na disk servera odakle se potom alju na odgovarajui tampa.
Fax serveri imaju slinu funkciju kao i print serveri samo to dobijene zahteve koje su takoe
smestili u redove ne upuuju na tampae ve preko telefonske parice na zahtevano odredite. Njihova
uloga se ogleda u mogunostima da fax-eve alju u tano specificiranom vremenu (kada je tarifa za
slanje jevtinija), da izvre dinamiko kompresovanje i dekomprsovanje podataka koji se alju
(smanjuje se koliina podataka koji alju) i da primljene podatke prikau bilo na displeju ili da ih
odtampaju na tampau. Osnovni uslov da bi ovaj servis funkcionisao je da najmanje jedan server
bude opremljen (internim ili eksternim) faks ureajem. Klijent ne mora imati faks ili ak ni telefonsku
liniju, ve on predaje faks serveru podatke koje treba poslati zajedno sa informacijom kome ih treba
poslati, a server sam obavlja prenos podataka faksom.
E-mail serveri su danas moda pored Web servera najrasprostranjeniji i serveri koji su najoptereeniji
u pogledu vremena koje provedu u aktivnom radu. Ne postoji ni jedan jedini trenutak vremena a da se
u svetu ne poalje neki E-mail tj. da neki E-mail server nije aktivan. E-mail je danas postao glavno
sredstvo za komunikaciju izmeu ljudi kako u poslovnom svetu tako i u privatnom ivotu. Veliki broj
savremenih tehnologija koje su zadnjih godina razvijene ( pre svih Script jezici i XML) omoguili su
da se putem E-mail-a ne alju samo tekstualni podaci ve i video i audio zapisi. Sa jedne strane to je
doprinelo da moemo da dobijamo znatno kvalitetnije informacije ali je zato pruilo velike mogunosti
za irenje velikog broja virusa, crva i ostalih neprijatnosti koji sve vie prete da u potpunosti unite
ovaj vid komunikacije.
Komunikacioni serveri dozvoljavaju klijentima koji su povezani na komunikacioni server, da pristupe
drugim host raunarima ili serverima za koje nisu direktno povezani. Oni daju podrku za
komunikacije koje se odvijaju u okviru jedne WAN (Wide Area network) mree. Ta podrka tipino
45
ukljuuje podrku za veliki broj protokola kao to su: asihroni i serijski protokoli, X.25, ISDN,
TCP\IP, OSI i LAN-to-LAN NetBIOS komunikacioni protokoli. Tipini predstavnici ovakvih servera
su poznatiji kao ruteri, bridge-vi i gateway ureaji bez kojih je nezamisliva bilo koja mrea raunara.
Database serveri ili Serveri baza podataka ine najiru i dosta uspenu klijent/server implementaciju.
U ovom sluaju klijent alje SQL zahtev serveru; server prima zahtev, potvruje ga, izvrava i alje
rezultat klijentu. Podaci i softver za upravljanje podacima se nalaze na serveru baze podataka. Od
klijenta se zahteva samo da ima eonu aplikaciju za pristup serveru baze podataka. Oni upravljaju
podacima koji su database (record) orjentisani. Najvei predstavnici ovakvih sistema su Sybase,
Informix, Paradox, ACCess, SQL i Oracle serveri. File serveri omoguuju inicijalni prostor za
pamenje baze podataka, dok database serveri vode rauna o prostoru za tabele koje se nalaze u bazi
podataka u okviru dodeljenog prostora za bazu podataka. Pored toga database server je odgovoran za
kompletno upravljanje svim podacima koji se nalaze u bazi podataka koja se servisira. To se pre svega
odnosi na:
automatski backout i recovery(oporavak) podataka nakon neke greke u sistemu koja je
prouzrokovana hardwer-om, softwer-om ili prekidom napajanja,
dodela prostora u okviru dodeljenog prostora za bazu podataka,
organizaciju podataka u velikom broju tabela i relacijama izmeu njih,
zakljuavanje podataka (record locking) kod viestrukog pristupa istim podacima,
detekcija i razreavanje mrtve petlje (deadlock),
omoguavanje brzog pretraivanja i nalaenja traenog podataka (indexing).
Transakcioni serveri se sastoje od baze podataka, sistema za upravljanje bazom podataka (DBMS
DataBase Managment System) i procedura za manipulaciju podacima. eona aplikacija na klijentu alj
zahteve transakcionom serveru na kome se izvravaju specijalne procedure koje koje su instalirane na
njemu. SQL kod ne putuje kroz mreu ime je redukovan mreni saobraaj pa ovaj server ima bolje
performanse od servera baze podataka.
Security serveri slue da dodele odreena prava oko pristupa serverima za odreene korisnike
klijente. U veini operativnih sistema to se radi putem dodeljivanja jedinstvenih imena korisnicima
koja su uvek u paru sa odreenim lozinkama. Na osnovu tog para podataka vri se prva provera da li se
korektan korisnik javio i ako je ta prva provera u redu tom korisniku se dodeljuju prava koja su
unapred specificirana za njega. U okviru ovih servera aktivni su neki servisi koji sa vezani za
dodeljivanje jedinstvenih ID brojeva za klijente kao to su WINS, DHCP ili DNS servisi.
Web serveri su danas sigurno narasprostranjeniji serveri koji se i najvie eksplatiu. Ogromni razvoj
Interneta prouzrokovao je i veliki razvoj internet tehnologija koje su omoguile da Web ne bude samo
mesto gde se mogu dobiti samo neke statine tekstualne informacije. Web postaje sve vie mesto gde
se uvaju i podaci kojima se koriste velike kompanije i u integraciji sa database serverima postaju
mono sredstvo za razvijanje aplikacija koje u potpunosti zadovoljavaju sve vee zahteve korisnika.
VPN (Virtualy Private Netware) postaje jako sredstvo u pogledu zatite tih podataka i spreavanja
neeljenih posetilaca koji bi mogli da narue integritet tih podataka.
Mreni operativni sistemi
Serveri se razlikuju po konfiguraciji zavisno od toga kakvu ulogu obavljaju. To su obino raunari
koji su opremljeni diskovima velikih kapaciteta, velikim radnim memorijama (RAM) i brzim mrenim
karticma. Mogu sluiti kao serveri datoteka (file server), serveri za tampanje (print server), serveri za
elektronsku potu (e-mail server), web serveri, specijalni serveri strogo definiranih poslova (domain
name server, gateway, database server). Sve ove vrste servera mogu se nalaziti i u samo jednom
(malo monijem) raunaru. O svakoj serverskoj funkciji brine i odgovarajua programska podrka, a
kompletan server baziran je na nekom mrenom operativnom sistemu. Danas najpopularniji serverski
mreni operativni sistemi su Apple IBM OS/2, Novell Netware, LAN Manager, Microsoft Windows
Server 2003/2008, UNIX operativni sistemi raznih proizvoaa (SCO OpenServer, UnixWare,
praktiki besplatni Linux i slino), Open VMS i ostali manje poznati.

1. Novell Netware - predstavljao je jedan od najrasprostranjenijih mrenih operativnih sistema za
lokalne raunarske mree. NetWare je zatieno ime amerike firme Novell. Od 1983. godine,
46
kada se ovaj proizvod prvi put pojavio na tritu, do danas, pojavilo se nekoliko verzija ovog
operativnog sistema sa vie varijanti (paketa) u svakoj verziji. Firma Novell je lansirala itav
niz komunikacionih proizvoda i pomonih programa koji su na posredan ili neposredan nain
vezani za ovaj operativni sistem. Prema podacima iz 1993. godine, Novell-ovi proizvodi su se
koristili u preko 400.000 LAN mrea. Ovaj mreni operativni sistem instalira se na jednom od
raunara u mrei koji predstavlja fajl server. To je obino raunar sa najjaim procesorom i
najveim kapacitetom diskova. Kako predstavlja otvoreni mreni sistem, on podrava iroki
raspon klijentskih platformi sa kojima moe da radi a koje mogu da budu OS2, DOS, Mac,
Win, UNIX i Linux. Jezgro operativnog sistema je program NET$OS.EXE kod ranijih verzija,
odnosno SERVER.EXE od verzije 3.x. Pomoni programi potrebni za normalan rad mree
smeteni su u 4 sistemska direktorijuma: SYSTEM, PUBLIC, LOGIN, MAIL. Od verzije 3.x
postoje jo i direktorijumi: DELETED.SAV i ETC. Svi programi pisani su na jeziku C. Za
komunikaciju u mreama, Novell je razvio sopstveni mreni komunikacioni protokol IPX/SPX.
Od verzije 3.x postoji mogunost korienja protokola TCP/IP a omogueno je i slanje paketa
podataka IPX/SPX kroz mree sa protokolom TCP/IP. Sve verzije od Advanced NetWare 286
v2.0 pisane su za izvrenje sa esnaestobitnim naredbama. Verzija 3.0 i kasnije verzija 3.x
pisane su za izvrenje sa tridesetdvobitnim naredbama i najnia hardverska platforma za njihov
rad je mikroprocesor Intel 80386SX. Komercijalni naziv za operativne sisteme iz serije 3.x
jeste NetWare 386 ili skraeno NW 386. Verzija 4.0 operativnog sistema zamiljena je kao
operativni sistem za gradske raunarske mree (MAN), odnosno za mree u velikim
kompanijama (Corporate Networks), jer omoguuje administraciju i upravljanje takvim
mreama. Operativni sistem je objektno orijentisan i administracija je zamiljena kao
upravljanje objektima (mree, serveri, korisnici, tampai itd.) i definisanje njihovog rasporeda
i prava. Konzistentnost podataka obezbeena je korienjem replike. Objekti u mrei su
hijerarhijski rasporeeni po principu stabla. Pozicija objekta u hijerarhiskoj strukturi zove se
kontekst objekta. Promenom konteksta objekta menjaju se i njegova prava. Standardne
programe (.com i .exe) nije mogue izvravati u okviru ovog operativnog sistema zbog
nekompatibilnog API (Aplication Program Interface). Novell je razvio sopstvenu tehnologiju
za izvravanje programskih modula poznatu kao Netware Loadable Modul (NLM).
Maksimalna verzija ovog operativnog sistema podrava ak do hiljadu korisnika. Poev od
verzije 5.0 (1998) Novell je napokon kao primarni mreni protokol poeo da koristi
opteprihvaeni TCP/IP, uz ouvanje podrke za IPX/SPX. Osim toga, izvrena je kompletna
reorganizacija fajl sistema, dodati su DHCP i DNS servisi, kao i mogunost da se NetWare
konfigurie kao web server. Poslednje znaajne izmene NetWare je doiveo sa verzijom 6.5
(2003. godine), kada je integrisana podrka za PHP, MySQL i OpenSSH, dodata funkcija
domenskog kontrolera (DC), podrka za enkripciju diskova, USB ureaje itd. Nakon 8 revizija,
oktobra 2008. Novell je objavio da naputa razvoj NetWare i prelazi u potpunosti na OES
(Open Enterpise Server). Osnovni nedostak ovog operativnog sistema je da ne podrava
multitasking a i ne poseduje neki snaan sistem zatite podataka.
2. LAN Manager predstavlja proizvod IBM koji koristi OS/2 operativni system. Iako ovaj sistem
omoguava multitasking i zatitu memorije, i pored podrke velikog imena u svetu raunarstva
ovaj sistem nije doiveo veliku popularnost.
3. Advanced Server Windows NT predstavlja jednu novu pojavu na polju mrenih operativnih
sistema. Od svog prvog pojavljivanja Windows NT (New Technology) 1993 god. pa do danas
ovaj proizvod je doiveo veoma brz i ogroman razvoj tako da se danas smatra za jednim od
najrairenijim operativnim sistemima koji se nalaze na serverima. U poetku zamiljen kao
operativni sistem koji bi trebalo da povee nekoliko Win raunara u okviru lokalne raunarske
mree (konkurencija Novell-u) danas je prerastao u sasvim ravnopravnog pa ak i veeg
uesnika u deljenju kolaa u WAN mreama za koje je vladalo pravilo da su UNIX sistemi
neprikosnoveni. Windows je ime operativnog sistema u vlasnitu firme Microsoft, koji danas u
svojim raznim verzijama dri preko 50% trita. Velika prednost Windows familije operativnih
sistema u odnosu na druge lei u vizuelno atraktivnom korisnikom okruenju, kao i
47
jednostavnosti korienja i podeavanja ak i najsloenijih opcija. Kroz sisteme "arobnjaka"
svaki Windows server se moe za tili as podesiti za rad u mrei sa nekim podrazumevanim
parametrima, pri emu za iskusnije korisnike postoje iroke mogunosti detaljnijeg
podeavanja.Windows je izbor mnogih korisnika i zbog ubedljivo najvee softverske podrke.
Bill Gates je ak i ranih 1980-tih godina znao da je umreavanje veoma vano za posao sa
raunarima. Dakle, 15. aprila 1985. godine Microsoft je ponudio prvu mrenu alatku MS-NET
i odgovarajuii operativni sistem DOS 3.10. Serverski softver je bio zasnovan na DOSu, nudio
je minimalnu zatitu i, ruku na srce, pokazao se loe. Microsoft je u avgustu 1993. godine
objavo NT Advanced Server. Prva verzija servera NT Advenced Server se savim dobro
pokazala. Meutim, zahtevala je mnogo memorije, nedostajale su joj mogunosti povezivanja
koje je nudio Novell i podravala je najosnovnije povezivanje pomou protokola TCP/IP. U
septembru 1994. godine se pojavila nova verzija i novo ime: Microsoft Windows NT Server
verzije 3.5. Verzija 3.5 je uglavnom doraena verzija 3.1; zahtevala je manje memorije,
ugraene su Novellove i TCP/IP mogunosti povezivanja i sadrala je Windows for
Workgroups verzije upravljakih alatki, tako da su administratori mogli da rade za raunarom
radne grupe umesto da rade na NT raunaru. NT verzije 4 se pojavio 1996. godine i liio je na
Windows 95. Osim toga, sadravao je gomilu novih osobina, ali ne i radikalne izmene bitne za
umreavanje raunara. U februaru 2000. godine se pojavio Windows 2000 (NT 5.0). Windows
2000 je sadravao mnogo toga novog, ali je verovatno najvanija promena bila u nainu na koji
su se zapisivali i organizovali korisniki nalozi i informacije koje se odnose na te naloge:
pojavili su se Active Directory (AD) domeni. Sledea po vanosti promena je bila u notaciji
grupnih polisa. Sledea verzija NT-a se, po prvi put od 1993. godine, dobijala u delovima. Prvo
se pojavio NT Workstation, poznatiji kao XP Professional i slabiji brat XP Home. Microsoft
je nameravao da potom objavi serversku verziju NT 5.1, ali je splet okolnosti doveo do toga da
posle nekog vremena napravi NT 5.2 odnosno, Windows Server 2003. Windows Server 2003
je verzija 1.1 Windowsa 2000, dobrodolo poboljanje Windowsa 2000. Sada je Microsoft
stigao do Windows Servera 2008, koji sadri brojne nove osobine u odnosu na prethodne
verzije. Najbolje od svega je to to Windows Server 2008 sadri bitna poboljanja na polju
zatite. Na primer, ak ni administrator ne moe da pristupi osnovnom (korenom)
direktorijumu, direktorijumu \Windows ili direktorijumu \Windows\System32, pa je daleko
tee otetiti izvrne datoteke koje se nalaze u ovim direktorijumima. Novi Windowsov firewall
titi dolazne i odlazne podatke, tako da se mnogo tee ulazi u server, naroito kada
postavimo dodatne firewallove. Administrator sada radi kao obian korisnik i mora imati
dozvole za obavljanje nekih poslova. To znai da neko zlonameran ne moe da napravi tetu
ukoliko ne zna sve to i administrator. Ukratko, Windows Server 2008 je poboljao bezbednost,
a to je ono na ta se najvei broj korisnika alio. Windows Server je infrastrukturna osnova za
pokretanje povezanih aplikacija, mrea i web servisa u svim okruenjima. Server ima napredne
mogunosti za upravljanje i komuniciranje sa udaljenim lokacijama, upravljanje pristupom i
identitetima korisnika, pokretanje web servisa, deljenje resursa... Takoe, Windows Server se
odlikuje naprednim bezbednosnim mehanizmima za utvrivanje identiteta, prava i dozvola
korisnika, kao i mehanizmima za ifrovanje podataka koji su kritini za poslovanje
organizacije. Windows Server je modularni operativni sistem koji se sastoji od komponenata.
Svi objekti operativnog sistema imaju interfejse, pomou kojih drugi objekti i procesi
obezbeuju njihovu funkcionalnost ili usluge. Komponente meusobno sarauju prilikom
obavljanja konkretnih zadataka operativnog sistema. Arhitektura Windows Servera podeljena
je u dva glavna sloja: korisniki sloj (engl. user mode) i sloj jezgra (engl. kernel mode).
Korisniki sloj u sutini je sloj za podrku aplikacijama, kako za Microsoftov softver, tako i za
softver drugih proizvoaa. Sve aplikacije i usluge instaliraju se u korisnikom sloju. Sloj
jezgra se sastoji od nekoliko komponenata koje imaju pristup sistemskim podacima i hardveru.
Usluga Active Directory je kljuna za graenje mrea Windows Servera i za upravljanje njima.
Pojava ove tehnologije je rezultat evolucije Microsoftove tehnologije servera i mrea. Usluge
imenika nisu nita drugo nego uredno razvrstavanje resursa mree i upravljanje njima, bilo da
48
se radi o korisnicima, tampaima, serverima ili bezbednosnim parametrima. Imenici postaju
referentna taka za korisnike usluge i aplikacije. Oni olakavaju pronalaenje tampaa u
terenskoj kancelariji, pronalaenje korisnika i prosleivanje poruka e-potom, ili pomau da se
proveri ima li neki korisnik pravo pristupa odreenoj datoteci.
Windows je trenutno najkomercijalniji i najpopularniji operativni sistem. Tome je doprinela
lakoa konfigurisanja i korienja kao i velika softverska podrka. Windows je razvijan
iskljuivo za Intel/AMD platforme. Ima svoja 32-bitna i 64-bitna izdanja. Ovo je takoe
viekorisniki sistem koji ima mogunost vieprocesne i vienitne obrade. Jezgro operativnog
sistema upravlja nitima procesa koje se prosleuju mikroprocesoru, vremenski rasporeuje
izvravanje niti, omoguuje istovremeni rad vie programa itd. Komponenta sistema Hardware
Abstrction Layer (HAL) sadri spedcifian kod koji obezbeuje ulazno/izlazne interfejse
specifine za pojedine hardverske ureaje, obrauje hardverske prekide itd. Windows Server
podrava vieprocesorsku simetrinu obradu. to se tie upravljanja memorijom trebamo
napomenuti da ovaj sistem koristi dve vrste memorije. Prva je fizika u obliku RAM ipova
utaknutih na matinu plou raunara. Drugu vrstu ini virtuelna memorija, to jest kombinacija
svih vrsta memorije ugraenih u raunar i naina na koji se ona stavlja na raspolaganje
operativnom sistemu.
4. PC Network File Services (NFS) ili poznatiji kao UNIX sistemi predstavljali su zaetnike
serverskih operativnih sistema koji su u startu podravali klijent server tehnologiju. Dugi niz
godina UNIX se smatrao kao neprikosnoveni operativnim sistemom na polju klijent serverskih
sistema tako da je izgledalo da ga niko nee moi dostii a kamoli prestii. I on je preiveo
mnoge modifikacije i prilagoavanja kako bi se odupreo konkurenciji. Danas je najpoznatiji
naslednik ove tehnologije Linux operativni sistem koji je i jedini ostao kao ozbiljan rival sve
veoj i veoj Windows imperiji. Linux je brz i stabilan operativni sistem za PC raunare i radne
stanice, otvorenog izvornog koda, koji prua Internet servise profesionalnog nivoa, obimne
razvojne alatke, potpuno funkcionalne grafike korisnike interfejse (GUI-je) i znatan broj
aplikacija, od onih za kancelarijsko poslovanje do multimedijalnih aplikacija. Linux je ranih
devedesetih godina dvadesetog veka razvio Linus Torvalds, zajedno sa drugim programerima
irom sveta. Kao operativni sistem, Linux obavlja mnotvo istih funkcija kao i Unix,
Macintosh, Windows i Windows NT. Meutim, Linux se istie po svojoj snazi i fleksibilnosti,
kao i po tome to je besplatan. Linux predstavlja PC verziju operativnog sistema Unix koji se
decenijama koristi na centralnim raunarima i mini-raunarima i trenutno je sistem koji
predstavlja pravi izbor za mrene servere i radne stanice. Linux donosi brzinu, delotvornost,
skalabilnost i fleksibilnost Unixa PC-ju, koristei sve mogunosti koje personalni raunari
danas pruaju. Tehniki, Linux se sastoji od programa operativnog sistema, koji se naziva
jezgro (kernel), i to je deo koji je prvobitno razvio Linus Torvalds na helsinkom univerzitetu.
No, jezgro se uvek distribuira sa znatnim brojem programa za posebne primene, od mrenih
servera i bezbednosnih programa do kancelarijskih aplikacija i razvojnih alatki. Linux se razvio
kao deo pokreta za softver otvorenog izvornog koda, u okviru kojega su se nezavisni
programeri sakupili da bi obezbedili besplatan kvalitetan softver za svakog korisnika. Linux je
postao glavna platforma softvera otvorenog izvornog koda, iji je veliki deo razvijen u okviru
projekta GNU organizacije Free Software Foundation. Mnoge od ovih aplikacija upakovane su
kao deo standardnih distribucija Linuxa. Trenutno je dostupno na hiljade aplikacija otvorenog
izvornog koda za Linux. Kao i Unix, Linux se uopteno moe podeliti na tri glavne
komponente: jezgro, okruenje i strukturu datoteka. Jezgro je osnovni program koji izvrava
programe i upravlja hardverskim ureajima, kao to su diskovi i tampai. Okruenje
obezbeuje korisniki interfejs. Ono prima komande od korisnika i alje te komande jezgru na
izvravanje. Struktura datoteka odreuje nain na koji se datoteke uvaju na ureaju za
skladitenje, kao to je disk. U potencijal Linuxovog operativnog sistema ubrajaju se i snane
mogunosti umreavanja, ukljuujui podrku za Internet, intranetove i Windows i Apple
umreavanje. Linux ima sve alatke za umreavanje, kao to su podrka za FTP transfer
datoteka, web pretraivai i ceo spektar mrenih servisa, kao to su e-pota, servis imena
49
domena (DNS) i dinamika konfiguracija matinog servera, uz FTP i web servere i servere za
tampanje. On takoe poseduje potpun skup uslunih modula za razvoj programa, kao to su
C++ kompajleri i moduli za pronalaenje greaka. I uz sve svoje mogunosti, operativni sistem
Linux ostaje mali, stabilan i brz. U svom najjednostavnijem formatu, Linux se efektivno moe
izvravati na samo 2 MB memorije.
5. Open VMS je smatran takoe za neprikosnoveni operativni sistem za snane i mone raunare
koje je proizvodila korporacija Digital Corporation VAX. To je bio period kada su snage
klijentskih raunara bile vrlo male, sa veoma skromnim resursima u pogledu memorijskog
prostora i brzine procesora, tako da se iole ozbiljnija aplikacija koje je zahtevala malo vee
resurse morala da se izvrava na monijim raunarima koje je proizvodila ova firma. Sa
razvojem tehnologija sva ta snaga velikh raunara polako se sputala na obine klijentske
raunare a samim tim se i polako gubila potreba za jako snanim raunarima. Snaga klijenskih
raunara bila sasvim dovoljna u pogledu raunarskih resursa za izvravanje gotovo svih
zahtevnijih aplikacija a sva vea zastupljenost interneta omoguila je korienje drugih
serverskih usluga. Jednom reju vrila se decentralizacija svih potrebnih serverskih usluga tako
da su se sada poslovi odvjali na vie servera koji su bili usko specijalizovani za poslove koje
su radili. VMS je tradicionalni operativni sistem kompanije Digital Equipment Corpration. 25.
oktobra 1977. verzija 1.0 VMS-a je ugledala svetlost dana. Od tada je VMS promenio ime u
OpenVMS i promenio je dva vlasnika, prvo ga je kupio Compaq da bi ga posle preuzeo DEC
koji e na kraju opet biti kupljen od strane HP-a. Uprkos svemu VMS se razvijao i napredovao
u kontinuitetu. Danas OpenVMS radi na VAX, Alpha, i Itanium procesorima (HP Integrity) i
trenutno je aktuelna verzija 8.3-1H1. Ovoj operativni sistem predstavlja viekorisniki
multiprocesni sistem koji omoguava efikasno deljenje resursa, obradu transakcija i rad u
realnom vremenu. Raspoloivost sistema je uvek na visokom nivou, s obzirom na sposobnost
sistema da se distibuira na vie fiziki odvojenih raunara. Iz tog razloga VMS je ujedno
izuzetno tolerantan na bilo koji vid greke koja bi uticala na rad bilo koje pojedinane jedinice
za obradu informacija. VMS ima i mogunost da bilo kom korisnikom procesu, prema potrebi,
dodeli prioritet iznad procesa sistemskog jezgra. VMS je uveo mnoge novine koje se danas
smatraju obaveznim osobinama ozbiljnih mrenih operativnih sistema, poput integrisane
raunarske mree, multiprocesiranje, distribuirani fajl sistem, podrku za vie razliitih
kompjuterskih jezika, sopstveni komandni jezik, visok nivo bezbednosti itd.
50
9 as Programska podrka servera

Baze podataka i sistemi za njihovo upravljenje predstavljaju nezobilazne komponente klijent server
sistema. Smatra sa da danas ne postoji ni jedna ozbiljnija klijent server alikacija koja se ne oslanja na
neku bazu podataka i mehanizam za upravljanje tom bazom. Zato emo se u daljem izlaganji i najvie
zadrati oko tehnologija koje su razvijene da bi u klijent server modelu zadovoljile pristupe razliitim
bazama podataka. Najoptije posmatrano, baza podataka se moe definisati kao kolekcija meusobno
povezanih podataka memorisanih na nekom medijumu. Pod podacima podrazumevao injenice o
nekom segmentu realnog sistema koje imaju tano odreeno (implicitno) znaenje za korisnike baze
podataka. Podaci koji se uvaju mogu se sastojati od svega nekoliko ulaznih podataka ili redova koji
ine jednostavan adresar sa imenima, adresama i telefonskim brojevima. Nasuprot tome, baza podataka
moe da sadri i milione zapisa koji opisuju katalog proizvoda, audio video zapisa ili platni spisak
neke velike kompanije. Kao i za druge komponente sistemskog softvera gde se korisnici odvajaju od
aplikacija, tako se i u upravljanju bazama podataka koriste neki modeli za odvajanje korisnikih
aplikacija od fizike baze podataka. Kod baze podataka taj model je predstavljen kroz arhitekturu tri
emekoja se sastoji od sledeih nivoa:
1. Interni nivo koji koristi internu emu pomou koje opisuje fiziku strukturu baze podataka.
Interna ema opisuje sve detalje memorisanja podataka i pristupne mehanizme i puteve u bazi.
2. Konceptualni nivo koristi konceptualnu emu pomou koje opisuje logiku strukturu baze
podataka. U stvarnosti to je globalni opis baze podataka koji od korisnika krije nepotrebne i
optereujue detalje fizike arhitekture baze podataka. Konceptualni nivo opisom entiteta
(objekata realnog mini sveta), tipom podataka i meusobnih odnosa izmeu entiteta,
omoguuje projektantima i korisnicima baze podataka da se potpuno posvete dogaajima u
mini svetu, relacijama koje vladaju u njemu, atributima entiteta, i na taj nain to tanije
definiu upotrebnu vrednost i efikasnost jedne konkretne baze podataka.
3. Eksterni nivo ukljuuje odreeni broj eksternih ema, drugim reima korisnikih pogleda kako
na deo mini sveta koji ih interesuje, tako i na deo baze podataka koja prati taj mini svet. Uloga
eksternog nivo je da od takve korisnike grupe sakrije deo baze podataka koji nije interesantan
za njih.

U centru svih klijent server aplikacija koje se bave bazama podataka nalazi se DBMS
(DataManagment System). DBMS je skup komponenata za definisanje, izradu i korienje baze
podataka koji treba da omogui skladitenje, pretraivanje i upravljanje podacima u bazi podataka.
Kada pomenemo sistem za upravljanje bazom podataka (DBMS), uglavnom mislimo na realcioni
DBMS tj. RDBMS. Relacione baze podataka skladite veze izmeu podataka i upravljaju tim vezama.
Da bi klijent server radio kako treba DBMS mora da zadovolji neke uslove i to:
Potreban je transparetni pristup podacima za razliite klijente bez obzira na hardver, softver i
mrenu platformu koju koristi klijent aplikacija.
Da se dozvoli da klijent alje svoje zahteve prema serveru baze podataka (ukljuujui i SQL
zahteve) kroz mreni sistem.
Da se svi zahtevi klijenta za podacima obrauju u lokalnom serveru.
Da se klijentu alju samo podaci koji se dobijaju kao rezultat obrade njegovog zahteva.
Klijent server DBMS oslobaa klijenta od lokalne obrade. To znatno redukuje mreni saobraaj i time
ubrzava rad sa traenim podacima. Klijentu se vraaju samo oni podaci koji odgovaraju traenom
zahtevu. Klijent server sistem je promenio nain na koji mi pristupamo i obraujemo podatke u bazi
podataka. Sada podaci mogu biti smeteni ne samo na jednoj lokaciji jednom serveru, ve na vie
servera koji mogu biti na potpuno lokacijski razliitim mestima. Ako su podaci smeteni na vie mesta
tada kaemo da se radi o distribuiranim klijent server bazama podataka. Takve baze podataka
karakterie:
Lokacija podataka je potpuno transparentna za korisnika. Podaci mogu biti smeteni na lokalnom
PC-ju, serveru odeljenja ili na velikim raunarima irom zemlje. Podaci mogu biti distribuirani
izmeu razliitih lokacija i izmeu razliitih baza podataka koristei iste ili razliite modele
51
podataka. DBMS mora biti sposoban da upravlja distribucijom podataka izmeu razliitih
vorova. Podaci mogu biti podeljeni na nekoliko naina i oni mogu biti smeteni na nakoliko
razliitih raunara koji rade na razliitim softverskim platformama. Korisnik ne treba da zna ni
gde su podaci locirani, ni kako se oni uzimaju a ni protokole koji to treba da obave.
Podaci treba da budu pristupani i da se njima moe manipulisati od strane korisnika u bilo koje
vreme i vie puta. Pristupanost podacima je poveana zato to je krajnji korisnik sposoban da
pristupi podacima direktno koristei pokazivae (mia) u sistemu baziranom na GUI-u. Krajnji
korisnik moe manipulisati podacima na razliite naine u zavisnosti od njegovih potreba. Tako
je mogue da iste podatke dobijamo u razliitim grafikim prikazima. Zahtev za podacima se
izvrava na serverskoj strani a formatiranje i prikaz podataka na klijentskoj strani.
Obrada podatak (smetanje, ispravnost, formatiranje, prezentacija i td.) je distribuirana izmeu
razliitih raunara. Predpostavimo da se naa baza podataka nalazi na tri DBMS pri emu su oni
locirani na razliitim raunarima. Ako klijent zahteva neki izvetaj on se tada obraa sa zahtevom
jednom od tih servera. Server baze podataka prihvata zahtev i brine se za lociranje i pribavljanje
svih podataka koji su zahtevom specificirani. Obrada pristupa i uzimanje podataka se obavlja na
tri razliita raunara i takvi ujedinjeni podaci se sada alju klijentu. Klijent se sada samo brine o
formatiranji primljenih podataka i njihovom odgovarajuem prikazivanju na svom raunaru.
Jedan klasian DBMS sistem se sastoji od sledeih komponenti:
1. I nterfejs za aplikacije predstavlja standardne biblioteke koje pomau u komunikaciji sa DBMS-
om. Veina DBMS-ova ima svoj jednostavni prevodilac u obliku komandne linije koji esto
koristi biblioteke za prenoenje zahteva unetih sa tastature do DBMS-a i za prikazivanje
odgovora.
2. I nterpretator SQL koda Sintaksni analizator proverava sintaksu prosleenih upita i prevodi ih u
interni prikaz.
3. Analizator upita Generie razne planove izvravanja upita na osnovu statistike baze podataka i
njenih svojstava, odabira jedan od planova i prevodi ga u akcije koje izvrava na niskom nivou.
4. Pristup podacima U module koji upravljaju pristupom podacima uskladitenim na disku spadaju
modul za upravljanje transakcijama, modul za upravljanje postupkom obnavljanja stanja, modul
za upravljanjem baferom glavne memorije, modul za zatitu podataka i modul za upravljanje
pristupom datotekama.
5. Baza podataka podrazumeva same fizike podatke koji su razvrstani u razliitim tabelama.
Ovde su obuhvaeni i neki drugi podaci koji olakavaju rad za bazom podataka kao to su
indeksne datoteke i statistike datoteke. Ti se podaci prvenstveno koriste za generisanje i
optimizovanje planova za izvravanje upita.

Neki od predstavnika sistema za upravljanje bazama podataka koji su danas najzastupljeniji su
ORACLE DBMS, SQL Server, MySQL i td. Za sve njih je zajedniko da podravaju sve gore
pomenute uslove kao i da podravaju jedinstveni jezik za upravljanjem podacima u bazama SQL
(Structure Queru Language).
ALATI ZA UPITE (QUERY TOOLS)
Klijent-server arhitektura i alati vezani za takvu arhitekturu uticali su na razvoj korisniki orijentisanih
alata za upite i izvetavanja, koji su obeavali korisnicima da e moi samostalno, bez intervenisanja
raunarskih specijalista, napraviti jednostavnije upite i izvjetaje bazirane na tim upitima. Meutim,
realnost je pokazala, da kada su u pitanju velike baze podataka pogotovo skladita podataka,
informatiki specijalisti postaju nuni kako bi optimizirali performanse baze podataka, alocirali
podatke i njihovu obradu izmeu platformi, te kreirali i testirali sloenu logiku obrade podataka.
Od savremenih alata za upite i izvetavanja oekuje se da osiguravaju:
1. Pristup velikom broju redova baze podataka;
2. Prenos velikog broja rezultata iz baze podataka na radne stanice krajnjih korisnika;
3. Sloene SQL iskaze ukljuujui povezivanje vie tablica i podupita;
4. Sloenu logiku izvetavanja kao grupnih postupaka koji ukljuuju veliki broj redova.
52
Navedeni zahtevi utjiu na to da se arhitektura naprednih alata za upite i izvetavanja sastoji od vie
slojeva. Profesionalci (i ponekad krajnji korisnici) prave upite i izvetavanja koristei klijent-server
razvojne alate. Krajnji korisnici pokreu izvetavanja sa svojih radnih stanica. Izvetavanja se smetaju
i pozivaju s drugog sloja, dok serveri baze podataka ine trei sloj. Ovakva arhitektura omoguava
upitima i izvetajima da se efikasno izvravaju i nad velikim bazama podataka, kao i da mogu vratiti
velike koliine podataka.
injenica je da alati za upite i izvetavanja postaju sve sofisticiraniji, to vie prevladava potreba za
pristupom sraymerno velikim bazama podataka (skladitima podataka). Izbor alata za izvetavanje vie
nije tako jednostavan proces, pogotovo otkako performanse nisu jedini kriterijum, nego odluka treba
primarno biti bazirana na korisnikom sistemu. U tom sluaju treba postojati razumevanje korisnikih
zahteva za pristupom podacima, strukture baze podataka, LAN/WAN komunikacijskih mogunosti i
slino, kako bi se moglo odabrati odgovarajue rjeenje. U sluaju pristupa skladitima podataka,
potrebno je definirati kategoriju veliko kako bi se lake odabrao odgovarajui alat za upite i
izvetavanja.
Alati za krajnje korisnike koji omoguavaju da baza podataka upravlja optimizacijom izvrenja upita
su najbolji za odabir malog broja redova baziranog na jednostavnoj logici iz jedne ili dvije ogromne
tablice. Prilagodljivi serveri za upite i izvetavanja su potrebni za odabir srednjeg do ogromnog broja
redova bazirano na sloenoj logici, tako da specijalisti mogu praviti upite koji imaju najefikasniji
pristup bazi podataka. Server orijentisani proizvodni alati za upite i izvetavanja sa mogunostima
programiranja, pamenja i optimiziranja upita, potrebni su za odabir velikog broja redova iz nekoliko
razliitih tablica baziranih na sloenoj logici i gde postoje zahtevi za sloenim izlaznim formatiranjem
izvetavanja.
Veina proizvoaa alata za upite i izvetavanja pronala je jednostavne naine da IS administratorima
omogui prikrivanje ili prevod SQL-a u poslovne termine. Zahvaljujui metapodacima, ili
podacima o podacima, alati za upite i izvetavanja obeavaju ukidanje potrebe da korisnici razumeju
dizajn baze podataka i postavljaju relacije neophodne za povezivanje tablica u trenutku pravljenja
upita.
Razvoj robusnijih alata za upite i izvetavanja napravio je znaajan korak ka smanjenju ali ne i
eliminisanju - potrebe za unapred definisanim izvetajima. Naime, ti alati su zamenili jedan nain
unapred definisanih upita, drugim. Tamo gde savremeni alati za upite i izvetavanja pomau
poslovnim korisnicima u formulisanju njihovih vlastitih upita, oni to mogu uraditi tako precizno zato
to su arhitekti sistema za podrku odluivanju anticipirali korisnike upite i predefinisali sloene
SQL naredbe. Na primer, da bi se izvrili zadaci vezani za podrku odluivanju sabiranja i
izraunavanje proseka to zahteva znatan broj unaprijed definisanih koraka i znatno programiranje.
Logino je da u sluaju promene zahteva, postupak predefinisanja i programiranja treba ponoviti.
Krajnji zakljuak je da alati za upite i izvetavanja u sutini ne podravaju stvarne ad hoc korisnike
upite, odnosno upite formirane od nule direktno na podacima iz baze podataka.
I pored znaajnog napretka u razvoju alata za upite i izvjetavanje, oni su jo uvek dostupni samo u
manje sloenim delovima sistema za podrku odluivanju. Kako je za njih karakteristian nedostatak
sofisticiranosti potrebne za sloeno okruenje za potporu odluivanju, u takvom okruenju oni se
mogu upotrebljavati samo u kombinaciji s drugim, za podrku odluivanju podesnijim, alatima.
Osnovni nedostaci alata za upite i izvetavanja ogledaju se u sledeem:
1. Stalno uee informatiara u procesu izrade i odravanja;
2. Potekoe u ispunjavanju izazova vezanih za sloena poslovna pitanja;
3. Nesposobnost podrke velikim upitima;
4. Nedostatak koncepta vremena, konsolidiranja i agregiranja;
5. Nemogunost transparentne potpore i ujednaavanja razliitih tehnika optimiziranja baza
podataka;
6. Slaba povezanost izmeu upita i izvjeivanja;
7. Dizajn tipa debeli klijent.
Navedena ogranienja, kao i ukupan razvoj alata za upite i izvetavanja koji je primarno bio vezan za
transakcijske, a ne sisteme za podrku odluivanju, dovela su do toga da su ti alati ostali marginalni s
53
aspekta podrke odluivanju, dok su se za potrebe podrke odluivanju razvijali mnogo sofisticiraniji
alati bazirani iskljuivo na potrebama tih sistema.

SQL predstavlja standardan jezik za iterakciju sa relacionom bazom podataka. Skoro svi sistemi
relacionih baza podataka podravaju SQL kao alat za izradu, zatitu i pretraivanje baze podataka, kao
i za upravljanje njome. Sql predstavlja mnogo vie od obinog jezika za upite; to je u potpunosti
usavrena alatka za sve aspekte odravanje jedne baze podataka. Sql se sastoji iz etiri glavna dela i to:
1. J ezik za definisanje podataka (Data Definition Language) predstavlja skup SQL komandi koje
formiraju i briu bazu podataka, dodaju ili uklanjaju tabele, formiraju indekse i unose izmene na
svakom od pobrojanih elemenata. Komande DDL-a se koriste samo u toku izrade baze podataka.
2. J ezik za manipulisanjem podacima (Data Management Language) je skup komandi koje rade
sa DBMS-om i bazom podataka. To su komande za pretraivanje, umetanje i brisanje podataka u
tabelama baze podataka. To su komande koje se najvie upotrebljavaju u toku uobiajenog
korienja baze podataka.
3. Upravljanje transakcijama podrazumeva da SQL sadri komande za oznaavanje grupe
komandi kao celine ili transakcije. Korienjem ovih komandi transakcije se mogu pozvati ili
ponititi.
4. Napredne mogunosti DML i DDL omoguavaju da se SQLnaredbe mogu ubaciti i u
programske jezike opte namene i definisanje prikaza postojeih podataka za specijalne namene,
kao i dodeljivanje i oduzimanje prava pristupa DBMS-u i bazi podataka. Tu spadaju i komande
za obezbeivanje integrititeta tj. komande za obezbeivanje ispravnosti podataka i potovanje
unutranjih relacija izmeu tabela.

Celokupno ovo razmatranje klijent server baza podatak ne bi bilo kompletno ako ne spomenemo veze
izmeu klijenata i servera koje nam upravo omoguuju da moemo da pristupamo razliitim bazama
podatak pod razliitim DBMS-ovima. Naveemo samo neke tipine predstavnike tih veza koji se
danas najvie koriste.
1. ODBC (Open DataBase Connectivity) predstavlja najstariji Microsoft-ov standard za
povezivanje aplikacionog softvera sa razliitim relacionim bazama podataka. Stariji COM
interfejsi kao to su DAO (Data Access Objects) i RDO (Remote Data Objects) zasnivali su se
upravo na ODBC preko koga su pristupali podacima u bazi podataka. ODBC je predstavljao
niski nivo API-a i zahtevao je od programera da vodi rauna o memorijskoj raspodeli i dodeli. To
je u mnogome oteavalo rad sa njim jer je optimizacija baze podataka bila oteana. Danas postoji
preko 100 razliitih ODBC drajvera za razliite softverske platforme. Jednostavnom zamenom
odgovarajueg ODBC drajvera omoguen je pristup razliitim bazama podataka.
2. OLE DB predstavlja ime Microsoft standarda koji je definisan za jedinstveno podravanje
aplikacija koje pristupaju i relacionim i nerelacionim bazama podataka. Postoje razliiti OLE DB
interfejsi za svaki razliiti izvor podataka. Ukoliko nemamo odgovarajui OLE DB interfejs za
neke podatke onda moemo da koristimo odgovarajui ODBC drajver i tako pristupimo
podacima.
3. ADO (ActiveX Data Objects) predstavlja Microsftov COM bazirani objektni modul koji nam
omoguava da upravljamo OLE DB izvorima podataka. Dizajniran je tako da omogui klijentima
to lake i bre dobijanje skupa slogova iz baze podataka.


54
10 as Veze izmeu klijent server sistema

Jedan od najeih opisa klijent server sistema koji na najednostavniji nain pokazuje i opisuje ta ta
tehnologija predstavlja je Mrea je raunar. U ovoj prostoj reenici sadrana je sva mudrost ove
tehnologije koja omoguava korisnicima da mogu sa svojih raunara, bez obzira kakvi su to raunari,
gledano i sa hardverske i sa softverske strane, da pristupe podacima, servisima ili drugim resursima
koji se nalaze bilo gde na mrei. Korisnik klijent radi na svom raunaru i koristi mnoge servise koji
su mu dostupni, u zavisnosti od njegovih prava pristupa pojedinim servisima, podacima ili resursima
koji se nude na mrei, a da on nema pojma da li se taj servis, podatak ili resurs koristi sa njegovog ili
nekog drugog raunara u mrei. to se njega tie on ima utisak da se sve to dogaa na njegovom
raunaru. Na taj nain od jednostavnog klijent raunara pravi se jako snana maina ija se snaga sada
ogleda u snazi kojom raspolae mrea raunara u koju je on ukljuen. Iz tog razloga gornja izreka
postaje prihvatljiva, jer najbolje odslikava klijent server tehnologiju u kojoj korisniki raunar
predstavlja samo jedan mali deo jednog velikog i snanog raunara, a to je celokupna mrea svih
povezanih klijenata i servera u njoj.
Da bi sve stanice bile povezane u neku mreu potreban je neki medijum koji e fiziki povezivati te
stanice. LAN kabliranje je upravo taj medijum koji povezuje sve te raunare u jednu jedinstvenu celinu
i omoguava im da razmenjuju podatke, dele resurse i koriste razliite servise. Za povezivanje
raunara koriste se i mnogi dodatni ureaji koji nam pomau kod povezivanja raunara i to su: habovi
(hubs), mreni komutatori (switches), repetitori-pojaavai (repeaters), mostovi (bridges), ruteri
(routers) i mreni prolazi (gateways). Da bi povezali dva ili vie raunara razvijane su mnoge
tehnologije iz kojih su danas proizale tri osnovne tehnologije koje se koriste:
ARCnet (Attached Resource Comuter Network) raunarska mrea prikljuenih resursa
predstavlja najstariju tehnologiju umreavanja koja se danas jo uvek koristi. Razvijena je 70-tih
godina u kompaniji Datapoint Corporation i svoj maksimum je doivela sredinom 80-tih godina kada
je Ethernet jo uvek bio preskupa tehnologija a veina mrea je bila jako mala. Poto se radi se o
tehnologiji koja koristi sistem prosleivanja tokena, ona predstavlja deterministiku tehnologiju pa se
njena upotrebljivost vidi samo u sistemima sa predvidljivim propusnim opsegom. Brzina rada ove
mree iznosi od 2,5 Mbps do 10 Mbps i u okviru ove mree moemo povezati maksimalono 255
raunara. Mada ARCnet vie nije reenje pre svega za PC raunare, i dalje sbog svojih svojstava ova
tehnologija je zastupljena i to pre svega u industrijskim aplikacijama (vrlo jednostavna i pouzdana
komunikacija u okviru predvidivog propusnog opsega).
Token Ring mree, u odnosu na Ethernet mree, koriste drugaiji mehanizam kontrole pristupa
medijumu i drugaiji format podataka. Zaetci tehnologije umeravanja token ring bili su u kompaniji
IBM. Kasnije je ona standardizovana od strane IEEE 802.5 radne grupe. U Token Ring mrei nema
sukobljenosti niti algoritma odustajanja. Radne stanice se nadmeu pomou okvira koji se prosleuje
od stanice do stanice i ije posedovanje omoguava prenoenje podataka preko mree. Ovaj okvir se
naziva token. On se prosleuje preko mree prema logikoj topologiji prstena pa od tuda i naziv ovoj
mrenoj tehnologiji. Poto token redovno krui prstenom, moe se izraunati najdue vreme potrebno
da ga stanica primi i zapone slanje podataka preko mree. Zato se Token Ring mree nazivaju
deterministike mree jer se moe izraunati vreme pristupa za najnepovoljnije okolnosti rada. Glavni
nedostatak Token Ring tehnologije je njegova skuplja realizacija u odnosu na realizaciju Ethernet-a.
Svega nekoliko kompanija proizvodi token ring adaptere, a zbog svoje sloenosti njihova proizvodnja
je skuplja.
Ako sednete za bilo koji dananji raunar-PC koji se nalazi u nekoj mrei, budite sigurni da je
on povezan sa lokalnom mreom nekim oblikom Etherneta. Iako postoje i druge tehnologije
povezivanja u lokalne mree, broj raunara koji su povezani pomou Etherneta nadmauje sve ostale i
to za red veliine. Ethernet je najraspostranjenija mrena tehnologija koja povezuje servere, tampae i
ostale ureaje na mrei. On je toliko raspostranjen da gotovo svi proizvoai mrene opreme nude
opremu koja je projektovana da radi sa Ethernet lokalnim mreama. Vano je napomenuti da postoje
vie vrsta Etherneta. On je poeo kao jednostavna tehnologija lokalne mree da bi se danas razvio u
ozbiljnu tehnologiju regionalne mree. Njegov razvoj poeo je u istraivakim laboratorijima Xerox-a
55
koji su dobili zadatak da umree vie raunara koji e istovremeno da koristire najnoviji laserski
tampa. Od prvih komercijalnih verzija koje su radile brzinama od 10 Mbps (sredinom 70-tih godina)
do dananjih Gigabit-nih mrea ( 10 Gigabit Ethernet IEEE 802.3ae ). Korienjem komutacije,
poveanjem brzina, vezama u punom dupleksu i prilagodljivost razliitim medijumima, Ethernet
tehnologiju svrstava daleko ispred svih ostalih LAN tehnologija razvijanih zadnjih 30 godina. Ne
postoji ni jedan razlog koji bi ograniavao dalji napredak ove tehnologije to je jo jedan jak razlog za
dominantnu ulogu koju ova tehnologija ima na polju mrenog povezivanja.
Instalirana baza sadanjih raunara uglavnom koristi tehnologije zasnovane na bakarnim
provodnicima i optikim kablovima. Meutim, ne smemo zaboraviti sve vei rast beinih
tehnologija. To potvruje trite mobilnih telefona koje svake godine raste velikom brzinom. Dananji
mobilni telefoni prihvataju tekstualne poruke, E-mail potu i doputaju ogranieno pretraivanje WEB
servisa. Poseban protokol razvijen za beine aplikacije (WAP) doprineo je da mobilni telefon sve vie
postane klijentski raunar preko koga moemo da odradimo gotovo sve poslove kao i sa normalnog
desktop raunara. Na ovom polju vodi se rat izmeu dva konkurenta na polju beine komunikacije i
to: Wi-Fi (IEEE 802.11 standard) i HomeRF. HomeRF tehnologija je projektovana posebno za kune
korisnike i predstavlja izradu potpuno nove beine mree. IEEE 802.11 standardi protokola slue za
proirenje mogunosti beinog povezivanja postojeih mrea dodavanjem taaka beinog pristupa
(acces point). Ova tehnologija odnosi se na povezivanje raunara od kue do javnih prostora. Njen cilj
je da postavi svetske standarde koji e omoguiti da se u mnogim raznorodnim okruenjima korisrti
jedna kartica beinog mrenog adaptera. Tu treba pomenuti jo jednu tehnologiju koja sve vie hvata
zamaha a to je Bluetooth tehnologija. Bluetooth predstavlja jo jednu beinu tehnologiju koja je
projektovana da zameni veliki broj ica na kratkom prostoru. Ona treba da povee ureaje kao to su
tampa, tastatura, mi, raunar i mobilni telefon.

Kada razmatrarno razliite mrene ureaje ili softverske komponente mree, obino kao referentnu
taku koristimo model koji je napravila Meunarodna organizacija za standardizaciju (I nternational
Standardization Model, ISO). Sedmoslojni referentni model umreavanja (Seven-Layer Networking
Reference Model) povezivanjem otvorenih sistema (Open System inter connection, OSI) prvobitno je
razvijen kao nacrt za izradu dodatnih mrenih ISO protokola. Meutim, ovi protokoli su nastali u
vreme kada je bilo potrebno veliko angaovanje raunara za njthovo implementiranje i nisu bili iroko
prihvaene. Neke kompanije, kao to je DEC-net korporacije Digital Equipment, ipak su prele na OSI
standarde. Sa naglim razvojem Interneta, kao i protokola koji su mu potrebni, TCP/IP je postao
globalni standard za veinu lokalnih (i regionalnih) raunarskih mrea umesto OSI protokola. TCP/IP
se zasniva na mrenom modelu koji ima manji broj slojeva - etri, ali je OSI ostao referentni model jer
se razmatranje tehnologije umreavanja obino jo uvek odnosi na ovaj model.
OSI model umreavanja je upravo to - model. To je referenca koju moete da koristite kada sa
kolegama razgovarate o mrema. Model odreuje sedam slojeva, koje rnoete da posmatrate kao
zasebne modele, od kojih svaki obavlja odreen skup funkcija. Svaki sloj u modelu komunicira sa
susednim slojevima preko standardnog definisariog interfejsa. Prema tome, razvoj unutranjih funkcija
svakog sloja moe da se prepusti proizvoau. Ono to je vano jeste da svi slojevi rade zajednu, bez
obzira na to koji proizvoa ih obezbeuje. Na primer, mreni adapteri i mreno kabliranje spadaju u
najnii, fiziki sloj. Mrene kartice su projektovane za rad sa softverom koji spada u sledei vii sloj,
sloj povezivanja podataka. Na slici se vidi kako meusobno komuniciraju razliiti slojevi modela, sa
dva kraja mrene veze.
56

Svaki sloj u OSI referentnom modelu obezbeuje funkcije za susedne slojeve u modelu. Kao to se
vidi na slici strelice pokazuju protok informacija u steku, od raunara A nanie. Kada informacije
stignu u fiziki sloj, komponente u svakom sloju deluju tako da se podaci prenesu na udaijeni sistem.
Na udaljenom sistemu, fiziki sloj prima elektrine (ili svetlosne) impulse, konvertuje ih odgovarajui
format poruke i vraa informacije u stek tako da podaci na kraju stiu do aplikacije za koju su
namenjeni. Na slici se takoe vidi da postoji veza u oba smera izmedu slojeva u jednom sistemu i
odgovarajuih slojeva u drugom slstemu. To znai da sa Iogike take gledita, svaki sloj u modelu
obavlja funkcije kao da uspostavija vezu direktno sa sebi odgovarajuim slojem na udaIjenom sistemu.
Nijedan sloj ne zna ta se dogaa u slojevima koji se nalaze neposredno ispod njega, odnosno kako se
poruka prenost do odgovarajueg sloja na udaljenom raunaru.
Na primer, TCP deli velike poruke u manje poruke koje se zovu segmenti. Ovi segmenti zatim se
prenose u nie slojeve koji ih enkapsuliraju u IP datagrame, a zatim u protokol fizkog sloja, kao to je
Ethernet. Na prijemnom kraju, TCP softver ne mora da zna da je za prenos poruke upotrebljen
Ethernet, Token Ring ill neka druga tehnologija. Umesto toga, TCP softver na udaljenom sistemu
prima segmente koje je TCP softver na predajnom sistemu prvobitno poslao.
Enkapsulacija
Veina slojeva prikljuuje informacije podacima koje predaje niim slojevima. Ovi podaci zovu se
informacije zaglavlja. Na primer, jedan IP datagram sadri informacije zaglavija kao to su izvorna i
odredina adresa i brojevi portova. Kada se IP datagrami prenosi nanie u steku, on moe da se
enkapsulira u Ethernet okviru. Ethernet okvir dodaje sopstvene informacije zaglavija. U Ethernet
zaglaviju, umesto IP adresa, koriste se fizike MAC adrese.
Na prijemnom kraju komunikacije, informacije Ethernet zaglavlja se uklanjaju pre nego to se
preostali podaci predaju u stek. Na IP nivou uklanja se IP zaglavlje i podaci se vraaju nanie do TCP
softvera, i tako dalje. Dakle, svaki sloj na svakom raunaru stvarno vidi, uz nekoliko izuzetaka, samo
informacije zaglavlja koje je odgovarajui sloj na drugom raunaru prikljuio prvobitnoj poruci. Na
ovaj nain slojevi logiki komuriiciraju jedan sa drugim, bez obzira na to kako slojevi iznad ili ispod
njih interno rade.
U sledeim odeljcima opisane su funkcije koje obavlja svaki sloj, poevi od dna (fiziki sloj) i penjui
se prema vrhu. Vano je napomenuti da neki proizvoai kombinuju dva iii vie slojeva u jednu
softversku aplikaciju. Kao to smo ve rekli, sedmoslojni OS! referentni model je samo model. To je
nain da se tehnologije urnreavanja razmatraju na racionalan nain razumljiv za profesionalce. To ne
znai da svi proizvodi za umreavanje moraju da budu usaglaeni sa ovim modelom.
1. Fiziki sloj
Fiziki sloj predstavljaju fizike komponente koje sainjavaju hardver za urnreavanje, ukljuujui
mrene adaptere, konektore, mrene nosioce podataka (bakarne provodnike ili optike kablove) i tako
57
dalje. Jednostavno fiziki sloj prenosi podatke sa jednog na drugo rnesto. Ovaj sloj pokriva elektrine i
mehanike aspekte mree. Predstavlja najnii nivo OSI referentnog modela i pored specifikacija za
povezivanje raunara pokriva i deo koji se odnosi na detaljnu specifikaciju medija za povezivanje:
upredene parice (twisted-pair), optikog (fiber-optic) i koaksijalnog (coaxial) kabla. Standardi koji su
interesanrni za klijent server aplikacije a koji su u okviru ovog nivoa su IEEE 802.3 (Ethernet), IEEE
802.5 (Token Ring). Oni su zadueni da definiu zahteve za mrenim interfejs karticama kao i
softverske zahteve za MAC nivo (Media Access Control). Ovde su ukljueni i standardi koji definiu
serijsko povezivanje kao to su EIA232 i X.21 standardi. Od mrenih ureaja ovom nivou pripadaju
repetitori-pojaavai (repeaters) i multiplekseri. Na primer, u ovom sloju odluuje se o metodu koji se
koristi za kodiranje podataka u elektrine ili svetlosne signale u mrenim nosiocima podataka.
2. SIoj povezivanja podataka
Sloj povezivanja podataka obavija nekoliko funkcija koje je IEEE podelio u dva podsloja. Prvi je
logika kontrola veze(Logical Link Control, LLC), a drugi kontrola pristupa nosiocima podataka
(Media Access Control, MAC). Kao celina, sloj povezivanja podataka odgovoran je za prenos
podataka sa jednog mesta na drugo kao i za minimalno ispravljanje greaka. Svrha LLC-a je da
obezbedi pristupne take servisa (service access point, SAP) koje ureaji mogu da koriste za slanje
informacija. MAC komponenta vodi rauna o prenosu podataka i ispravljanju greaka. Sloj
povezivanja podataka odgovoran je, na primer, za sastavijanje Ethernet okvira. Tu spada formatiranje
informacija u zaglavlju u tana polja i smetanje podataka na pravo mesto. Funkcije koje rade u ovom
sloju takoe odreuju redosled interpretiranja bitova (to jest, sa veeg iii manjeg kraja) i dodaju
informacije kontrolnog zbira koje se koriste da bi se osiguralo da okviri stignu nedirnuti na svoje
odredite. Mreni komutatori(swiches) i mostovi(bridges) su mreni ureaji koji rade u ovom sloju
modela. Oni pregledaju MAC adrese paketa i koriste te informacije da bi odIuili da Ii da paket
proslede na drugi port.
3. Mreni sloj
Ethernet, Token Ring i FDDI (Fiber Distributed Data Interface) definiu zapise podataka paketa koji
cirkuliu izmeu MAC i Netware nivoa. Ovaj nivo je odgovoran za sviovanje i rutiranje poruka i
podataka na njihove odgovarajue destinacije. Zaduen je da omogui jedinstvenu mrenu adresu,
odredi put za podatke do odredita, podeli velike blokove podataka u manje pakete i izvri tekuu
kontrolu. Mreni sloj obezbeuje vane funkcije mrenom steku protokola. Ovde se prave protokoli
koji upravljaju nainom prenosa paketa u mrei ili usmeravanja paketa u drugu mreu. Na primer,
Internet protokol (IP) nalazi se u ovom sloju. IP adresiranje obavlja se u ovom sloju. Setite se da IP
adrese imaju dve komponente: mreni ID i ID raunara. Prema tome, paketi mogu da se prenose u
lokalnom LAN-u (korienjem ID-a raunara ili da se usmere u drugu mreu (korienjem mrenog
ID-a). Ovaj sloj je odgovoran i za podelu veih poruka u manje koje se smetaju u okvire napravljene u
sloju povezivanja podataka. Ova veliina zove se maksimalna jedinica prenosa (Maximal Transmision
Unit, MTU). Na prijemnom kraju, mreni sloj ponovo sastavlja manje poruke u vee, originalne
poruke, pre nego to preda podatke nave u transportni sloj. Najlaki nain da se setimo ovog sloja
jeste da zapamtimo da on obezbeuje adresiranje i usmeravanje. Trebalo bi da bude oigledno da na
ovom nivou rade tradicionalni usmerivai. Usmerivai koriste mrenu adresu protokola da bi odredili
na koji port treba proslediti paket.
4. Transportni sloj
Dok je mreni sloj odgovoran za usmeravanje paketa podataka, protokoli u transportnom sloju
preuzimaju dunost da se postaraju da ovi paketi stvarno budu preneseni i to tanim redosledom. Kada
se poruke sadre vie od jednog paketa, tada prenosni nivo sekvencira te poruke i regulie njihov
protok. On je odgovoran za siguran prenos poruka od jednog do drugog raunara tj. odredita. Ovaj
nivo uvodi svoje adrese koje se dodaju na mrene adrese. Zato to servisira procese na sistemima,
viestruke transportne adrese (izvor ili odredite) mogu da imaju istu mrenu adresu. Na primer, u
ovom sloju moe da se nae protokol za kontrolu prenosa (Transmission Control Protocol, TCP). TCP
58
koristi IP (u mrenom sloju), prati koji segmenti se gube u mrei i stara se da ih IP po potrebi ponovo
alje.
lako ovaj segment moe da obezbedi ponovno slanje izgubljenih paketa, on to ne mora da ini. Na
primer, u ovom sloju nalazi se protokol korisnikih datagrama (User Datagram Protocol, UDP). UDP
takoe koristi IP da bi preneo svoje poruke. Meutim, UDP minimalno upravlja porukama koje alje.
On ne potvruje prenos paketa, ali odgovara na ICMP poruke, kao to su one koje su napravijene da bi
usporile prenos kada podaci stiu na prijemni kraj prevelikom brzinom.
5. SIoj sesija
Sloj sesija odgovoran je za odluivanje o formatu podataka koji se prenose. Primeri protokola sesija su
pozivi udaljenih procedura (koristi ih NFS kao i druge aplikacije). Jo jedan nain posmatranje sloja
sesija jeste da njegovo funkcionisanje omoguuje procesima na umreenim raunarima da meusobno
komuniciraju. Ovaj nivo nam omoguava da se jedna aplikacija izvrava na dva ili vie razliitih
procesora. Zadatak je da tu aplikaciju svedu na jednu sesiju. Sesija je jedna razmena podataka-poruka
tj. dijalog koji vode dva procesora. U sluaju da neka stanica (procesor) otkae ili prekine rad ovaj
nivo treba da obezbedi da se sesija bezbedno zavri. TCP i NetBIOS su protokoli koji se nalaze u
ovom sloju sesije.
6. SIoj prezentacije
Sloj prezentacije interpretira stvarne podatke koji se razmenjuju. Na primer, razliiti stemi mogu da
koriste razliite metode predstavljanja brojeva sa pokretnim zarezom ili nekih drugih podataka. Na
ovom nivou se prevodi redosled bitova u bajtu. U ovom sloju obavlja se i neophodna konverzija. Pored
toga, upravo u ovorn sloju obavljaju se prevoenja izmeu razliitih metoda za ifrovanje znakova. Na
primer, kada jedan raunar koristi ASCII znakove, a drugi IBM-ovo EBCDIC ifrovanje, prevoenja
izmeu ova dva metoda predstavljanja znakova obavljaju se u sloju prezentacije
7. SIoj aplikacija
Korisnik stupa na scenu u sloju aplikacija. Bez aplikacija koje treba da koriste mreu, administratori
mrea ostali bi bez posla. Ovo je nivo gde se aplikacija direktno izvrava. Programer kodira jedan API
(Aplication Programing Interfaced) koji je definisan za taj nivo. Primeri mrenih komponenti koje se
nalaze u ovom sloju su mrene barijere ili umreeni sistemi datoteka (kac to je NFS). Krajnji korisnici
mogu da prepoznaju komponente sloja aplikacija kao programe koje svakodnevno koriste, na primer,
elektronsku potu i FTP.
o Komunikacioni posrednik
Softver komunikacionog posrednika obezbeuje sredinu kroz koju klijent i server komuniciraju radi
izvoenja specifinih akcija. On je logiki smeten izmeu klijenta i servera i obezbeuje specijalne
servise za izolovanje klijenta od detalja mrenih protokola i detalja u protokolima server procesa.
Takoe, on izoluje aplikacionog programera od internih poslova u serveru i od mrenih protokola.
Upotreba posrednika kod baza podataka donosi: mrenu nezavisnost (eone aplikacije mogu da
pristupe podacima bez obzira na protokol) i nezavisnost servera baze podataka (eone aplikacije mogu
da pristupe podacima na razliitim serverima baze podataka bez potrebe da se pie kod koji je
specifian za takav server baze podataka).
Za korienje baze podataka posrednik omoguuje programerima da koriste generike SQL reenice za
pristup razliitim i viestrukim serverima baze podataka. Posredniki nivo izoluje programera od
razlika izmeu SQL dijalekta transformiui SQL reenice u sintaksu koja se oekuje na serveru baze
podataka. Ovo je veoma znaajno, jer postoji veliki broj razliitih DBMS softvera, u kojima je
implementiran SQL sa razliitom sintaksom i sa razliitim funkcijama. Pored toga, podaci mogu biti
smeteni i u nerelacionim DBMS-ima koji ne podravaju SQL.
59
Da bi izvrio ove funkcije, komunikacioni posrednik radi u dva nivoa:
o Fiziki nivo, koji razmatra komunikaciju izmeu klijenta i servera. Fizika veza ukljuuje mreni
hardver i softver. Mreni softver sadri mrene protokole, a to su pravila koja kazuju kako raunar
mora interagovati sa ostalim raunarima u mrei i obezbeuje da taj raunar bude spreman da primi
i poalje signal od i prema ostalim raunarima u mrei. U veini sluajeva, fiziki nivo
komunikacionog posrednika jeste mrea, tj. mrene kartice i kablovi.
o Logiki nivo razmatra komunikaciju izmeu klijent i server procesa. Ovo je nivo gde klijent/server
konverzacija dolazi najvie do izraaja.
Da bi bolje razumeli kako u klijent/server okruenju putuju podaci i upravljake informacije, trebalo
bi da znamo vie detalja o komunikaciji raunara. Za ilustraciju ovih detalja koristiemo OSI referencu
mrenog modela koji je zasnovan na sedam nivoa koji su meusobno izolovani. Jedan nivo, da bi
obavio svoju funkciju ne mora poznavati detalje o radu sledeeg nivoa u nizu obrade. Ovaj model se
sastoji od sledeih nivoa:
1. Aplikacioni nivo. To je aplikacija krajnjeg korisnika. Kod klijenta su to eone aplikacije
(elektronska pota, radne tabele, programi za obradu teksta, itd.), a kod servera su to pozadinske
aplikacije.
2. Prezentacioni nivo. Obezbeuje funkcije formatiranja za aplikacioni nivo protokola kao to su
konverzija, kompresija, ifrovanje i sl. Drugim reima, ovaj sloj obezbeuje da se informacija
poalje u formi koja je razumljiva i upotrebljiva na odreditu.
3. Nivo sesije. Ovaj nivo obezbeuje uspostavljanje i kontrolu komunikacije izmeu aplikacija.
Obezbeuje bezbednost, dostavnost i komunikacioni oporavak.
4. Transportni nivo. On obezbeuje prepoznavanje greke i oporavak, obezbeujui na taj nain da se
svi podaci pravilno dostave, dodajui identifikator koji je specifian za transportni nivo.
5. Mreni nivo. Obezbeuje rutine za pakovanje razbijajui velike poruke na male delove. On deluje
kao mreni kontroler koji odluuje kojim putevima podaci mogu da se prebace na odredite.
6. Data-link nivo. Kreira okvire za prenos i kontrolie dodelu pristupa prema mrenom fizikom
medijumu (kablu). Ovaj nivo ukljuuje jo i proveru greke, korekciu i sl.
7. Fiziki nivo. Obezbeuje standardni postupak prenosa, sa elektrinim detaljima, mrenu karticu,
tip kabla, napon, itd. Fiziki prenosi okvire podataka kroz mreni kabl.


60
11 as Protokoli za povezivanje klijent server sistema

Povezivanjem dva ili vie raunarskih sitema (klijenti i serveri) putem razliitih mrenih topologija, ne
znai i potpunu interoperatibilnost izmeu njih. Potrebno je da se ti sistemi sloe oko mnogih stvari
koje utiu na njihovu vezu a to su: naini uspostavljanja veze kod poetka prenosa podataka, vrste
poruka koje se razmenjuju, formati podataka i poruka, razreavanje incidentnih situacija (loi podaci,
prekid veze i td.), kodiranje i dekodiranje podataka, strategije korienja mrenih resursa i td.
Kombinacijom mrenih protokola kao to su Novelov IPX/SPX. NetBIOS, TCP/IP, i
interoperatibiolnih udaljenih procesa kao to je RPC (Remote Procedure Call) tehnologija postie se
potpuna interoperatibilnost izmeu dva povezana mrena segmenta. Drugim reima, kao to izmeu
ljudi postoji komunikacija koja moe da se uspostavi na vie razliitih jezika, tako i izmeu mrenih
segmenata postoji veliki broj protokola koji im pomau da bezbedno i sigurno razmenjuju podatke.
Normalno oba segmenta moraju da razgovaraju na istom jeziku tj. da koriste iste protokole kako bi
se potpuno razumeli i na taj nain obezbedili normalno funkcionisanje veze kako u LAN okruenju
tako i ire u okviru WAN mree.
Verovatno najpoznatija WAN mrea koja se sastoji od ogromnog broja manjih mrea poznata je kao
Internet. Njen istorijat datira jo od kraja 60-tih godina prolog veka, kada je Advanced Research
Projects agencija (ARPA) amerikog ministarstva odbrane, poela da prikuplja sredstva od
univerziteta i privatnih organizacija za razvoj komunikacionih sistema. Istraivanja su na kraju dovela
do razvoja ARPANET-a, male eksperimentalne mree koja je demonstrirala mogunost povezivanja
razliitih raunara pomou mree sa komutacijom paketa podataka. Prvi protokol koji je upravljao
ARPANET-om je bio NCP (Network Control Protocol) i on je predstavljao zaetak svih dananjih
savremenih protokola poznatih pod nazivom TCP/IP skup protokola. Daljim razvojem ove mree ona
je znaajno narasla i polako prerasla u Internet koji danas povezuje na hiljade univerziteta, privatnih
institucija i vladinih agencija irom sveta. Teko je proceniti koliko ljudi danas koristi Internet, ali sa
mreama koje danas postoje bukvalno u svim privatnim i javnim organizacijama i sa sve veim brojem
Internet provajdera, broj korisnika dostie desetine miliona, a sasvim je mogue da je re i o nekoliko
milijardi korisnika irom sveta.

Jedan od najdominantnih pojmova koji je u neku ruku i postao sinonim za Internet mrenu
komunikaciju je TCP/IP skup protokola. TCP/IP predstavlja primarni mreni protokol koji se koristi na
Internetu i za razliku od mnogih drugih protokola on nema svog vlasnika tj. njega nije razvijao samo
jedan proizvoa. Razvijen je da bi obezbedio vezu preko mree izmeu raunara razliitih
proizvoaa (kao to su IBM i Apple), tako da jedan protokol (ili vie protokola) moe da se koristi za
izradu mree, bez obzira na to koji se izvrni raunarski hardver koristi. Tokom vremena TCP/IP se
razvijao i napredovao zahvaljujui brojnim pojedincima koji su imali mogunosti da daju svoj
doprinos njegovom napredku. RFC (Request For Comments - zahtevi za komentarima) dokumenti
predstavljaju dokumente koji su otvoreni za sugestije u vezi unapreenja postojeih i izrade novih
protokola, koji se analiziraju od strane razliitih grupa specijalista za pojedine oblasti. TCP/IP je
razvijan pomou ovog metoda da bi obezbedio vezu preko mree, izmeu razliitih hardverskih
konfigiracija raunarskih sistema. Oslobaajui se u toku razvoja od uticaja samo jednog proizvoaa,
TCP/IP je razvijen tako da zadovolji hardverske potrebe mnogih proizvoaa, a ne samo jednog. OSI
(Open System Interconnect otvoreni sistem uzajamnog povezivanja) predstavlja referentni model koji
se koristi uglavnom kao radni okvir u kome mogu de se sprovode diskusije mrenih protokola. Ovaj
model je 1984 godine razvio ISO (International Organization for Standardization ) i on definie
stekove protokola u modularnom obliku i podrazumeva da se svaka mrena aplikacija moe predstaviti
u sedam meusobno povezanih slojeva. Kako je razvoj TCP/IP protokola poeo mnogo ranije nego to
je definisan ovaj referentni model OSI umreavanja, za oekivati je da se TCI/IP protokoli ne uklapaju
uvek u sedam slojeva OSI referentnog modela. ISO je koristio ovaj model da zapravo razvije skup
otvorenih mrenih protokola, ali oni nikada nisu bili iroko prihvaeni. Meutim, OSI referentni model
danas se i dalje koristi kada se govori o mrenim protokolima. Vano je da uoi da je i TCp/IP razvijan
na osnovu slinog, mada manjeg modularnog referentnog model DOD ( Department of Defense ) ili
61
DARPA modela. Na slici 1. su prikazana etri sloja od kojih se sastoji TCP/IP DOD model i kako se
svaki od ovih slojeva odnosi prema OSI referentnom modelu.
OSI model Sloj TCP/IP model
Aplikacija 7
Aplikacija Prezentacija 6
Sesija 5
Transport 4 Transport
Mrea 3 Mrea
Podataci 2
Pristup na mreu
Fiziki 1
Slika br. 1
Kao to se sa slike moe videti TCP/IP se ne uklapa tano u OSI model, ali i dalje je mogue da se
pozovete na ovaj model kada raspravljate o izvesnim aspektima protokola i servisa koje obezbeuje
TCP/IP.
Skarenica TCP/IP odnosi se na Transmission Control Protocol/Internet Protocol (protokol za
kontrolu prenosa/Internet protokol). Pored ova dva znaajna protokola, mnogi drugi srodni protokoli i
usluni programi obino se grupiu zajedno i nazivaju se TCP/IP Protocol Suite -TCP/IP skup (ili
stek) protokola. Prema tome pod pojmom TCP/IP podrzumevamo skup protokola i uslunih programa
koji nam stoje na raspolaganju kod Internet komunikacija. Neki od tih protokola i programa su:
1. IP (Internet Protocol) - predstavlja jedan nesiguran protokol bez uspostavljanja veze koji se
koristi kao sredstvo za prenos datagrama sa jednog raunara na drugi i za adresiranje izmeu
mrea. Ovde treba objasniti pojmove kao to su segment, datagram, paket i okvir jer se oni
obino pogreno tumae i zamenjuju. Poevi od TCP protokola, podaci koji treba da se alju
nazivaju se segmentima. TCP proputa segmente IP-u, koji pravi pakete ili datagrame od tih
segmenata. IP proputa podatke nanie u stek, a ovi, kada stignu na fiziki provodnik, dobijaju
naziv okvir. Prema tome, u svim praktinim primenama moe se smatrati da su paketi i
datagrami jedno te isto.
2. TCP (Transmission Control Protokol) - je protokol koji koristi IP, ali obezbeuje vii nivo
funkcionalnosti, pri kome se proverava da li odreeni datagrami kojima upravlja IP zaista stiu
sa odreenog odredita i do njega. TCP je protokol orijentisan na uspostavljanje veze, koji
zahteva da se uspostavi sesija za upravljanje komunikacijama izmeu dve take na mrei.
3. UDP (User Datagram Protocol) takoe koristi IP da alje podatke preko mree. Dok TCP
koristi mehanizam za potvrivanje da bi osigurao pouzdanu isporuku, UDP to ne ini. On je
namenjen za korienje u aplikacijama kod kojih nije neophodan garantovani servis isporuke
koji obezbeuje TCP. Servis DNS(Domain Name System - sistem imena domena) predstavlja
primer aplikacije koja koristi UDP. Aplikacije koje koriste UDP odgovorne su za preduzimanje
funkcija provere radi pouzdane isporuke koju inae obezbeuje TCP.
4. ICMP (Internet Control Message Protocol - protokol koji upravlja Internetom putem poruka)
predstavlja neophodan deo svake TCP/IP implementacije, a funkcije koje on sprovodi veoma
su vane za usmerivae i ostale mrene ureaje koji komuniciraju preko TCP/IP-a. Slino kao i
TCP i UDP i ovaj protokol koristi IP protokol za slanje svojih poruka. Dok TCP obino moe
da se oporavi zbog isputenih datagrama tako to jednostavno zatrai od IP-a da ih ponovo
prenese, ICMP je mehanizam za izvetavanje koji i IP koristi a samim tim i mnogi protokoli
koji koriste IP (ako ste koristili komande ping ili traceroute onda ste sigurno koristili usluge
ICMP-a).
5. IGMP ( Internet Group Menagment Protocol protokol za upravljanje grupama na Internetu)
slui za upravljanje grupama sistema koji su istovremeno lanovi vie grupa. Vieznano
upuivanje ( multicasting ) predstavlja tehniku koja doputa da se isti datagrami isporue na
vie razliitih odredita odjednom. Upravo ovaj protokol igra glavnu ulogu u ispunjavanju ove
funkcije.
6. ARP ( Address Resolution Protocol protokol za razreavanje adresa ) koristi se da bi raunar
odredio koje hardverske adrese treba da se pridrue IP adresi. Ovo je neophodno poto se IP
62
adrese koriste za usmeravanje podataka izmeu mrea, dok se komunikacije na lokalnom
mrenom segmentu obavljaju pomou fiksnih hardverskih adresa mrenih kartica.
7. RARP (Protocol Reverse Address Resolution ) je protokol slian ARP-u, ali radi suprotno. To
je stariji protokol koji je razvijen da bi omoguio raunaru da utvrdi koju IP adresu treba da
koristi, na osnovu tabele koja se obino uva na usmerivau. U optem sluaju, ovu
funkcionalnost preuzeli su drugi protokoli, kao to su BOOTP i DHCP. Meutim jo uvek
moemo da pronaemo da se ovaj protokol koristi u mnogim mreama koje koriste stariju i
zastarelu opremu iji radni vek polako istie.
8. BOOTP ( Bootstrap Protocol ) predstavlja protokol za podizanjem sistema. I on predstavlja
stariji protokol, koji je u optem sluaju zamenjen DHCP-om. Praktino veina DHCP servera
moe da radi i kao BOOTP serveri. BOOTP je napravljen da bi omoguio stanicama bez
diskova da mogu da uitavju konfiguracione informacije, kao to su IP adresa i naziv servera,
koje mogu da se koriste za uitavanje operativnog sistema. Budui da radne stanice bez diskova
nemaju lokalne ureaje za smetanje podataka (osim operativne RAM memorije) one ne mogu
same da uvaju ove informacije izmeu dva podizanja sistema.
9. SMTP ( Simple Mail Transport Protocol jednostavni protokol za upravljenje potom) koristi
se za prenos poruka od klijenta do SMTP servera, kao i za prenos tih poruka od jednog do
drugog SMTP servera. Poto SMTP predstavlja aplikacioni protokol, on je pridruen broju
porta isto kao i FTP, Telnet ili drugi aplikacioni protokoli. Port koji se obino koristi za SMTP
je TCP port 25. Iako je TCP verzija koja se najvie koristi za implementaciju SMTP-a on moe
da se koristi i sa drugim protokolima. Kao aplikacioni protokol, SMTP se oslanja na
mehanizme detekcija i ispravljanja greaka koji se nalaze u oanovnim protokolima i ne
implementira ovu vrstu funkcija u samom SMTP-u.
10. SNMP ( Simple Network Management Protocol jednostavni protokol za upravljanjem
mreom) napravljen je da olaka upravljanje mrenim ureajima i raunarima sa neke centralne
lokacije. Kako formiranje mree u dananjim uslovima podrazumeva integrisanje proizvoda
razliitih proizvoaa tako je potrebno imati neki servis koji e nam pomoi da upravljamo
svim tim razliitim komponentama sa jedne centralne lokacije. Upravo tu dolazi do izraaja
ovaj protokol koji treba da obezbedi jednostavnost u upravljanju mrenih komponenti (kao
prostih mostova i habova tako i sloenijih usmerivaa ili komutatora).
11. RMON ( Remote Monitoring Protocol ) je razvijen radi daljeg unapreenja mogunosti
administratora da daljinskim putem moe da upravlja udaljenim raunarima i mrenim
ureajima.
12. WINS ( Windows Internet Name Service ) predstavlja Microsoft-ov NetBIOS Name Server
(NBNS) koji je razvijen za razreavanje problema oko dodele imena raunarima u mrei,
zasnovan je na klijent server arhitekturi. WINS koristi dinamiku bazu podataka u kojoj se
registracija imena sprovodi putem poruka sa jednoznanim upuivanjem (direktan kontakt)
izmeu servera i odreenog WINS klijenta. Poto WINS server ne mora da bude na istom
segmentu mree kao i klijent i poto nema difuziono upuenih poruka koje mogu da izazovu
nered na mrenom medijumu, WINS predstavlja efikasan metod za razreavanje problema
dodele imena sve do pojave DNS servera i Active Directory-aktivnog diretorijuma.
13. DHCP(Dynamic Host Configuration Protocol-protokol za dinamiko konfigurisanje raunara)
oslobaa mrenog administratora od dunosti kao to su runo konfigurisanje svakog
umreenog raunara adresnim i drugim informacijama.
14. DNS ( Domain Name System ) predstavlja hijerarhijski sistem imenovanja koji se koristi na
Internetu i u veini TCP/IP mrea. Na primer, kada u svom Internet pretraivau otkucate
www.eunet.yu , va TCP/IP stek alje zahtev DNS serveru da utvrdi IP adresu koja je
pridruena tom imenu. Od tog trenutka pa nadalje, pretraiva moe da koristi tu IP adresu da
alje zahteve toj Web strani.
15. FTP ( File Transfer Protocol protokol za prenos datoteka) predstavlja sloen protokol koji
omoguava razmenu datoteka sa podacima, pomou razliitih metoda za prikaz podataka i za
smetanje datoteka. U svom najjednostavnjem obliku on koristi razmenu nezatienih imena i
63
lozinki, tako da nije osmiljen kao posebno bezbedan usluni program. To je i normalno jer
kada je on razvijan napadi na bezbednost nisu se smatrali kao ozbiljna pretnja.
16. TELNET predstavlja jo jedan vrlo koristan alat koji ini skup TCP/IP protokola. Telnet
aplikacija udaljeni terminal pmoguava vam da uspostavite interaktivnu sesiju za
prijavljivanje na sistem udaljenog raunara i da izvravate komande kao da ste se diretno
prijavili na taj udaljeni raunar. Telnet se ne koristi samo da bi se uspostavila sesija sa
raunarom, ve je takoe ugraen i u mnoge mrene ureaje kao to su serveri za tampanje,
habovi, komutatori i usmerivai. Korienje telneta predstavlja jednostavan nain za
upravljanje sa vie vorova u mrei, raunara ili mrenih ureaja, sa neke centralne lokacije.
Na slici broj 2 prikazan je raspored svih ovih protokola u odnosu na referentni OSI model
umreavanja. Sa slike se vidi da IP predstavlja osnovni protokol koji se u TCP/IP skupu koristi za
isporuku datagrama. Takoe moemo da primetimo da da protokol TCP/IP i srodni protokoli rade
iznad fizikih komponenti mree. Zbog toga je jednostavno prilagoditi TCP/IP za razliite vrste mrea,
kao to su Ethernet ili Token Ring. Kada se radi o korienju protokola TCP/IP u mrei, ono to on
odrauje jeste prenos IP paketa u koji ste upakovali svoje podatke i kojeg ste prosledili nadole, ka
stvarnom mrenom hardveru.
HTTP SMTP FTP TELNET DNS SNMP voice over IP

TCP UDP (4 sloj) Segment

IP ICMP IGMP (3 sloj) Paket/Datagram

Sloj veze podataka (2 sloj)

Fiziki mreni medijum (1 sloj) Okvir

Slika broj 2.

Budui da IP predstavlja zajedniki imenalac TCP/IP skupa u narednim poglavljima malo vie emo
objasniti taj protokol, a ksnije i TCP i UDP protokol.

64
12 as IP Internet Protocol

U skraenom nazivu protokola TCP/IP, Internet protokol se nalazi kao druga komponenta, ali prema
funkciji koju obavlja moe se slobodno rei da je on u stvari mnogo znaajnija komponenta. On
predstavlja osnovni protokol preko koga se prebacuju paketi sa jednog mesta na drugo i gotovo svi
protokoli iz skupa TCP/IP ga koriste. Osnovna uloga ovog protokola je da on treba da obezbedi mreni
servis bez potvrivanja i bez uspostavljanja veze, a pored toga treba da obezbedi mehanizam za
adresiranje koji koristi TCP/IP. Sledeih nekoliko karakteristika izdvaja IP protokol od ostalih:
IP predstavlja protokol bez uspostavljanja veze kod koga nije potrebno nikakvo podeavanje. On je
jedan nepovezan protokol kod koga svaki paket predstavlja poseban entitet koji sa IP aspekta nije ni
u kakvoj vezi sa sa drugim paketima. IP ne kontaktira odredini raunar ili mreni ureaj da bi
uspostavio putanju koja e se koristiti za slanje podataka. Umesto toga, on samo prihvata podatke od
protokola vieg nivoa, kao to su TCP ili UDP, formatira pakete koji sadre adresne informacije i
alje te pakete na njihov put, koristei kao podlogu fiziku mrenu arhitekturu. Kada protokoli vieg
nivoa koriste IP za isporuku svojih informacionih podataka, ne postoji garancija da e svaki paket
koji nastane na IP nivou koristiti istu putanju do svog odredita. Vrlo je verovatno da e serija paketa
koju je sainio protokol vieg nivoa stii na odredite u sekvenci koja ima sasvim drugaiji redosled
od onoga po kome je zapoet prenos. ak ta vie, IP uopte i ne vodi rauna o tome da li su svi
paketi stigli do odredine take. Ta funkcija je preputena protokolu koji koristi IP za isporuku koji
je zaduen za proveru greaka i potvrivanja ispravnog prijema.
IP je protokol bez potvrivanja. U veini sluajeva on ne proverava da li je datagram nedirnut stigao
na svoje odredite. On samo formatira informacije u pakete i alje ih du provodnog medija. Bez
mehanizma za potvrivanje, IP mogu da koriste drugi protokoli kojima ova funkcionalnost nije
potrebna, i na taj nain eliminiu dodatno troenje vremena koje prati potvrivanje. Taj zadatak moe
da odradi neki vii protokol (TCP) ili sama aplikacija kojoj je bitno da se svaki paket ispravno stigne
do odredita. Meutim, i na nivou IP postoji poseban protokol , ICMP (Internet Control Message
Protocol ), koji posredno pomae IP-u u reavanju ovog zadatka, utoliko to moe da utie da se
neki uslovi slanja koriguju. Na primer, iako IP ne dobija natrag potvrdu sa odredita IP paketa,
dobie ICMP poruku da uspori, ukoliko se paketi alju bre nego to mogu da se obrade na
odreditu.
IP je nepouzdan. To je lako uoiti budui da je u pitanju protokol bez uspostavljanja veze i bez
provere da paketi stiu na svoje odredite, kao ni po kom redosledu oni stiu. Drugim reima za IP je
samo bitna brzina isporuke paketa. Postoji jo jedan razlog zbog koga se IP smatra nepouzdanim
protokolom a to je to IP implementira TTL (Time To Live) vrednost, koja ograniava broj mrenih
usmerivaa ili raunara kroz koje datagram moe da prolazi. Kada se ova granica dostigne, taj
datagram se jednostavno odbacuje a kako IP nema mehanizme za otkrivanje ovog problema
(potvrivanje prijema) on je potpuno nesvestan ovog problema. Meutim TTL ima i svoje prednosti
a to su u sluaju da administrator sistema pogreno konfigurie usmerivae (router) i tako napravi
beskonanu petlju u mrei. Da nije TTL vrednosti, paket bi beskonano putovao od jednog do
drugog usmerivaa i tako nepotrebno optereivao gustinu saobraaja na mrei.
IP obezbeuje adresni prostor za TCP/IP. Adresiranje predstavlja najvaniju funkciju koja je
implementirana u IP sloju. Svaka mrena kartica koja se nalazi u bilo kom raunaru ima jedinstvenu
fiksnu (burned in) adresu koja se naziva MAC (Media Access Control ) adresom. Ove adrese
obezbeuje proizvoa mrenih kartica i ona se utiskuje u svaku karticu u procesu proizvodnje tih
kartica. Adrese koje se tada ubacuju u kartice formiraju takozvani ravni adresni prostor koji nam
ne dozvoljava da moemo efikasno da organizujemo usmeravnje datagrama iz jednog sistema ili
mree u druge. Ta MAC adresa koja se dodeljuje kartici je jedinstvena i sastoji se od 6 bajtova (48
bitova). Prvi deo te adrese identifikuje proizvoaa a ostali deo predstavlja obini serijski broj
kartice koji se redom dodeljuje svakoj kartici. Obino je prikazana u vidu heksadecimalnih brojeva
kao na primer: 00-80-C8-AB-34-56. IP adresa se takoe sastoji iz dva dela i to adrese mree i adrese
raunara. Zahvaljujui mrenoj adresi mogue je napraviti hijerarhiju koja omoguava efikasne
mehanizme za usmeravanje pri slanju podataka u druge mree. Dok odreena mrea moe da ima
65
mrene adaptere koji su od vie isporuilaca a samim tim i MAC adrese koje su razliite, moe se
slobodno rei sluajni brojevi, dotle su IP adrese organizovane po mreama. Samim tim usmerivai
ne moraju da imaju na milone MAC adresa, ve sadre samo IP adrese kojih ima onoliko koliko i
raunara ili mrenih ureaja koji su vezani na isti usmeriva.

ta zapravo radi IP ?
Osnovna uloga IP protokola je da prihvata podatke iz vieg sloja i da vri njihovo usitnjavanje u manje
pakete (ili datagrame) i iste prenosi preko mree. Na prijemnom kraju IP ponovo prikuplja te
datagrame i prosleuje ih ka viem sloju, ka protokolu vieg nivoa koji koristi IP. Da bi se svaki paket
uruio, IP u zaglavlju datagrama postavlja IP adrese izvora i odredita. IP takoe na osnovu prorauna
proverava ispravnost informacije u zaglavlju kako bi mogao da je potvrdi. Meutim, to se samo radi sa
podacima u zaglavlju a ne i sa kompletnim paketom tj. ta se funkcija ne izvrava nad podacima u
paketu. Kao to smo ranije napomenuli velika prednost TCP/IP je da on doputa mreama da koriste
razliite medijume za meusobne veze. Dok jedna mrea moe da koristi format okvira Ethernet 802,
druga moe da koristi FDDI (Fiber Distributed Data Interface). Svaki od ovih okvira nieg nivoa ima
svoje posebno zaglavlje koje sadri informacije, koje su za tu tehnologiju potrebne, za slanje okvira
du fizikog mrenog medijuma. Na ovom niem nivou, u steku protokola, IP datagram se nalazi u
delu sa podacima u odreenom okviru. Poto IP doda svoje informacije iz zaglavlja u poruku koju
prima od protokola vieg nivoa, i poto napravi datagram odgovarajue veliine, on taj datagram
prebacuje u sloj Network Access, koji taj IP datagram ubacuje u Ethernet okvir. Na prijemnom kraju,
informacije se skidaju iz zaglavlja Ethernet okvira, a IP datagram se prosleuje navie u stek koji
obrauje IP protokol. Na slian nain, informacije iz IP zaglavlja skidaju protokoli vieg nivoa koji
samo koriste IP, kao to su TCP ili UDP.
Iako je veini ljudi IP poznat kao transportni protokol koji koriste protokoli vieg nivoa, jedna od
njegovih vanijih funkcija je da obezbedi adresni prostor za potrebe TCP/IP skupa. Uvoenjem IP
adresa obezbeen je hijerarhijski adresni prostor za mree, tako da je sada bilo lako da se konstruie
usmeriva koji e koristiti deo te IP adrese koji e predstavljati adresu mree. Na taj nain kada
datagram stigne do usmerivaa on na osnovu mrenog dela adrese usmeri podatke prema toj
odredinoj mrei. Kada datagram stigne do odredine mree tada se tek koristi drugi deo adrese tj.
adresa raunara u toj mrei. Bez mogunosti odreivanja mrene adrese i adrese raunara, hijerarhijski
adresni prostor ne moe da se uspostavi, a usmeravanje bi zahtevalo tabele usmeravanja koje bi
doslovno morale da sadre sve adrese svakog raunara ili ureaja u odreenoj mrei. Umesto toga,
ograniavanjem tabela za usmeravanje samo na uvanje mrenih adresa, ovo postaje jednostavan
postupak.
Postoje tri vrste IP adresa i to:
Unicast (jednoznano upuivanje) Ova vrsta adresa je najuobiajeni tip IP adrese. Ona na
jednostavan i jedinstven nain identifikuje jedan raunar u odreenoj mrei.
Broadcast (difuzno upuivanje) Ne treba ga meati sa difuznim upuivanjem (broadcast) kod
Ethernet okvira. IP takoe ima ovu mogunost i podeava za sebe skup adresa koje mogu da se
koriste za difuziono upuivanje, ime se alju podaci svakom sistemu na odreenoj mrei.
Multicast (vieznano upuivanje) Slino adresama za difuziono upuivanje, adrese za
vieznano upuivanje alju podatke na vie odredita. Razlika izmeu adresa za vieznano i
difuziono upuivanje jeste u tome to adresa za vieznano upuivanje moe da alje podatke na
vie mrea, gde ih primaju raunari koji su konfigurisani za prijem tih podataka.

Sve IP adrese takoe moemo podeliti na vie adresnih klasa u zavisnosti od veliine mrenog i
raunarskog dela IP adrese. Klase IP adresa su prvo definisane u preporuci RFC (Request for coments)
791. Iako je ovaj sistem klasa sluio svrsi dug niz godina, dananje usmeravanje na Internetu mnogo je
sloenije od onoga to ove jednostavne klase adresa doputaju. Meutim, od sutinskog je znaaja da
se razumeju klase adresa u lokalnom LAN-u ili korporativnoj mrei. Dok su se MAC adrese sastojale
od 6 bajta (48 bita) i heksadecimalno se prikazivale, dotle se IP adrese sastoje od 4 bajta (32 bita) i
predstavljaju se u vidu 4 decimalna broja sa takama izmeu njih. Sve IP adrese se dele na tri glavne
66
klase adresa i to A, B i C klasu, i dve manje poznate D i E klasu. Svaka od ovih klasa
koristi drugaiji deo IP adresnih bitova za identifikaciju mree. Potreba da se mree klasifikuju
posledica je potrebe da se prave mree razliitih veliina. Dok neki mali LAN moe da ima nekoliko
ili nekoliko stotina raunara, vee mree mogu da imaju na hiljade pa i vie umreenih raunara.
Sistem klasa IP adresa ostvaruje se pomou razliitog broja bitova u celokupnoj adresi za identifikaciju
mrenog i raunarskog dela IP adrese. Uz to, prvih nekoliko bitova u binearnoj adresi koristi se za
indikaciju klase kojoj pripada odreena adresa. Ukupan broj bitova raspoloivih za adresiranje je uvek
32 bita. Budui da broj bitova koji se koriste za identifikaciju mree varira u zavisnosti od klase,
oigledno je da varira i preostali deo bitova koji se inae koristi za adresiranje raunara u mrei. To
znai da neke klase mogu da adresiraju vei broj mrea, a kao posledica ovoga je da onda one druge
mree mogu da identifikuju vei broj raunara u svakoj mrei.
Prva etri bita u IP adresi govore kojoj klasi pripada sama adresa i to:
1. Klasa A 0 x x x ( 0.0.0.0 127.255.255.255) 00 00 00 00 - 7F FF FF FF
2. Klasa B 1 0 x x (128.0.0.0 191.255.255.255) 80 00 00 00 - BF FF FF FF
3. Klasa C 1 1 0 x (192.0.0.0 223.255.255.255) C0 00 00 00 - DF FF FF FF
4. Klasa D 1 1 1 0 (224.0.0.0 239.255.255.255) E0 00 00 00 - EF FF FF FF
5. Klasa E 1 1 1 1 (240.0.0.0 255.255.255.255) F0 00 00 00 - FF FF FF FF
( x oznaava bilo koju vrednost i ne utie na odreivanje klase).
Klasa A adresa
Kao to je prikazano u gornjoj tabeli, svaka IP adresa koja ima nulu na prvoj poziciji pripada klasi A
adresa. Za adresiranje mrenog dela adrese u klasi A koristi se samo prvi bajt (prvih 8 bitova) i to je u
sistemu IP adresa najmanji opseg koji se koristi. Preostala 3 bajta (24 bita) koristi se za formiranje
adrese raunara u mrei. Prema tome klasa A moe da adresira najmanji broj mrea ali zato se u ovoj
klasi moe adresirati najvei broj raunara. Kako je prvi bit rezervisan za adresu mree (uvek je jednak
0), preostaje sedam bitova za adresiranje mrea kojima moemo da adresiramo 127 razliitih mrea, ali
zato imamo 24 bita za adresiranje raunara to znai da imamo 16 777 216 (2
24
) razliitih adresa koje
moemo dodeliti raunarima.
Klasa B adresa
Da bi utvrdili da li je u pitanju klasa B IP adrese potrebno je pogledati prva dva bita IP adrese. Ako su
ona 10 onda smo sigurni da ta adresa pripada klasi B. Kod klase B prva dva bajta se koriste za
adresiranje mree dok se preostala dva bajta koriste za adresiranje raunara. Pa prema tome ovde
imamo na raspolaganju 16 384 moguih (2
14
) mrenih adresa i 65 536 ( 2
16
) adresa koje moemo
dodelti razliitim raunarima u mrei. Do razliitog broja adresa mrea i raunara dolazi zbog toga to
su u mrenoj adresi rezervisana prva dva bita za oznaku klase IP adrese pa je od tuda smanjen broj
adresa za mree.
Klasa C adresa
Opseg adresa klase C ima uvek prva tri bita postavljena na 110. U ovoj klasi sa prva tri bajta koriste
za adresiranje mrea to isnosi 2 097 152 adresa (2
21
), a preostali jedan bajt adresira 256 (0-255)
razliitih raunara u mrei.
Klasa D adresa
Prve tri klase adresa predstavljaju one adrese koje se standardno koriste u IP adresiranju. Opseg klase
D rezervisan je za grupno korienje slanja na vie adresa (multicasting). Slanje na vie adresa
predstavlja postupak kada se paketi alju na vie raunara odjednom. Ovde se ne koriste nikakvi
posebni bajtovi za adresiranje mrea i raunara ve se ukupno moe napraviti 268 435 456 (2
28
)
jedinstvenih adresa.
Klasa E adresa
Ukoliko u IP adresi vidimo da stoje 1 na prvih etiri mesta-bita onda smo sigurni da ta adresa pripada
klasi E adresa. Adrese klase E su rezervisane za buduu upotrebu i obino se ne sreu na veini mrea
koje su povezane na Internet.

U razreavanju problema oko dodele IP adresa moramo pomenuti kako se to u praksi radi. Ma koliko
da je adresni prostor, koji dozvoljava dodelu IP adresa, veliki on je ipak konaan i da ne postoji jedna
67
tehnika poznata kao NAT (Network Address Transslation) on bi brzo bio dostignut. Prevoenje
mrenih adresa (NAT) moe da se koristi sa usmerivaima, tako da moete da koristite samo adresni
prostor svoje interne mree, dok su usmerivau koji predstavlja vezu prema Internetu dodeljuje jedna
ili vie stvarnih registrovanih adresa. Koristei NAT taj usmeriva moe da manipulie IP adresama i
portovima, odnosno da se ponaa kao proxy server za klijente u internoj mrei kada komuniciraju sa
spoljanjim svetom. U praksi su poznata nekoliko opsega koji su opet putem RFC dokumenta broj
1918 definisana za upotrebu u lokalnim Intranet okruenjima i to su:
10.0.0.0 do 10.255.255.255
172.16.0.0 do 172.31.255.255
192.168.0.0 do 192.168.255.255
Sve ove adrese nisu validne za Internet pa prema tome vie privatnih mrea mogu da koriste ove
ospege za definisanje svog Intranet okruenja.
Postoji nekoliko izuzetaka koji se izdvajaju iz ukupnog broja adresa koje su mogue u klasama adresa.
Na primer, sve adrese koje zapoinju sa adresom 127 u prvom bajtu nisu validne izvan lokalnog
raunara. Adresa 127.0.0.1 (koja spada u opseg adresa A klase) uobiajeno se naziva adresom povratne
petlje (loopback) i koristi se za testiranje lokalnog TCP/IP steka da bi se utvrdilo da li su konfiguracija
i funkcionisanje korektni. Ostali izuzetci obuhvataju vrednosti 0 i 255. Kada se 0 koristi u mrenom
delu adrese tada ona oznaava trenutnu mreu. Broj 255 se koristi u adresi za navoenje difuziono
upuene poruke. Uzimajui u obzir sve ove izuzetke onda dolazimo do stvarnog broja mrea i raunara
koje moemo da adresiramo u svakoj klasi i on izgleda ovako:
Klasa A 126 mrea 16 777 214 raunara
Klasa B 16 384 mrea 65 534 raunara
Klasa C 2 097 152 mree 254 raunara.
Ovde treba pomenuti jo jednu tehniku koja se koristi da bi se poveao broj razliitih mrea a to je
tehnika deljenja jednog adfresnog prostora na manje jedinice poznate kao podmree (subnets).
Primenom maske podmree mogue je pozajmiti bitove iz dela IP adrese za raunare, za formiranje
novih mrea. Maska podmrea je takoe 32-bitna binarna vrednost kao i IP adresa ali to nije adresa
ve niz bitova koji se koristi za identifikaciju dela ukupne IP adrese koji treba da se koristi za
identifikaciju mree i podmree. Jednostavnom AND operacijom izmeu maske adrese i IP adrese
dolazimo do konane adrese koja je validna na mrei. Prema tome u zavisnosti od klase adresa imamo
i odgovarajue maske. Tako klasi A odgovara maska 255.0.0.0, klasi B maska 255.255.0.0 i klasi C
maska 255.255.255.0. Jednostavnim maskiranjem dela adrese koji ukazuje na adresu raunara mi
moemo proiriti broj adresa kojima adresiramo mreu tj. u ovom sluaju podmeu. Tako na primer
ako koristimo masku 255.255.255.128 mi moemo da adrese iz klase C podelimo na dve podmree i to
za prvu podmreu od adresa 192.113.255.1 do 192.113.255.128 i za drugu podmreu od
192.113.255.129 do 192.113.255.254. Slino ovome ako koristimo masku 255.255.255.192 mi
moemo da izvrimo podelu adresnog prostora iz klase C na 4 podmree.

Novi razvoj internet protokola - IPv6
Sve ovo to smo do sada objanjavali odnosi se na internet protokol verzije 4IPv4. Sve vei razvoj
Interneta kao i sve vea potreba za dodeljivanjem fiksnih IP brojeva pojedinim entitetima na mrei
doveli bi do manjka IP adresa u skoroj budunosti. Ljudi razmiljaju o ovom problemu ve godinama.
Internet Engineering Task Force (IETF) poeo je 1991. godine da razmatra problem promene
postojeeg IP-ja i kreiranje nove generacije IP-ja, neformalno nazvane IPng (IP Next Generation - IP
nove generacije). U pokuaju da se ukljui kompjuterska zajednica, pozvani su razni profesionalci
(istraivai, proizvoai, prodavci, programeri, itd) da daju svoje predloge.
Oformijeni komitet nazvan IPng Directorate razmotrio je predloge i mnoge odbacio, jer su bili
namenjeni specijalnim zahtevima, ili su bili isuvie kompleksni. Meutim, jedan predlog koji je
ukljuivao dizajn pod nazivom Simple Internet Protocol - SIP bio je proiren tako da se iskoriste ideje
opisane u drugim predlozirna. Rezultujui protokol je dobio naziv Simple Internet Protocol Plus
(SIPP).
68
IETF se 1994. godine sastao u Torontu i, na osnovu preporuka IPng Directorate, izabrao je SIPP kao
osnovu za sledeu generaciju Internet protokola, koja je formalno trebalo da bude poznata kao IPv6 (IP
verzija 6).
U poreenju sa IPv4 paketom najvea izmena je izvrena u proirenju broja bitova kojima se vri
adresiranje. Za razliku od IPv4 gde smo imali 32 bita za adresiranje sada nam je na raspolaganju 128
bita, etiri puta due od IPv4 adresa. Teorijski je omogueno 2 na 128 ili 10 na 40 razliitih adresa.
Jedan od problema sa eksponencijalnom notacijom je to to je esto teko razumeti koliko je to veliko,
nego zapisati broj. Da biste lake razumeli koliko je veliko 2 na 128 objasniemo sledeim primerom.
Pokazano je da ako bi se sve adrese rasporedile ravnomerno po povrini cele zemaljske kugle,
postojale bi 1.024 adrese na svakom kvadratnom metru, to je vie nego dovoljno za svaku osobu,
glistu i insekta na planeti.
Notacija 128-bitnih adresa se razlikuje od one koja se koristi za IPv4. Korienje tekue notacije u
kojoj se takama razdvajaju trocifreni brojevi dalo bi notaciju koja sadri 16 trocifrenih brojeva
razdvojenih takama. Naravno, ovo postaje pomalo nezgrapno. Umesto toga, take se menjaju
dvotakama i svakih 16 bitova u adresi predstavlja heksadecimalnu notaciju etvorocifrenog broja.
Primer IPv6 adrese ima sledei oblik
7477:0000:0000:0000:0000:OAFF: 1BDF:7FFF
Svaka heksadecimalna cifra u ovoj reprezentaciji ima jedinstveni 4-bitni ekvivalent. Rezultat je i dalje
nezgrapan, ali je bolji od alternative. Za adrese koje sadre mnogo nula (a sa 2 na 128 adresa bie ih
dosta) koristi se skraena notacija. U sutini, nule se ne navode, ve se na njihovo prisustvo ukazuje sa
dve dvotake (::). Stvarni broj nula koje nedostaju izraava se oduzimanjem broja heksadecimalnih
cifara u notaciji od 32, broja heksadecimalnih cifara koje su potrebne za punu 128-bitnu
reprezentaciju.
Na primer, prethodna adresa bi bila zapisana kao
7477::OAFF: 1BDF:7FFF
Poto ova notacija sadri 16 cifara, znamo da mora da nedostaje 16 nula. U sluajevima kada adresa
poinje sa 0, notacija zapoinje dvotakom. Drugim reima, adresa
0000:0000:0000:0000:OAFF: 1BDF:000F:0077
moe da se zapie i kao OAFF: 1BDF:000F:0077
Da bi se adrese dalje pojednostavile, vodee nule u okviru etvorocifrene grupe ne moraju da se
navode. Ovo omoguava uproenu notaciju na sledei nain:
::AFF: 1BDF:F:77
Kao to IPv4 deli svoje adrese na razliite klase u zavisnosti od vodeih bitova, to radi i IPv6.
Trenutno postoje 22 razliitih tipova adresa; svaki ima jedinstven bitski prefiks. Prefiksi mogu da
sadre od tri do 10 bitova. Na primer, adresa koja poinje sa osam nula odgovara IPv4 adresi.
Osnovni problem u primeni ovog protokola je u tome to ve preko milon raunara komunicira putem
IPv4. Ovako veliki broj onemoguava konvertovanje u Ipv6 preko noi. Da bi se potpuno prelo na
IPv6 bie potrebno dosta godina i za to vreme veina mrenih entiteta (pre svega ruteri), morae da
podravaju oba protokola. Za IPv6 to nije problem jer on podrava IPv4 ali je se problem javlja u
obrnutom smeru jer IPv4 kao prvonastali protokol ne podrava nove protokole.
TCP (Transsmision Control Protocol)
TCP protokol predstavlja protokol za kontrolu prenosa podataka. On koristi IP adresu ali dodaje i svoje
parametre i funkcionalnosti koje ine da TCP protokol pouzdanim protokolom orijentisanim prema
uspostavljanju veze. Sve ono to IP protokol nije zahtevao i to ga je inilo nesigurnim protokolom,
TCP protokol ispravlja i na taj nain omoguava IP-u da napravi sesiju koju aplikacije mogu da koriste
69
za pouzdanu razmenu podataka. Osnovne karakteristike ovog protokola koje ga izdvajaju kao pouzdan
protokol i koje ga svrstavaju u protokole koji se najee koriste su:
obezbeuje proveru ispravnosti prenoenih podataka,
regulie protok podataka da ne doe do zaguenja,
ubacuje brojeve za sekvence u svom zaglavlju kako bi IP datagrami mogli da se rekonstruiu u
ispravnom stanju na prijemnom mestu.
TCP prima podatke iz gornjih delova (slojeva) u steku protokola, dodaje svoje informacije zaglavlja, a
zatim ih predaje IP sloju koji sada dodaje svoje informacije zaglavlja. Poruke koje se alju TCP od
aplikacija iz viihslojeva obinose nazivaju tok (stream) podataka. Budui da koliina podataka moe
da varira i nije ograniena na neki skup brojeva bajtova, TCP preuzima ove poruke i, ako su suvie
velike da bi se uklopile u paket, usitnie ih na manje segmente i svaki od njih poslati u posebnom
paketu. TCP sloj na prijemnom kraju rekonstruie te poruke pre slanja na gore, prema aplikaciji.
Za proveru ispravnosti TCP koristi tri parametra i to:
Polje u TCP zaglavlju
TCP podataka
Pseudo informacija u zaglavlju
TCP predstavlja protokol koji je orijentisan na uspostavljanje veze tj. raunari koji komuniciraju treba
prvo da uspostave uslove koji e upravljati sesijom i uspostavljaju komunikaciju. TCP doputa
dvostruku komunikaciju odnosno to je dvosmerna ili puna dupleksna veza. Obe strane mogu
istovremeno da primaju i da alju podatke. Da bi se uspostavlia veza, svaka od strana mora da otvori
svoju stranu veze. Na strani servera to se naziva pasivno otvorena veza (passive open). Aplikacija na
serveru izvrava se kao proces na raunaru, koji slua zahteve za vezu koji stiu na odreni port.
Pomou IP adrese i broja porta, proces na serveru moe na jedinstven nain da identifikuje svakog
klijenta koji upuuje zahtev za vezu. Kada klijent eli da uspostavi vezu sa serverom, prolazi kroz
postupak poznat kao aktivno otvoren (active open). Server ve slua zahteve za vezu, ali klijent mora
da inicira stvarni proces povezivanja slanjem zahteva na broj porta aplikacije servera koju eli da
koristi.
UDP ( User Datagram Protocol )
Predstavlja jednostavan protokol koji ne zahteva dodatno angaovanje kao TCP. Ukoliko aplikaciji
nisu potrebne vrednosti koje obezbeuje TCP veza, moe da se koristi UDP. Kako UDP ne podeava
sesiju i svi UDP datagrami predstavljaju nezavisne entitete na mrei, on moe da se posmatra kao
nepouzdan protokol i protokol bez uspostavljanja veze. Jedan od servisa koji koriste ovaj protokol je
DNS (Domain Name Service). Ukoliko klijent ne primi natrag odziv na jednostavan DNS zahtev, on
moe ponovo da pokua ili da jednostavno iskoristi neki drugi DNS server ako je konfigurisan da
moe to da uradi. U poreenju sa TCP zaglavljem UDP zaglavlje je vrlo prosto i ono se sastoji od
sledeih polja:
Izvrni port predstavlja 16-bitno polje koje se koristi za identifikaciju porta koji koristi
aplikacija koja alje podatke.
Odredini port takoe je 16-bitno polje koje se koristi za identifikaciju portaq na kome se
uruuju paketi na prijemnom kraju veze.
Duina Ovo 16-bitno polje se koristi za uvanje duine itavog IP datagrama, i ukljuuje delove
i sa zaglavljem i sa podacima.
Provera ispravnosti 16-bitno polje koje se koristi da obezbedi da se sadraj UDP datagrama ne
narui pri prenosu.

70
13 as Klijent server arhitekture
Kada razmatramo prelazak na klijent server model jednog raunarskog sistema, bilo da je to
nadogradnja ve postojeeg ili uvoenje potpuno novog raunarskog sistema, vrlo je vano odluiti se
za tip arhitekture jednog takvog klijent server sistema. Glavni zadaci jedne aplikacije za krajnjeg
korisnika klijenta mogu se predstaviti kroz sledee tri komponente a to su: podaci-informacije,
obrada tih podataka i njihovo adekvatno predstavljanje. Nain na koji su ove komponente obraene,
podela na delove aplikacije koji obrauju ove komponente, kao i mesto obrade u mrenom sistemu,
tano definiu i odreuju tip klijent serverske arihitekture koja je primenjena za reavanje datog
problema. Takoe izbor odgovarajue arhitekture zavisi i od: broja korisnika i raunara na mrei,
vrsta razvojnih okruenja i programskih alata, modela i obima baze podataka kao i sloenosti
programskih procedura. Postoji vie naina kako se ta podela vri a mi emo se najvie zadrati na dve
arhitekture koje su danas najvie u upotrebi. To su dvoslojna (two-tier) i troslojna (three-tier)
arhitektura. Ve smo ranije napomenuli da se kod klasinih sistemima za obradu podataka po
klijent/server modelu, mogu uoiti tri osnovne klase komponenti i to:
1. server ima zadatak da optimalno upravljanja zajednikim resursima to su najee podaci, da
upravlja bazom podataka kojoj pristupa vie korisnika, da kontrolie pristup i bezbednost podataka
i da omogui centralizovano obezbeenje integriteta podataka za sve aplikacije
2. klijent - vri upravljanje korisnikim interfejsom i izvrava deo logike aplikacije.
3. mrea ili komunikacioni posrednik koji ima zadatak da omogui prenos podataka izmeu klijenta
i servera.

Dvoslojna arhitektura
Mada postoje vie naina na koji se ova arihitektura moe realizovati mi emo se zadrati na
najprostijoj implementacija jer ona najjasnije pokazije osobine ovakve realizacije. Za poetak razvoja
jedne ovakve arhitekture smatra se 1980 god. i ona je predstavljala prirodni nastavak dotadanje file-
server arhitekture. Osnovne prednosti koje su je izdvajale od klasine file-server aritekture bile su:
Upotrebljivost (Usability)-korienjem razliitih formi za korisniki interfejs mogue je jedne iste
podatke prikazati na vie razliitih naina.
Skalabilnost (Scalability)-za razliku od fajl-server sistema gde su istovremeno mogli da rade
desetak korisnika a da se performanse sistema drastino ne narue, ovde je omogueno da taj broj
bude oko 100 istovremenih korisnika.
Fleksibilnost (Flexibility)-mogunost da podaci budu deljivi za veliki broj korisnika koji rade na
heterogenim raaunarskim sistemima.
Osnovne komponente koja svaka dvoslojna klijent server arhitektura mora da ima su:
1. Korisniki interfejs (User System Interface) - nain predstavljanja podataka, sesije, unos teksta,
dijaloki prozori, prikaz na ekranu.
2. Upravljanje procesima (Processing Management) obrada podataka, generisanje, izvoenje i
nadgledanje procesa i neophodnih resursa
3. Upravljanje podacima (DataBase Management) - servisi vezani za uvanje i deljenje podataka i
datoteka
71

Slika broj 13.1
Kao to je prikazano na slici broj 13.1 sve tri komponente koje su bitne za jednu aplikaciju (podaci,
njihova obrada i predstavljanje) podeljene su izmeu dva softverska entiteta (tiers): klijent aplikacija i
server baze podataka. Robustan jezik za razvoj klijentske aplikacije kao i prilagodljivi mehanizam za
prenos klijentskih upita ka serveru su dve najvanije stvari kod dvoslojne klijent server arhitekture.
Predstavljanje podataka se iskljuivo vri na klijentskoj strani, njihova obrada se deli izmeu klijenta i
servera, dok se podacima pristupa i oni se uvaju na serveru. Najveu odgovornost za funkcionalnost
jedne aplikacije na sebe preuzima klijent jer se na njemu odvija najvei deo te aplikacije. Od njega i
polaze svi zahtevi za nekim podacima i kod njega se zavravaju svi podaci koji se sada prikazuju u
razliitim formama prikaza. Serverska strana je odgovorna za integritet i ispravnost tih podataka,
prihvatanje zahteva putem redova (query capabilities) i pravovremeno reavanje i slanje odgovora na
te zahteve. Jedan od najrairenijih jezika koji je danas postao gotovo standard u slanju zahteva za
nekim podacima je SQL-jezik. Slanje SQL zahteva od strane klijenta ka serveru zahteva vrstu
povezanost izmeu dva sloja koji ine dvoslojnu klijent server arhitekturu. Da bi poslao jedan SQL
zahtev klijent mora dobro da poznaje sintaksu serverske komponente ili pak da se putem
odgovarajueg API-a taj zahtev prevede da bi postao razumljiv serverskoj strani. Takoe klijent mora
da zna lokaciju servera, kako su podaci na njemu organizovani, kao i nazive tih podataka. Upueni
zahtevi mogu da iskoriste prednosti logike koja je upamena i koja se izvrava na serveru a koja
centralizuje globalne zadatke koji se izvravaju na serveru kao to su: validacija podataka, njihov
integritet kao i sigurnost tih podataka. Traeni podaci se vraaju klijentu i sada je na njemu kako e ih
on prikazati, da li e izvriti novu selekciju ili izvriti neke nove operacije na njima. Jedna od najveih
prednosti dvoslojne arhitekture je brzina razvoja nove aplikacije. Zahvaljujui velikom razvoju PC
baziranih rutina omogueno je klijentu da veoma lako razvije novu aplikaciju koja e koristiti veliki
broj ve razvijenih rutina za pozivanje podataka i njihovo predstavljanje bez obzira na nain kako su ti
podaci organizovani na serveru.
Jedna od osnovnih karakteristika klijent/server sistema je distribuirana obrada podataka koja
podrazumeva da se logika aplikacije podeli izmeu klijenta i servera, kako bi se obezbedilo optimalno
iskorienje raspoloivih resursa. Na primeru dvoslojne arhitekture, to bi znailo da se prezentacija
podataka kao i provera ulaznih podataka vru u okviru klijent-aplikacije, dok se rukovanje podacima, u
smislu njihovog fizikog smetaja i kontrole pristupa, vri na serveru. Kod dvoslojne arhitekture
klijent pokree aplikaciju koja preko mree pristupa serveru baze podataka. Zatim pokree aplikaciju
koja izvrava logiku i prikazuje traene rezultate na ekranu.
Neke od glavnih prednosti ovakvog modela obrade podataka su: centralizovano upravljanje resursima
sistema i jednostavnije obezbeivanje sigurnosti podataka, a osnovni problem predstavlja nedostatak
skalabilnosti. Pod skalabilnou se podrazumeva osobina sistema da omogui efikasan rad velikom
broju korisnika, i da dalje poveavanje broja korisnika ne izaziva drastian pad performansi sistema.
Dvoslojna arhitektura je arhitektura koja je pogodna za sisteme sa malim brojem korisnika jer se ona
dobro ponaa za manje sredine koje imaju do 100 klijenata. Svaka konekcija novog korisnika na mreu
72
zahteva izvesne sistemske resurse. Takoe treba napomenuti da kod dvoslojne arhitekture kada se
korisniku alje ogromna koliina podataka dolazi do zaguenja to utie na usporavanje protoka
informacija kroz mreu a samim tim usporava rad drugih korisnika.
Ova arhitektura se koristi za homogene sredine gde imamo tano definisana pravila koja se ne menjaju
tako esto. Ona je mnogo manje pogodna za heterogene sredine gde se pravila ponaanja izmeu njih
vrlo esto menjaju.
Troslojna arhitektura
Troslojna arhitektura kako i sam naziv kae je takva arhitektura kod koje je potrebno uvesti jo jedan
sloj tzv. srednji sloj u kome se nalazi aplikativni server. Aplikativni server komunicira sa database
serverom, podaci dobijeni sa database servera se preko aplikativnog servera prosleuju klijentu. Ovde
imamo tankog klijenta. Poslovna logika se izvrava na aplikativnom serveru. Aplikacija na
aplikatinom serveru je vienitna (multithread) i omoguava istovremeni pristup vie klijenata.
Aplikacioni server kreira konekciju sa bazom i rezultate vraa klijentu. Radi na principu Connection
Poolinga. Zahtevi klijenata se stavljaju u bazen tzv. Pool. Kada konekcija bude slobodna dodeljuje se
sledeem korisniku u zavisnosti od prioriteta korisnika koji eka u Pool-u. Pooling se moe
realizovati primenom IIS-a (Internet Information Server) i COM+ tehnologije.

Ova arhitektura namenjena je da prevazie neke probleme i ogranienja dvoslojne arhitekture time to
je potpuno odvojila podatke, njihovu obradu i prezentaciju u posebne softverske entitete-slojeve
(tiers). Isti tipovi rutina za predstavljanje podataka koje su koriene kod dvoslojne arhitekture, mogu
se koristiti i ovde ali se sada one iskljuivo koriste za predstavljanje podataka. Kada se zahteva neka
obrada tih podataka ili pristup novim podacima, upuuje se novi poziv srednjem sloju. Taj sloj sada
izvrava obradu na podacima ili generie novi zahtev, sada kao klijent, prema serveru ako se trae novi
podaci. Taj srednji sloj se obino realizuje u visoko portabilnim programskim jezicima kao to je C
jezik. Taj sloj mora da omogui pristup velikom broju klijenata pa njegova realizacija zahteva servere
koji podravaju vie-nitno (multi-threaded) procesiranje.















Kao to je na slici brj 2. prikazano troslojna arhitektura se sastoji iz tri sloja ito : korisniki sloj(User
interface), srednji sloj (Comutational function ili Middle tier server) i sloj podataka (Data access).

73












Slika broj 2.
Poetak razvoja ovakvih arhitektura datira od 1990 godine i za razvoj ovakve arhitekture mogue je
primeniti razliite tehnologije. Meutim ono to je zajedniko za ovakvu arhitekturu je pozivni
mehanizam koji je jedinstven za svaku vezu klijent server a to je RPC tj. udaljeni poziv procedure
(remote procedure call). Kako veina dvoslojne arhitekture primenjuje SQL mehanizam poziva a taj
mehanizam nije zatupljen kod troslojnih arhitektura ve je to standardni RPC poziv, potrebno je
razmotriti malo vie ove pozive. Standardni RPC poziv ima mnogo veu fleksibilnost u odnosu na
SQL poziv. To proizilazi od toga to taj poziv jednostavno moe da sadri parametre upita u okviru
kojih e specificirati strukturu podataka u kojoj eli da prihvati traene podatke. To znai da korisniki
sloj ne mora da zna SQL jezik jer on u RPC pozivu diktira u kom obliku eli da dobije povratne
informacije. Sada ukoliko doe do promene podataka u sloju podataka tada nije potrebno da se
aplikacija na nivou korisnika menja ve se to radi samo u srednjem sloju koji je zaduen za prihvatanje
podataka i njihovu isporuku korisnikom sloju. To znai da sada ni sloj podataka ne mora da uva
podatke koji su SQL orjentisani. Oni sada mogu da budu organizovani hijerahijski, relaciono i u vidu
objekata. Samim tim to dodaje veliku fleksibilnost da se omogui pristup podacima koji e biti
razliito organizovani a i omoguava prodor i uvoenje novih tehnologija za baze podataka.

Slika broj 13.2 sss
74
Pored toga podeljenost na tri zasebne celine omoguava paralelan razvoj softverskih entiteta koji sada
mogu da budu potpuno nezavisno razvijani i to na potpuno razliitim kako hrdverskim tako i
softverskim platformama. Ba zbog ove osobine ova arhitektura je primenljiva za razvoj aplikacija
koje se zasnivaju na distribuiranim bazama podataka. Tri kljune stvari koje su nam ovom
arhitekturom omoguene su zakljuavanje, koegzistentnost i replikacija. I ovde se veza dinamiki
menja u zavisnosti od korisnikih zahteva za podacima i servisima. Srednji sloj omoguuje praenje i
upravljanje procesima, njihovo aktiviranje, kontrolu rada, aktiviranjue i uspavljivanje pojedinih
procesa i obnovu procesa.
Klijent/server sistemi sa troslojnom arhitekturom (three-tier architecture) predstavljaju sisteme sa tri,
u velikoj meri nezavisna, podsistema. U pitanju su sledei podsistemi:
1. podsistem za interakciju sa korisnikom (implementira funkcije korisnikog interfejsa);
2. podsistem za implementaciju osnovnih funkcija sistema (implementira tzv. poslovnu logiku);
3. podsistem za rukovanje podacima, pri emu se pre svega misli na fiziki smetaj podataka (ovo
je, zapravo, sistem za upravljanje bazama podataka).
Za razliku od dvoslojnog modela obrade podataka, gde je logika aplikacije bila podeljena izmeu
klijenta i servera, u troslojnom modelu ona se nalazi koncentrisana u tzv. aplikacionom serveru ija
je namena da izvrava programski kod koji implementira logiku aplikacije. Klijent aplikacija je
namenjena samo za implementaciju korisnikog interfejsa, a funkcija sistema za upravljanje bazom
podataka je iskljuivo fiziko rukovanje podacima (u prethodnom sluaju je, pored toga, izvravao i
deo logike aplikacije).
Troslojni koncept je doveo do podele programskog koda na segmente koji implementiraju tano
odreene funkcije sistema. Tako organizovan sistem je jednostavniji za odravanje, jer je mogue
nezavisno razvijati korisniki interfejs i logiku aplikacije. Za potrebe fizikog rukovanja podacima
najee se koristi neki od komercijalno dostupnih servera za tu namenu. Troslojne arhitekture
sistema podrazumevaju oslanjanje na standarde u odgovarajuom oblastima, zasnovane na Internet
tehnologijama. Oslanjanje na standarde omoguava integraciju sistema heterogenih u pogledu
koriene hardverske i softverske opreme.
Prednosti troslojne arhitekture
1. Vana karakteristika troslojnih sistema je skalabilnost.
a) poveavanje broja klijenata je jednostavno
b) poveavanje propusne moi i brzine odziva servera srednjeg sloja je mogue kroz dodavanje novih
serverskih maina uz korienje postojeih
2. Sistem sa vie servera karakterie i poveana pouzdanost i fleksibilnost
3. Logika aplikacije se moe menjati i u toku rada sistema
4. Mogue je efikasno vriti balansiranje optereenja serverskog podsistemapodsistema za
Ova arhitektura se koristi u heterogenim sredinama koje zahtevaju povezivanje heterogenih baza
podataka. Primenjije se za povezivanje velikog broja klijenata gde je potrebno povezati vie od 1000
klijenata.

Arhitektura vieslojnih sistema
Daljim proirivanjem koncepta troslojnih sistema dolazi se do pojma vieslojnih sistema (multitier
architecture), gde se vri dalja podela na komponente u okviru srednjeg sloja sa ciljem jo veeg
poveanja skalabilnosti, odnosno performansi. Srednji sloj je podeljen na dva sloja: jedan je namenjen
za opsluivanje Web klijenata, a drugi sadri komponente koje implementiraju poslovnu logiku
sistema. Nekada se srednji sloj deli na dva ili vie sloja u zavisnosti od aplikacije. Ovakva arhitektura
poznata je kao vieslojna (multi tier) arhitektura. To je sluaj kod nekih Internet aplikacija. One obino
imaju tankog klijenta pisanog u HTML jeziku a aplikacioni serveri su pisani u C++ ili JAVA jeziku.
Postoji veliki jaz izmeu ove dve tehnologije koji predstavlja neprolaznu prepreku da bi se ovakve dve
aplikacije meusobno direktno spojile. Zaro postoji meusloj (intermediate layer), obino WEB server
, koji je implementiran u nekom script jeziku. Taj sloj prihvata zahteve od klijenata i generie HTML
dokument koristei servise koje pozajmljuje od poslovnog (business) sloja.
Java tehnologije za izgradnju vieslojnih sistema
75
Interakciju sa korisnikom u ovakvom sistemu obavljaju klijenti koji imaju standardan Web interfejs. U
pitanju su Web itai koji prikazuju HTML stranice. Komunikacija izmeu Web itaa i Web servera
se odvija putem standardnog HTTP protokola, uz dodatak cookie podataka kojima se prati korisnika
sesija dok se on kree po Web sajtu. Stranice koje prikazuju klijenti su najee generisane dinamiki,
tj. po prijemu zahteva za nekom stranicom. Dinamiko generisanje Web sadraja na osnovu podataka
iz ostatka sistema vre servleti ili se za tu namenu koriste JSP (Java Server Pages) stranice. Za
potrebe manipulacije podacima u sistemu servleti ili JSP stranice pristupaju objektima u okviru
aplikacionih servera koji su dostupni kao CORBA (Common Object Request Broker Architecture) ili
EJB (Enterprise JavaBeans) komponente. Protokol za komunikaciju izmeu ova dva sloja je JRMP
(Java Remote Method Protocol), protokol za komunikaciju izmeu distribuiranih Java objekata, ili
IIOP (Internet Inter-ORB Protocol) ekvivalentan protokol vezan za CORBA tehnologiju.
CORBA/EJB komponente za potrebe skladitenja podataka u bazi podataka pristupaju serveru za
upravljanje bazama podataka preko standardnog JDBC (Java Database Connectivity) interfejsa.




korisnikom i po


76
14. as Distribuirani sistemi
Distribuirani sistemi (DS) predstavljaju jedan vid mrenih sistema koji omoguuju raunarima
izvoenje obrade podataka korienjem svih raspoloivih mrenih resursa u toj mrei. Za razliku od
mrenih sistema koji omoguuju kontrolisani pristup drugim raunarima i prenos podataka izmeu
raunara, DS omoguuju istovremeno izvoenje obrade na vie raunara. Upotrebom DS-a klijent
moe pristupati svim mrenim resursima kao resursima lokalnog raunara. Drugim reima, DS
predstavlja skup nezavisnih raunara koji su klijentu predstavljeni kao jedan koherentan sistem.

Slika 1. Organizacija distribuiranog sistema
Na slici br.1. prikazano je mesto jednog distribuiranog sistema u mrenoj strukturi raunara kao
meusloj (middleware). Navedimo sada koje su prednosti koje nam jedan DS-a prua u odnosu na
klasian mreni sistem:
1. Ubrzanje obrade podataka obrada se izvodi na vie raunara istovremeno pa je ukupno vreme
obrade krae u odnosu na obradu na jednom raunaru.
2. Vea pouzdanost u sluaju nekorektne obrade izvodi se ponavljanje obrade na raunaru na kome
je greka nastala, dok se obrade izvedene na ostalim raunarima ne ponavljaju; u sluaju izvoenja
svih obrade na jednom raunaru nuno je ponavljanje svih obrada.
3. Ravnomerno optereenje raunarske mree ako je neki od raunara u mrei jako optereen nekom
obradom, mogue je izvriti njegovo rastereenje prenosom obrade na manje optereene raunare.
4. Smanjeni zahtjevi za hardverom dovoljno je imati nekoliko raunara sa nadproseno kvalitetnim
hardverskim osobinama, a zatim se sve hardverski zahtevnije obrade preusmeravaju na te raunare.
5. Smanjene zahteva za softverom skupi softverski proizvodi instaliraju se na nekoliko raunara, a
zatim se sve potrebne obrade preusmeravaju na jedan od tih raunara; na taj nain se smanjuje
potreban broj licenci i cena upotrebe softverskih paketa.
Ciljevi razvoja DS-a:
1. Povezivanje korisnika i resursa - Povezivanje korisnika i resursa omoguuje korisniku pristup
resursima svih raunara u mrei i njihova upotreba kao lokalnih resursa raunara na koje je korisnik
spojen. DS-i koji se mogu korisniku i aplikacijama prikazati u formi jednog sistema su transparentni.
2. Transparentnost - Transparentnost u distribuiranim sistemima moe se prikazati u sledeim
oblicima:
1. Transparentnost pristupa (access) prikrivanje razlike u prikazu podataka (razliite hardverske
osnove raunara koriste razliite formate u prikazu podataka) i naina korienja resursa.
2. Transparentnost lokacije (location) - korisnik nije upoznat sa fizikom lokacijom resursa koji
sadri podatke koje korisnik upotrebljava.
3. Transparentnost promene mesta (migration) promena fizike lokacije resursa ne utie na nain
pristupa resursima.
4. Transparentnost relokacije (realocation) omoguava promenu lokacije resursa u trenutku kada
se resurs koristi.
5. Transparentnost replikacije (replication) mogunost postojanja vie kopija originalnih podataka
a da korisnik ne mora biti upoznat sa time.
77
6. Transparentnost konkurentnosti (concurrency) mogunost korienja skupa podataka za vie
korisnika istovremeno pri emu to korisnici ne vide i ne znaju za to.
7. Transparentnost pogreke (failure) korisnici ne opaaju nefunkcionalnost odreenog resursa kao
ni postupak oporavka sistema u sluaju kvara.
8. Transparentnost postojanosti (persistance) korisnik nije upoznat sa trenutnom lokacijom
podataka koji koristi (npr. podaci na kojima se izvodi manipulacija u bazi podataka kopiraju se u
glavnu memoriju, obrauju i rezultat se smeta u bazu podataka dok korisnik taj postupak vidi kao
direktnu operaciju u bazi podataka).
3. Otvorenost - Otvoreni DS omoguuje izvoenje usluga prema prihvaenim standardima. Standardi
za DS-e sadrani su u interfejsu (interface) koji se opisuje sa jezikom za definisanje interfejsa
(Interface Definition Languge IDL). IDL sadri imena funkcija sa popisom parametara, rezultata
izvoenja, moguih razlika itd. Popis svih funkcija ini specifikaciju. Osobine dobre specifikacije su
kompletnost i neutralnost. Kompletnost znai da je sve to je nuno potrebno za implementaciju ve
je ukljueno u specifikaciju. Neutralnost znai da specifikacija ne propisuje nain implementacije
funkcija.
4. Merljivost (scalability) Skalabilnost ili merljivost je osobina koje se primenjuje na tri naina:
1. Prema veliini mogunost dodavanja novih korisnika i resursa.
2. Prema lokaciji odvojenost korisnika i resursa podataka.
3. Prema administriranju mera jednostavnosti upravljanja sistemom iako se sistem sastoji od
mnogo neovisnih administrativnih organizacija.
Ukoliko elimo poveati kvalitet sistema nailazimo na niz ogranienja. Pri porastu broja korisnika
ogranienja se mogu prikazati tabelom 1.

Koncept Primer
Centralizirani server
Centralizirani podaci
Centralizirani algoritmi
Jedan server za sve korisnike
Jedan on-line telefonski imenik
Izvoenje usmeravanja zasnovanog na
kompletnim informacijama
Tabela 1. Ogranienja poveanju broja korisnika

Primena centraliziranog servera za sve korisnike uslovljava veliki stepen optereenja servera, ali u
nekim situacijama nije opravdana upotreba vie servera iste namene (jedan od razloga je sigurnost).
Pristup centraliziranim podacima je problematian ako je u pitanju velika koliina podataka jer
dolazi do velikog optereenja servera na kome su podaci smeteni. Ukoliko se koristi vie raunara
mora se osigurati jednakost podataka na svim serverima. Primena centraliziranih algoritama nije
dobro rjeenje jer se komunikacija izvodi slanjem i primanjem velikog broja poruka pa je poeljno
koristiti razliite mrene linije u cilju ubrzanja izvoenja algoritma. Za to je potrebno imati
informacije o raspoloivim putanjama i odabrati najpovoljniju putanju za prenos poruka.
Tehnike za realizaciju scalability-a su:
1. Asinhrona komunikacija nakon slanja poruke aplikacija pokree druge aktivnosti, odnosno ne
eka na prijem odgovora od servera, a kada odgovor stigne on se prekidom dojavljuje aplikaciji te
poseban proces (handler) izvodi obradu pristiglog odgovora. U nekim sluajevima je bolje veinu
obrade izvesti na klijent strani kako bi se rasteretio server (slika 2. prikazuje moguu primenu
obrade podataka formu za unos podataka na klijent strani (b))
2. Distribucija - znai slanje odreene komponente podeljene na manje dijelove i njihova distribucija
putem mree kako bi se na odreditu svi dijelovi ponovo spojili u celinu. Primer je rad DNS
servera (slika 3.) gdje se primenom zona izvodi usluga dodele imena (naming service) primjenom
vie decentraliziranih servera.
3. Caching to je specijalna forma kopije (replike) podataka, a njena upotreba definisana je
potrebama klijenta i servera koji ima originalnu verziju podataka.
78

Slika 2. Primer obrade na klijent strani


Slika 3. Primena zona za rad DNS servera.

1.1. Hardware
Distribuirani sistemi mogu se koristiti za razliite vrste raunara spojenih u raunarsku mreu.
Razliitosti raunara uslovljavaju nivo sloenosti DS-a. Razlikujemo:
1. Multiprocesorske raunarske sisteme
2. Multiraunarske raunarske sisteme.
Multiprocesorski sistemi imaju jedan memorijski adresni prostor koji koristi vie procesora, dok kod
multiraunarskih sistema svaki procesor koristi svoj zasebni adresni prostor (slika 4.). Arhitektura
sistema moe se zasnivati na magistrali (bus) ili na prekidaima (switch). Multiraunarski sistemi
mogu biti homogeni i heterogeni. Homogeni sistemi imaju skup raunara istih karakteristika jer koriste
iste procesore (struktura procesora je identina) i imaju jednu mrenu tehnologiju. Heterogeni sistemi
sastoje se od velikog broja razliitih raunara koji su spojeni na razliite mree.
79
Multiprocesori
Svi procesori koriste jedan adresni prostor. Ukoliko se promena vrednosti memorijske lokacije od
jednog procesora moe u 1 s prikazati na drugom procesoru kaemo da imamo koherentan sistem.
Primena ovog sistema dovodi do optereenja magistrale i smanjenja performansi sistema. Zato se
koristi cache memorija. Svaki proces ima malu brzu cache memoriju za smetanje vrednosti koje
trenutno obrauje (slika 5.). Cache memorijom se rastereuje magistrala, ali se pojavljuje problem
auriranja vrednosti cache memorije ukoliko dva procesora obrauju vrednost na istoj memorijskoj
lokaciji.


Slika 4. Razlika multiprocesorskih i multiraunarskih sistema

Slika 5. Primjena cache memorije
Primena velikog broja procesora uslovljava e podelu memorije u module kako bi se poboljale
osobine sistema. Pri radu sa memorijom svaki procesor moe pristupati memorijskim modulima
korienjem prekidaa. Prekidai mogu biti crossbar i omega. Crossbar prekidai omoguuju direktno
spajanje svakog procesora sa svakim memorijskim modulom, pruaju veliku brzinu spajanja ali
uslovljavaju velik broj prekidaa. Manji broj prekidaa postie se upotrebom omega prekidaa gde se
njihovom upotrebom bira putanja pristupa memorijskim modulima (slika 6.).
Homogeni multiraunarski sistemi
Kako kod ovih sistema svi raunari imaju istu strukturu njihova upotreba u DS-u je znatno
jednostavnija. Ostaje jedino problem naina povezivanja i komunikacije raunara. Pri povezivanju
raunara mogua je upotreba strukture reetke (grid) ili hiperkocke (hypercube). Na slici broj 7
prikazana je ema povezivanja raunara kod ovih struktura.
80


Slika 6. Upotreba crossbar i omega prekidaa

Slika 7. Struktura a) reetke b) hiperkocke

Hetrogeni raunarski sistemi
Sastoje se od veeg broja razliitih raunara spojenih na mreu putem razliitih mrenih struktura.
Primjenom DS-a generie se sloj (middleware) koji je nezavisan od hardvera raunara koji su spojeni
na mreu i komunikacija se izvodi primenom tog sloja. Na taj nain se izbjegavaju problemi koji
nastaju zbog razliitosti raunara.

1.2. SOFTVER
Pri analizi softvera razlikujemo mrene raunare koji koriste operativni sistem koji ima kontrolu nad
svim resursima mree (tightly-coupled system) i operativni sistem koji kontrolie resurse lokalnog
raunara (loosely-coupled system). Za prvu grupu sistema koristi se distribuirani operativni sistem, a za
drugu mreni operativni sistemi. Tabela 2 prikazuje razlike izmenu ovih operativnih sistema.

Sistem Opis Ciljevi

DOS Tightly-couped sistemi; primena
za vieprocesorske i homogene
sisteme
prikrivaju nain
upotrebe resursa

NOS Loosely-couped sistemi;
primena za heterogene sisteme
pruaju lokalne usluge
za udaljene klijente
Middleware dodatni sloj na NOS za
implementaciju usluga opte
namene
osigurava
transparentnost

Tabela 2. Razlika izmenu OS-a

81
DISTRIBUIRANI SISTEMI DS
Razlikujemo multiprocesorske DS i multiraunarske DS. Analiza primjene mikrokernela u dizajnu OS
jednog rauna zasnovanog na klijent-server strukturi (slika 8.) omoguiti e bolju razumljivost rada
DS-a.

Slika 8. Primjena mikrokernela
Multiprocesorski DS omoguuju poveanje performansi sistema upotrebom vie CPU-a. Aplikacije
koje pokreemo ne uoavaju upotrebu vie CPU pri njihovom izvoenju. Komunikacija u
vieprocesorskom sistemu ostvaruje se manipulacijom podataka izmeu deljenih memorijskih lokacija
za vie procesora, a jedini uslov koji mora biti zadovoljen je onemoguavanje istovremenog pristupa
jednoj memorijskoj lokaciji dva ili vie CPU istovremeno. To je omogueno primenom semafora,
monitora i uslovnih promenljivih.
Multiraunarski DS omoguuju rad potpuno razliitih raunarskih sistema, pa je i njihova
kompleksnost znatno vea u odnosu na multiprocesorske DS-e. DS za multiraunarske sisteme se
zasniva na slanju poruka (slika 9.).

Slika 9. Opta struktura multiraunarskih operativnih sistema
Za prijenos poruka bitna je usklaenost poiljaoca i primaoca pri slanju poruka, a pri tome je korisna
upotreba buffera.
Distribuirani sistemi sa dijeljenom memorijom zasnivaju svoj rad na dijeljenju globalnog
memorijskog prostora raunarske mree. Adresni prostor je podeljen na stranice (veliine 4 KB ili 8
KB). Princip je da svaki raunar koristi stranice u svojoj memoriji, a kada je potrebno izvoditi stranicu
koja nije u lokalnoj memoriji generie se zahtjev za uitavanjem traene stranice. Princip je slian
klasinom stranienju ali se za virtualnu memoriju ne koristi sekundarna memorija (obino hard disk),
nego RAM memorija drugih raunara u mrei. Slika 10. prikazuje princip rada deljene memorije. Pri
radu sa dijeljenjem memorije javljaju se problemi uzrokovani obradom podataka unutar jedne stranice
koja se izvodi na razliitim procesorima. U tom sluaju promena promenljive u jednoj stranici nije
vidljiva u drugoj stranici i moe doi do greke (false sharing) to prikazuje slika 11.
82



Slika 10. Deljenje memorije a) poetno stanje b) CPU 1 referencira stranicu 10 c) stanje nakon
upotrebe replike stranice 10

Slika 11. Primer greke pri obradi promenljivih u stranici koja se izvodi na dva procesora.
Istovremene promene nezavisnih promenljivih rezultirali bi gubitkom promena za jedan od procesa.

Mreni operativni sistemi se prilagoavaju operativnom sistemu svakog raunara i ne stvaraju sliku
jedinstvenog sistema kao kod DS-a. Mreni operativni sistemi svaki raunar vide posebno i pruaju
mrene servise operativnom sistemu na svakom mrenom raunaru. Slika 12 prikazuje ulogu mrenih
operativnih sistema u radu distribuiranih aplikacija.
83

Slika 12. Opta struktura mrenih operativnih sistema
Komunikacija u mrenim operativnim sistemima usmerena je na prenos poruka izmeu klijent
raunara i raunara namenjenih pruanju usluga drugim raunarima (npr. Data server). Slika 13.
prikazuje komunikaciju klijent i server raunara u mrenim operativnim sistemima.

Slika 12. Komunikacija klijent-server
Middleware je dodatni sloj softvera koji se pozicionira izmeu distribuiranih aplikacija i mrenih
operativnih sistema. Middleware je namenjen usklaivanju razliitosti izmeu mrenih operativnih
sistema. Slika 13. prikazuje optu strukturu middleware sistema. Middleware se primenjuje u
distribuiranom datotenom sistemu, zatim pri izvedbi poziva na udaljenom raunaru (Remote
Procedure Call RPC) ili za rad distribuiranih objekata. Usluge middleware-a su:
1. Komunikacijske usluge maskiranje prenosa podataka niskog nivoa.
2. Imenovanje omoguavanje pristupa i deljenje resursa.
3. Postojanost podataka.
4. Distribuirane transakcije izvoenje vie zasebnih operacije koje se moraju kompletno izvesti da bi
se zavrila distribuirana transakcija.
5. Sigurnost.

Slika 13. Opta struktura midleware-a
84
Tabela 3. prikazuje uporedni prikaz multiprocesorski, multiraunarskih, mrenih i middleware
zasnovanih distribuiranih sistema prema stepenu transparentnosti, razliitosti OS za raunare u mrei,
broju kopija OS, komunikacijskoj osnovi, upravljanju resursima, proirivosti i otvorenosti..


Tabela 3. Uporedni prikaz distribuiranih sistema

2. KOMUNIKACIJA
Komunikacije su kljuni element DS-a. Osnovna razlika distribuiranih sistema i lokalnog sistema je
komunikacija meu procesima. Zasniva se na primjeni poruka niskog nivoa (bliskom hardveru raunara)
korienjem postojee mrene strukture. Komunikacija dva raunara izvodi se primenom strukture slojeva.
Svaki sloj izvodi set aktivnosti i ini osnovu za primenu vieg sloja. Nii slojevi usmereni su prema
hardveru, a vii prema aplikacijama. Primenjujemo sledee modele komuniciranja:
1. Poziv procedure na udaljenom raunaru (Remote Procedure Call RPC)
2. Poziv metode na udaljenom raunaru (Remote Method Invocation RMI)
3. Meusloj usmeren prenosu poruka (Message-Oriented Middleware MOM)
4. Primena toka (Stream).
2.1. Protokoli slojeva za komunikaciju
Najvaniju, kljunu ulogu u komunikaciji igraju protokoli. Prema modelu realizacije njih moemo podeliti
na protokole zasnovane na slojevima (layers) (OSI model i ATM) i klijent-server model protokola.

Slika 19. Slojevi OSI-modela

85
OSI model
Pri komunikaciji dva raunara koristi se vie slojeva za prenos podataka.Slojevi se mogu razliito definisati
u skladu sa njihovim funkcionalnostima. Opte prihvaeni predlog strukture slojeva predloen je od
International Standard Organization (ISO) pa je i predloeni model strukture slojeva nazvan OSI model.
OSI model omoguuje komunikaciju otvorenih sistema (sastavi koji koriste propisane standarde pravila,
formate, sadraj i znaenje poruka koje se alju i primaju). Pravila za otvorene sisteme su formalizirana u
protokolima. Protokoli mogu biti connection-oriented (potrebna je uspostava veze pre slanja i primanja
podataka) i connectionless (veza ne mora biti uspostavljena da bi se poruke mogle slati i primati upotreba
mailbox-a). Slika 19. prikazuje slojeve u OSI modelu. Koristi se 7 slojeva. Kada proces jednog raunara
alje poruku drugom raunaru, sloj aplikacije generie poruku i prosleuje sloju prezentacije, koji poruku
prosleuje niem nivou. Pri tom svaki sloj dodaje header na poetak poruke. Izgled poruke pre prenosa
mreom prikazuje slika 20. Primljena poruka se pomou headera poruka moe preneti do procesa kojem je
namijenjena.

Slika 20. Primjer poruke sa header-ima
Protokole potrebne za rad OSI modela delimo na:
1. protokole niskog nivoa (low-level)
a. fiziki sloj (physical layer) sloj za prijenos 0 i 1 putem fizike veze
b. Sloj prenosa podataka (data link layer) grupiranje bitova u vee celine ili pakete frame i provera
ispravnosti prenosa frame-ova primenom postupka za proveru (checksum); slika 21 prikazuje proveru
podataka.
c. Mreni sloj (network layer) izbor putanje za slanje paketa mreom; najee koriteni protokol je IP
(Internet Protokol); pri brim vezama (ATM) koriste se virtualni kanali koji povezuju vie
komunikacijskih vorova u jednu celinu
2. Transportne protokole funkcija protokola je deljenje poruke za prenos na manje delove, dodela brojeva
delovima i njihovo slanje; najee koriten protokol je TCP (Transmission Control Protokol), zatim
UDP (Universal Datagram Protokol, to je proirenje IP protokola), za real-time prijenos se koristi RTP
(Real-time Transport Protocol). Primena transportnih protokola esta je u klijent-server interakciji u
distribuiranim sistemima primenom TCP i UDP protokola, pri tome komunikacija moe biti standardna
(normal) ili transakcijska (slika 22.)
3. protokole visokog nivoa (high-level)
a. protokol sesije nadogradnja transportnog sloja sa funkcijama izvoenja dijaloga sa niim slojem i
sinhronizacije uz mogunost definisanja kontrolnih taaka za nastavak komunikacije u sluaju
neuspelog prenosa poruke
b. prezentacijski protokol orijentisan je sadraju poruka pa omoguuje povezivanje podataka poruke sa
formatom prenosa poruke (poruke mogu sadrati imena, adrese, novane iznose i sl. pa je prikladno
odrediti strukturu poruke kako bi se jednostavnije manipulisalo porukama).
c. Aplikacijski protokoli orijentisani su na radu sa aplikacijama sa karakteristikama protokola opte
namene. Primeri su FTP (File Transport Protocol), HTTP (HyperText Transfer Protocol).
d. Middleware protokoli protokoli sadrani u sloju aplikacije za izvoenje posebnih usluga (protokoli
za provjeru autentinosti, protokoli za implementaciju atominosti izvoenje vie procesa kao jedna
nedjeljiva celina)
86


Slika 21. Postupak provere prenosa poruka


Slika 22. a) standardni TSP b) Transakcijski TCP
2.2. Poziv procedure na udaljenom raunaru RPC
Poziv procedure na udaljenom raunaru omoguuje prenos obrade na drugi raunar pokretanjem
odgovarajue procedure. Za vreme izvoenja procedure na drugom raunaru proces koji je inicirao poziv je
suspendovan i eka rezultat izvoenja procedure (slika 23). Kada pozvana procedura vrati rezultat rada
procedure proces na lokalnom raunaru nastavlja izvoenje, pri emu je celi postupak nevidljiv za
programera.
87

Slika 23. Prikaz RPC poziva izmenu klijenta i servera
Primenom RPC poziva omoguavamo da se pozvana procedura na udaljenom raunaru izvede na nain kao
da lokalni proces izvodi proceduru na lokalnom raunaru. To se ostvaruje upotrebom posebnog tipa zapisa
procedura (client stub) u stack deo memorije procesa. Kada udaljeni raunar primi poruku sa pozivom
procedure prosljeuje je posebnom zapisu (server stub) u stack memoriji. Kada se procedura izvede sledi
prenos rezultata klijentu i nastavak izvoenja procesa na klijent raunaru. Koraci za izvoenje RPC poziva
su (slika 24.):
1. klijent proces poziva proceduru i generie klijent stub,
2. klijent stub generie poruku i prosleuje je lokalnom OS,
3. klijent OS alje poruku udaljenom raunaru (serveru),
4. server OS prima poruku i prosljeuje je server stubu,
5. server stub raspakuje primljenu poruku, analizira parametre poruke i genee sistemski poziv na serveru,
6. server izvodi poziv i vraa rezultat server stubu,
7. server stub pakuje poruku i prosleuje je server OS,
8. server OS alje poruku klijent raunaru,
9. klijent OS poruku prosleuje klijent stubu,
10. klijent stub raspakuje poruku i prosleuje rezultat klijent procesu.


Slika 24. Izvonenje RPC poziva
Pri tome je nuno uskladiti formate za prenos podataka ukoliko klijent i server koriste drugaiji zapis
podataka (npr. Pentium i SPARC arhitektura). Slika 25. prikazuje postupak prevoenja poruka u drugaiji
format (korienje drugaijih kodova za karaktere, formate brojeva itd.). Pri generisanju poruke prema
serveru nuno je poznavanje servisa koji se eli koristiti (razliiti servisi imaju razliite portove). Klijent
moe dobiti potreban port statikim nainom, kada server svim klijent raunarima poalje oznake portova
(to je nepraktino u sluaju promene oznaka portova jer se podaci o promeni portova moraju slati svim
88
raunarima). Drugi nain je dinamiki: klijent alje serveru upit za oznakom porta za traenu uslugu, a
zatim dobivenu informaciju ugrauje u poruku prema serveru.

Slika 25. Prevoenje formata podataka a) Intel b) SPARC c) invertirana poruka
Proirenje RPC modela
Ukoliko je potrebno koristiti poziv RPC poziva na jednom raunaru koristi se posebna vrsta procedure
ekvivalentna RPC pozivu a zove se door. Door procedura mora biti podrana u OS raunara. Postupak
izvoenja je identian RPC pozivu osim komunikacije putem mree jer se poziv izvodi na istom raunaru.
Slika 26. prikazuje izvedbu door procedure. Asinhroni RPC poziv omoguuje klijent procesu nastavak
izvoenja aktivnosti koje se ne odnose na rezultat RPC poziva, pa klijent ne mora biti suspendovan za
vrijeme izvoenja RPC poziva (slika 27.). Slika 28. prikazuje izvoenje dva RPC poziva (deffered
synhronous RPC)


Slika 26. Izvoenje door procedure
89

Slika 27. a) standardni RPC b) asinhroni RPC

Slika 28. Klijent i server izvode dva asinhrona RPC poziva
2.3. Poziv metode na udaljenom raunaru RMI
Rad se zasniva na primeni distribuiranih objekata koji su opisani podacima koje sadre(state) i operacijama
na podacima (method). Metode su DS dostupne primenom veze interfejsa (interface). Distribuirani sistemi
dozvoljavaju smjetaj interface-a na jedan raunar i objekta na drugi raunar (slika 29.).


Slika 29. Primjer organizacije objekta na udaljenom raunaru
90
Klijent poziva udaljeni objekat putem interface-a (proxy), koji zahtev prosleuje na server gde se
primjenom interface-a (skeleton) prosleuje objektu. Nakon to klijent pristupi objektu on pokree
izvoenje metode na objektu. Korieni interface-i mogu biti definisani u trenutku izrade aplikacije na
klijentu pa se takav nain upotrebe interface-a zove static invocation. Ukoliko interface nije unapred
poznat koristi se dinamic invocation. U tom sluaju aplikacija odabire eljenu metodu te se dinamiki
odreuje potreban interface za selektovanu metodu.
2.4. Meusloj usmeren prenosu poruka
Porukama se izbegava ogranienje blokiranja klijent procesa pri RPC ili RMI pozivu na serveru. Primer
primene poruka je slanje elektronske pote (slika 30.). Aplikacija generie poruku koja se prosleuje putem
lokalne mree prema komunikaciskom serveru (mail serveru). Komunikaciski server prosleuje poruku
drugom komunikaciskom serveru koji prihvata poruku i prosleuje aplikaciji korisnika u trenutku kada se
korisnik prikljui na komunikaciski server.


Slika 30. Princip rada elektronske pote primenom prenosa poruka.
Elektronska pota je primer kontinuirane komunikacije (persistant communication) gde se poruka smeta
na serveru sve dok se ne steknu uslovi za njen dalji prenos na drugi server. Slika 31 prikazuje persistant
communication na primeru Pony Express slube.

Slika 31. Primjer kontinuirane komunikacije
91
Nasuprot persistant communication je transient communication gde se poruka zadrava samo za vreme
izvoenja aplikacije za slanje i primanje poruka. Komunikacija porukama moe biti sinhrona i asinhrona.
Kod asinhrone komunikacije poiljalac nastavlja izvoenje nakon slanja poruke, a kod sinhrone poiljalac
je blokiran sve dok poruka nije smetena u bufffer primaoca ili je primalac nije primio. Slika 32. prikazuje
6 naina komunikacije.



Slika 32. Naini komunikacije: a) kontinuirana asinhrona b) kontinuirna sinhrona
c) transient asinhrona d) receipt-based transient sinhrona e) delivery-based transient
sinhrona f) response-based transient sinhrona

2.5. Primena toka (stream)
Tok (stream) se koristi u radu sa multimedijalnim dokumentima gde je vrlo vana usklaenost izmeu
sadraja i naina interpretacije sadraja. Razlikujemo kontinuirane i diskretne medije. Za prikaz
kontinuiranih medija vana je brzina prenosa podataka dok za diskretne medije brzina nema kljunu
vanost. Za implementaciju kontinuiranih medija u distribuiranim sistemima koristi se tok podataka (data
stream). Za asinhroni transmisijski nain prenoenja podaci se prenose jedan za drugim i koriste kada je
prijenos zavren (prijenos fotografija). Za sinhroni transmisijski nain prenoenja podaci se prenose jedan
za drugim i moraju se preneti pre odreenog intervala vremena. Za izohrone transmisijske naine
prenoenja podaci se prenose jedan za drugim ali imaju tano odreen vremenski interval prenosa te se ne
smeju podaci preneti posle, ali ni pre dozvoljenog intervala vremena. Tok moe biti:
1. jednostavan jedan niz podataka
2. sloen nekoliko nizova podataka (kombinacija slike i zvuka).
92
Tok moe biti izveden korienjem dva procesa, a moe biti realiziran i direktno (slika 33.).


Slika 33. Primjena toka a) pomou dva procesa b) direktno
Kvalitet toka definie se specifikacijama za prenos podataka sa podacima o brzini prenosa, problemima pri
prenosu itd. Primer poboljanja kvaliteta toka je Token bucket algoritam (slika 34.). Aplikacija generie
podatke za tok u nepravilnim vremenskim intervalima, a filter korienjem brojaa vremena T alje
podatke u tanim vremenskim intervalima.

Slika 34. Primena token bucket algoritma
Postavljanje toka podataka izvodi se primenom Reosurse reSerVation Protocol-a (RSVP) kao kontrolnog
protokola smetenog u transportni sloj. RSVP sadri sve podatke potrebne za realizaciju toka podataka i
preuzima kontrolu nad tokom podataka (slika 35.).


Slika 35. Primjena RSVP-a u kontroli toka podataka
93
Za tok podataka bitna je sinhronizacija, pa je nuno koristiti sinhronizacijski mehanizam. Zadatak
mehanizma je da prihvati dolazni tok podataka i da vremenski izvri usklaivanje toka podataka koji se
prosleuje prema konkretnom primaocu. Kontrolni mehanizam moe biti:
1. jednostavankontrola prihvata podatke i vri sihronizaciju pri prosleivanju podataka primacu (slika 36.)
2. sloena koristi se poseban program (aplikacija) koja je namenjena kontroli toka podataka (slika 37).

Slika 36. Primer jednostavnog mehanizma za sinhronizaciju

Slika 37. Primer sloenog mehanizma za sinhronizaciju


3. SINHRONIZACIJA U DISTRIBUIRANIM OPERACIONIM SISTEMIMA

Sinhronizacija je kljuna za rad DS-a. Raunarska mrea ukljuuje niz raunara sa vremenski usklaenim
satovima. Uskladivost vremena na svim raunarima ne moe se potpuno postii to stvara probleme pri
izvoenju operacija (procesa) na razliitim raunarima koji se moraju izvesti tano odreenim redosledom.
Primjer na slici 46. prezentira situaciju pri kompajliranju datoteke. Na jednom raunaru editujemo
datoteku, a na drugom je kompajliramo. Kompajler pre kompajliranja proverava vreme zadnje promene
datoteke i ako je to vreme manje od zadnjeg procesa kompajliranja ne izvodi postupak kompajliranja.
Zadnje vrijeme kompajliranja je 2144 na prvom raunaru. Posle tog trenutka na drugom raunaru se
promeni datoteka i zapamti vrijeme 2143 (sat na drugom raunaru zaostaje za satom na prvom raunaru).
Kompajler pri uporeivanju utvruje da je promena datoteke izvedena pre zadnjeg kompajliranja (2134
promena, 2144 zadnje kompajliranje) i nee kompajlirati datoteku. Jasno je da se ovakve situacije moraju
izbjei.
94

Slika 46. Greka pri kompajliranju datoteke
3.1. Sinhronizacija sata
Sinhronizacija sata moe se postii:
1. primjenom fizikog sata koristi se univerzalni sat prema kojem se usklauju svi ostali satovi
2. algoritma za sinhronizaciju za raunare koja imaju pristup WWW-u mogue je usklaivanje sa
referentnim satom stalnim praenjem odstupanja lokalnog sata; kada odstupanje pree dozvoljenu
granicu izvodi se korekcija lokalnog sata (slika 47.); druga mogunost je upotreba time servera za
usklaivanje lokalnih satova (slika 48.); ukoliko raunari nemaju pristup WWW-u potrebno je primeniti
Berkeley algoritam gde se izraunava srednje vreme svih raunara u lokalnoj mrei i putem time deamon
procesa usklauju svi lokalni satovi sa srednjim izraunatim vremenom (slika 49.)

Slika 47. Usklanivanje sa referentnim satom Slika 48. Usklanivanje time serverom

Slika 49. Berkeley algoritam
95
Za pojedine procese vrlo je bitno odreivanje sleda aktivnosti izvoenje to je izvodivo ukoliko su satovi
meusobno usklaeni. Za procese kod kojih je nuno da se jedan proces dogodio pre drugog definie se
relacija happend before. Dva procesa su u relaciji happend before ako je:
1. a se dogodio pre b: C(a) < C(b)
2. a i b oznaavaju slanje i primanje poruke: C(a) < C(b)
3. za sve a i b ako je C(a) C(b).


Slika 50. prikazuje usklaivanje vremenskih satova kako bi se mogla implementirati relacija happend
before. a) prikaz lokalnih satova b) prikaz usklaenih satova
Pri usklaivanju replika servera mogu se javiti sledei problemi. Korisnik u Niu ulae 100 dinara na raun
koji je trenutno na centralnom serveru u Beogradu i kopiji servera u Niu iznosi 1000 dinara. Istovremeno
slubenik banke u Beogradu aktivira program za obraun kamata na iznos korisnika. Kako e oba zahtjeva
biti proslijeena na oba servera doi e do izrauna trenutnog iznosa od 1110 dinara u Beogradu i 1111 u
Niu(slika 51.). Ova situacija izbegava se blokiranjem promena na podacima ija je izmjena u toku sve dok
se ne dobije potvrda o zavrenim izmenama na svim serverima replikama.

Slika 51. Primjer greke pri radu sa replikama podataka.
3.2. Algoritmi za izbor
U DS-u je esto potrebno selektirati proces koordinator to se realizira upotrebom odgovarajueg algoritma
za izbor. Algoritmi za izbor su:
1. Bully algoritam
2. Ring algoritam.
Bully algoritam radi na sledeem principu: procesima se dodeljuju brojevi ovisno o vremenu nastanka
(najstariji proces ima najvei broj); pri izboru proces P alje poruku ELECTION svim drugim procesima sa
96
upitom za vrednost dodeljenog broja; ako niti jedna poruka nema vei broj od broja koji ima P proces P je
izabran; ako se pojavi poruka sa veim brojem proces koji je poslao poruku je izabran (slika 52).
Ring algoritam koristi krug za odabir procesa. Kada koordinator nije aktivan pokree se ELECTION poruka
koja sadri broj procesa. Ako susedni proces nije aktivan poruka se prosleuje sledeem procesu u krugu.
Pri svakom prijemu poruke proces poveava svoj broj pa e tako proces sa najveim brojem biti izabran.
Kada poruka stigne ponovo do procesa koji ima najvei broj on se proglaava koordinatorom i alje
ostalima poruku o tome i procesima ukljuenim u krug (slika 53.)


Slika 52. Bully algoritam a) proces 4 zapoinje odabir b) proces 5 i 6 odgovaraju c) proces 5 i 6 zapoinju
odabir d) proces 5 i 6 zaustavljaju odabir e) proces 6 je odabran i informira ostale

Slika 53. Ring algoritam


97
3.3. Mutual Excluison
U DS-u je nuno implementirati mutual excluison kako bi se izbegle greke u radu sa deljivim resursima .
Implementacija mora ukljuiti sve resurse svih raunara ukljuenih u DS.Implementacija mutual
exclusiona ostvaruje se:
1. Centraliziranim pristupom - Centraliziran pristup znai upotrebu koordinatora sa pravima dodele dozvole
ulaska u kritinu sekciju na deljivom resursu. Svi procesi koordinatoru alju zahtjeve (request) za
ulaskom u kritinu sekciju. Ako je resurs slobodan koordinator dozvoljava slanje poruke potvrde ulaska
(reply) u kritinu sekciju i proces zapoinje kritinu sekciju. Ukoliko neki drugi proces zatrai ulazak u
kritinu sekciju na istom djeljivom resursu koordinator mu nee vratiti poruku potvrde za ulazak u
kritinu sekciju sve dok prvi proces ne zavri kritinu sekciju i vrati poruku zavretka kritine sekcije
koordinatoru (release). Slika 54. prikazuje centraliziranu izvedbu mutual exclusiona. Problem nastaje kad
koordinator nije u funkcionalnom stanju, ali u tom sluaju njegovu funkciju preuzima rezervni
koordinator.

Slika 54. Centralizirani pristup
a) slanje upita i dozvola ulaska u kritinu sekciju b) upit odbijen c) upit prihvaen
2. Decentraliziranim pristupom - Decentralizirani pristup znai da nema koordinatora ve procesi
meusobno dogovaraju dozvole ulaska u kritine sekcije. Ako jedan proces eli ui u kritinu sekciju
alje svim ostalim procesima poruku koja sadri naziv kritine sekcije, broj procesa i trenutno vreme.
Ako svi procesi vrate poruku potvrde (OK) proces ulazi u kritinu sekciju. Ako bi neki drugi proces
poslao nakon toga zahtev za ulaskom u kritinu sekciju dobio bi odgovor od svih procesa osim od
procesa koji je u kritinoj sekciji. Odgovor od procesa koji je u kritinoj sekciji uslediti e kada proces
zavri kritinu sekciju. Problem se moe pojaviti ako dva procesa istovremeno poalju zahtjev za
ulaskom u kritinu sekciju, a rjeava se usporeivanjem vremenskih oznaka dogaaja slanja poruke za
ulazak u kritinu sekciju (time stamps) pa se na taj nain odreuje koji proces prvi ulazi u kritinu
sekciju. Problem nastaje ako jedan proces nije funkcionalan jer tada niti jedan drugi proces ne moe
dobiti poruku potvrde za ulazak u kritinu sekciju pa je nuno detektovati takve procese i iskljuiti iz
komunikacije pri dodeli dozvola za ulazak u kritinu sekciju. Slika 55. prikazuje rad centraliziranog
pristupa pri izvedbi mutual exclusion-a.

Slika 55. Centralizirani pristup a) slanje zahtjeva b) dobivanje odgovora c) ulazak u kritinu sekciju
98
3. Koritenjem token-a. - Primena token-a znai upotreba poruke token za svaki deljivi resurs koja putuje
sistemom od procesa do procesa. Proces koji eli ui u kritinu sekciju zadrati e token kod sebe sve dok
ne zavri kritinu sekciju i tako osigurati izvoenje mutual exclusion-a. Problem nastaje ako se poruka
token izgubi pa je potrebno proveravati da li je poruka u sistemu i ako nije nuno je generisati novu
poruku. Slika 56. prikazuje primjenu token-a na neorganiziranu grupu procesa koja se softverski
povezuje u krunu strukturu.

Slika 56. Primjena token-a a) neorganizirana struktura b) logiki krug konstruiran u softveru

Tablica 4. prikazuje uporedni pregled naina za implementaciju mutaul ecxlusiona. Tablica sadri podatke
o broju potrebnih poruka, ekanju na ulazak u kritinu sekciju izraenom putem broja poruka za primanje i
problemima svake tehnike.

Tabela 4. uporeivanje tehnika za mutual exclusion
3.4. Atominost
Atominost se odnosi na transakcije odnosno skup akcija koje se moraju izvesti kompletno kako bi se
transakcija mogla zakljuiti. Ukoliko barem jedna akcija nije kompletirana, cela transakcija se ponitava i
vraa na poetak. Osnovne operacije za izvoenje atominih akcija su: BEGIN_TRANSACTION,
END_TRANSACTION, ABORT_TRANSACTION, READ_TRANSACTION, WRITE_TRANSACTION
Slika 57. prikazuje izvoenje transkacije pri rezrevaciji karata na relaciji Washington- New
York Nairobi Malindi.

Slika 57. Prikaz transakcija za rezervaciju karata
Svojstva transakcija - ACID:
1. Atominost akcije se izvode kao cjelina
99
2. Konzistentnost ukupno stanje vrednosti promenljivih sistema pre i posle transakcije je konzistentno
(nepromijenjeno)
3. Izoliranost akcije se mogu izvoditi paralelno ali to ne utie na rezultat izvoenja
4. Trajnost jednom zavrena transkacija ima trajan uinak na rezultate transakcije (nije mogue povratak
promenjenih vrednosti u transakciji)














Slika 58. Primjer transakcija i upravljanja transakcijama
Upravljanje transakcijama mora biti izvedeno na nain koji osigurava korektnu obradu na podacima. Slika
58.a) i 58.b) daju korektan rezultat dok 58.c)generie greku. Ugnedene transakcije su transakcije nieg
hijerarhijskog nivoa, a generiu se stvaranjem child procesa koji izvode aktivnosti nad podacima parent
procesa. Implementacija transakcija je izvediva primenom:
Privatni radni prostor blokovi podataka koji se menjaju u transakciji se kopiraju u slobodne blokove i
na njima se izvodi obrada; ukoliko se transakcija vrati na poetak, privremeni blokovi se briu, a za
kompletiranu transakciju privremeni blokovi postaju korektni blokovi dok se prethodni blokovi
proglaavaju nevaeim (slika 59.)
Writeahead log ili intention liste liste sadre popis promijenjenih vrednosti koje se koriste za
obnavljanje poetnih vrednosti u sluaju ponitenja transkacije (slika 60).













Slika 59. Privatni radni prostor

Slika 60. Primer upotrebe Whiteahead loga
100
15 as WWW i WEB aplikacije

WEB APLIKACIJE
Pod pojmom web aplikacije podrazumjeva se irok skup programskih reenja koje kao korisniki
interface (metod slanja zahtjeva i dobijanja rezultata) koriste neki web browser. Sve web aplikacije
funkcioniu po principu klijent server. Server predstavlja raunar na kojem je aplikacija smetena i
koji u zavisnosti od zahtjeva korisniku isporuuje (servira) rezultat u zavisnosti od tipa i funkcije
aplikacije. Klijet moe biti bilo koji web browser ili neki specijalno napravljeni klient program, koji
opet mora kontaktirati server da bi korisnik dobio rezultate na osnovu svojih zahteva. Najelementarniji
oblik web aplikacije jeste najobinija Internet prezentacija. Upravo zbog ove injenice, a i s obzirom
da najvei broj ljudi koji se koriste Internet-om, pojam web aplikacije poistoveuju sa web
prezentacijama, web aplikacije su obino predmet skepticizma i potcenjivanja kada su u pitanju
mogunosti realizacije nekih kompleksnih problema ili kreiranja nekog ozbiljnijeg software-a.
Kompletan software-ski dio web aplikacije smjeten je na serveru, i samim tim je dostupan na
korienje veem broju ljudi istovremeno. U isto vrijeme je siguran od krae, prepravljanja i uopte
bilo kakvog uticaja na kod u onolikoj mjeri u kojoj je i sam server siguran od neovlaenih upada.
Znai, nema nikakve potrebe za komplikovanim instalacijama, podeavanjima, voenja rauna o
kompatibilnosti. Sve se to zavrava na strani servera.
Server http ili https protokol Korisnik
Internet
Web
Aplikacija http ili https protokol Korisnik

Korisniku nije potreban nikakav specijalni software za pristup aplikaciji, nije ogranien da je mora
koristiti iskljuivo sa jednog raunara, a sama brzina komunikacije sa aplikacijom zavisi od brzine
kojom korisnik moe da pristupi serveru. Klient alikacija je web browser (MS Internet Explorer,
Mozilla, Opera) i obino je ukljuena u okviru operativnog sistema instaliranog na korisnikom
raunaru, ili dolazi kao sastavni deo nekog od klient software-skih paketa kao to je na primjer MS
Office. Upravo zbog ovih karakteristika web aplikacije, koristei Internet kao globalnu mreu, sve vie
se koriste za reavanje vrlo ozbiljnih korisnikih zahteva. On line kupovina, elektronsko bankarstvo,
informacioni sistemi u okviru firmi, turistike aplikacije i mnogi drugi sloeni sistemi bazirani su
upravo na web aplikacijama.
Danas, kada web predstavlja sve dominantniji medij za kolaboraciju i integraciju razliitih poslovnih
softvera unutar lanca snabdevanja, elektronskog trita, ali i ljudi, unutar odreene interesne zajednice,
od sutinske je vanosti da razvoj tehnologija koji e to omoguiti na efikasan nain, izlazi u susret
narastajuim potrebama trita u ovom segmentu. Osnovne tehnologije za izradu web aplikacija su
HTML jezik za izradu statikih strana i Server- Side Scripting jezici za generisanje HTML koda,
odnosno, izradu dinamikih strana. Preuzimanje i prikaz statikih web strane predstavlja jednu
realizaciju klijent server arhitekture, iji su akteri internet pretraiva, kao klijent i web server, kao
server, u ovoj arhitekturi. Web server predstavlja softver, koji se instalira na odrenenom, dostupnom
serverskom raunaru i koji upravlja zahtevima za pristup odrenenoj web stranici, tako to postupa po
zahtevu klijenta, isporuujui sadraj neke web strane. Web server i pretraiva komuniciraju
razmenom poruka putem HTTP (Hyper Text Transfer Protocol) protokola, koje mogu biti u vidu
zahteva (koji ini odgovarajue HTTP zaglavlje - header) i odgovora, koji ini odgovarajue HTTP
zaglavlje I sadraj samog odgovora, odnosno HTML kod koji se interpretira od strane internet
pretraivaa i prikazuje na njegovoj radnoj povrini.
Tok ove komunikacije je prikazan na slici 12.

Slika 12. Tok komunikacije u prikazu statikih web strana

Osnovna tehnologija za izradu web strana danas predstavlja HTML jezik. On se koristi za definisanje
sadraja ili elemenata interakcije (linkovi ili forme) jedne web strane, tako to definie komande
101
(odnosno, tagove), koje internet pretraivai, kao to su Internet Explorer ili Firefox, mogu da
interpretiraju na pravilan nain i, prema toj interpretaciji, korisniku jednog web sajta prikau njegov
sadraj. HTML je nastao uproavanjem SGML (Standard Generalized Markup Language,
standardizovani uopteni jezik za oznaavanje) standarda sa svrhom opisa dokumenta koji se
objavljuju na webu. U poetku je bio prilino ogranien to se oznaavanja sadraja tie i pruao je
uglavnom elementarne mogunosti za oznaavanje i formatiranje teksta (paragrafi, naslovi, citati itd.).
Kako je web rastao, tako je rasla i potreba za bogatijim sadrajem te je u tom smeru razvijan i HTML
standard. Tada su standardu dodate elementi za opis tabela, slika, slojeva, napredno formatiranje teksta
itd. HTML dokumenti se sastoje iz dva osnovna dela: dela koji opisuje dokument i dela koji
predstavlja sadraj dokumenta. Informacije koje opisuju sam dokument se smetaju u head tag, dok se
sam sadraj smeta u body tag. Oba ova elementa se nalaze unutar html taga.

Slika 13. Primer osnovne strukture HTML dokumenta
HTML dokumente, odnosno statike web strane ini isti HTML kod, i one predstavljaju datoteke sa
ekstenzijom htm ili html, koje se kodiraju i smetaju na odgovarajue mesto na web serveru. Osnovni
problem primene statikih web strana u sloenijim web aplikacijama je to to je njihov sadraj i
funkcionalnost unapred odrenen. Samim tim, statike web strane se ne mogu koristiti za kreiranje
interaktivnih i aurnih web aplikacija, kod kojih prikazani sadraj u svakom trenutku zavisi od
trenutnih okolnosti. Na primer, kod web aplikacija za komunikaciju izmenu ljudi, kao to su web
forumi, sadraj jedne strane koja prikazuje diskusiju o odrenenoj temi se stalno menja svaki put kada
neki korisnik te aplikacije da doprinos diskusiji. Dalje, web prikaz kataloga proizvoda se, takone,
kontinuirano menja svaki put kada se promeni dostupnost nekog proizvoda na lageru, doda novi
proizvod ili modifikuju atributi postojeeg cena ili drugi atributi.
Oigledno, postoji potreba za kreiranjem novog sloja u komunikaciji pretraivaa i web servera, koji
treba da programski obradi zahtev i parametre zahteva i, prema njihovom sadraju, automatski
generie odgovarajuu web stranu ili obradi zahtev i skladiti njegove parametre na odgovarajui nain
(uobiajeno, u neku relacionu bazu podataka). To se radi primenom tzv. dinamikih web strana
skupa instrukcija koje se po prijemu zahteva izvravaju i automatski kreiraju HTML kod, koji se, u
okviru HTTP odgovora isporuuje pretraivau. Na slici dole, prikazana je ema toka komunikacije
izmenu pretraivaa i web servera u prikazu dinamikih web strana.

Slika 14. Tok komunikacije u prikazu dinamikih web strana
Za kreiranje instrukcija ija je namena automatsko generisanje HTML koda, na osnovu parametara
zahteva, koriste se razliiti programski jezici i njihove varijante, kao to su PHP, JSP (Java), ASP
102
(Visual Basic), itd. Ove instrukcije nazivamo skriptovima na strane servera (Server- Side Scripts), zato
to se izvravaju na web serverima.

Slika 15. Obrada skripta na serveru
Ovi skriptovi uobiajeno ostvaruju vezu sa odgovarajuom bazom podataka u koju se smetaju
obraneni podaci i zahtevi i koja se, po odgovarajuem zahtevu i interpretira, sa ciljem prikaza
odrenenih podataka. Pored navedenih, druge prednosti korienja tehnologija na strani servera za
kreiranje dinamikih web strana su:
- Ova tehnologija omoguava da se neki program izvrava u programskim jezicima koje web
pretraivai ne podravaju.
- Ona daje mogunost da se programiraju dinamike Web aplikacije nezavisno od itaa, bez
pribegavanja programiranju na strani klijenta, pomou Java apleta, DHTML-a i ActiveX kontrola, od
kojih svaki zahteva odreneni internet pretraiva, odnosno njegove konkretne karakteristike.
- Ona moe klijentu (pretraivau) da dostavi podatke koji su mu inae nedostupni.
- esto ostvaruje bre vreme uitavanja.
- Obezbenuje poboljane mere bezbednosti.
Ipak, vano je napomenuti da korienje dinamikih web strana poveava optereenje web servera,
naroito ukoliko njima pristupa vei broj korisnika. Iz ovog razloga, uobiajeno je potrebna vea
inicijalna investicija u hardver web servera, koji se koriste za generisanje dinamikih web strana. Jezik
koji se najee koristi za kreiranje dinamikih web strana je PHP. PHP je stekao popularnost zbog
svoje jednostavnosti i sintakse naslenene iz programskog jezika C. Tokom vremena jezik se proirivao
i sticao mogunosti za objektno orijentisano programiranje, naroito od verzije 5.0. Nalikuje jeziku
C++ u smislu da dozvoljava i isto-proceduralno programiranje, ali omoguava i korienje klasa i
drugih koncepata objektno orijentisanog programiranja (naslenivanje, apstraktne metode, interfejsi
itd.).
1.1 ta su to Web servisi?
Web servis je vrsta distribuirane aplikacije sa interfejsom kome se moe pristupiti preko
komunikacione mree kao to je Internet. Tipina arhitektura u kojoj se koriste Web servisi je klijent-
server arhitektura. Samo ime Web servis nagovetava da se radi o aplikaciji koja se koristi putem
interneta, najee preko HTTP (Hyper Text Transfer Protocol) protokola. Web servisi predstavljaju
gradivne blokove savremenih i buduih informacionih sistema. Poto je re o distribuiranim
aplikacijama na internetu, Web servisi se adresiraju tj. pristupa im se preko URL adresa. Osnovna
karakteristika Web servisa je interoperabilnost. Pojam interoperabilnost odnosi se na mogunost da
aplikacije pisane u razliitim programskim jezicima i razvijene na razliitim platformama mogu da
komuniciraju. Kod Web servisa potuju se tano definisana pravila kako bi bila omoguena
komunikacija razliitih tehnologija.
1.2 Osobine Web servisa
Postoji nekoliko razloga koji su uslovili pojavu i razvoj Web servisa:
1. Interoperabilnost (Interoperability) je potreba za komunikacijom aplikacija razvijenih u razliitim
tehnologijama, u razliitim programskim jezicima i na razliitim platformama. Web servisi
omoguavaju ovakvu komunikaciju.
103
2. SOA (Service Oriented Architecture) je pristup u razvoju softvera koji podrazumeva razdvajanje
funkcija u odvojene servise, dostupne preko komunikacione mree. Razdvojeni servisi olakavaju
kombinovanje i korienje ve implementiranih funkcionalnosti bez potrebe njihovog ponovnog
razvoja.
3. Skalabilnost (Scalability) predstavlja potrebu da se postojei skupovi funkcionalnosti menjaju
(poveavaju ili smanjuju) uz minimalne trokove i najmanji mogui negativan uticaj na rad
sistema.
Evo nekoliko primera korienja Web servisa: pregled kursnih lista, vremenska prognoza, kreditni
biro, validacije kreditnih kartica prilikom online plaanja i td.
1.3 Platforme za razvoj Web servisa
Brzina razvoja interneta i tehnologija koje se koriste na internetu dovela je do nastanka mnogih
tehnologija za razvoj Web servisa koji su istom tom brzinom i nestale. Sa dananje take gledita
postoje dve platforme za razvoj Web servisa, Microsoft.NET i Sun J2EE, i bez obzira na odabranu
platformu, Web servisi mogu sa lakoom da pozivaju jedni druge.
1.4 Podela Web servisa
Web servisi se grubo mogu podeliti u dve grupe: SOAP i REST Web servisi. Razlika izmeu ova dva
tipa nije otra. SOAP Web servis kome se pristupa preko HTTP protokola je specijalan sluaj REST
Web servisa. SOAP predstavlja skraenicu od Simple Object Access Protocol (protokol za jednostavan
pristup objektima). Ovu skraenicu ne treba meati sa skraenicom SOA (Service Oriented
Architecture) arhitektura orijentisana servisima. Web servisi igraju centralnu ulogu u SOA pristupu
razvoja softvera. SOAP poruka je XML dokument definisan XML emom. Kod SOAP Web servisa,
SOAP poruke nisu predmet interesa programera koji kreira Web servis ili pie klijentski kod za
korienje Web servisa. SOAP poruke omoguavaju komunikaciju klijentske aplikacije koja
konzumira Web servis i samog Web servisa. Na primer, u tipinom scenariju nazvanom razmena
poruka inicirana zahtevom od klijenta (request/response message exchange pattern), SOAP bibliteka
na strani klijenta alje SOAP poruku kao Web servis zahtev, a SOAP bibliteka na strani Web servisa
alje drugu SOAP poruku kao odgovarajui odgovor klijentu (slika broj 1).

Klijent SOAP Web servis

Zahtev
SOAP biblioteke SOAP biblioteke
Odgovor

Slika 1. Komunikacija kod SOAP Web servisa

Ime REST dolazi od Representational State Transfer. Dok je SOAP stil Web servisa definisan
standardima od strane tela koja se bave standardizacijom Web-a kao to je W3C (World Web
Consortium) konzorcijum, za REST Web servise nisu definisani standardi, biblioteke, niti alati za
razvoj. Uvoenje REST Web servisa u upotrebu predstavlja pokuaj da se prevazie sloenost SOAP
Web servisa. Klijent Web servisa moe biti napisan u bilo kom programskom jeziku koji ima
odgovarajue biblioteke za podrku Web servisima. Najvea dobrobit koja se dobija od Web servisa je
nezavisnost od programskog jezika ili tzv. jezika transparentnost. Klijent i Web servis ne moraju da
budu napisani u istom programskom jeziku. Na primer, klijent Java Web servisa moe da bude napisan
u nekom od programskih jezika kao to su C#, Perl, Ruby i td. Isto tako, Java klijenti mogu
konzumirati Web servise napisane u drugim programskim jezicima. Magija u transparentnosti
programskog jezika ne postoji. Ako SOAP Web servis napisan u Javi moe da ima klijenta razvijenog
u programskim jezicima kao to su Perl i Ruby, onda mora da postoji neto to premoava razlike
izmeu tipova podataka programskog jezika na strani klijenta i na strani Web servisa. XML
tehnologija, koja podrava razmenu struktuiranih podataka i njihovo skladitenje, predstavlja tu
neophodnu spregu.
Nekoliko bitnih osobina izdvaja Web servise od drugih distribuiranih softverskih sistema:
104
Korienje postojee infrastrukture. Web servisi u osnovi koriste standarde koji su nezavisni od
proizvoaa. Ti standardi su HTTP i XML koji su sveobuhvatni i razumljivi. HTTP omoguava
transport poruka a XML omoguava struktuiranje podataka. Web servisi ne zahtevaju nove sisteme
ve se oslanjaju na postojee komunikacione mree (internet), standarde za formatiranje podataka,
bezbednost i infrastrukturu koja ve postoji ime se sniavaju trokovi i pospeuje interoperabilnost.
Transparentnost u odnosu na programski jezik. Web servisi i njihovi klijenti mogu da
komuniciraju ak i kada su napisani u razliitim programskim jezicima. Programski jezici kao to su
C/C++, C#, Java, Perl, Python i drugi obezbeuju biblioteke i okvire (framework) za podrku Web
servisima.
Modularna arhitektura. Web servisi su sami po sebi moduli koji se mogu koristiti pri razvoju
aplikacija. Integracijom postojeih Web servisa mogu se dobiti novi Web servisi (na primer,
povezivanje servisa koji prati koliinu robe u skladitu i servisa za online kupovinu te robe, moe
voditi stvaranju servisa koji automatski naruuje robu od dobavljaa u zavisnosti od koliine robe u
skladitu).
1.5 Korist od Web servisa
Danas postoje brojni softverski sistemi koji su razvijeni u razliitim programskim jezicima i rade na
razliitim platformama. U malom broju sluajeva pomenuti sistemi rade u potpunoj izolaciji. Tipini
softverski sistem mora da komunicira sa drugim sistemima koji su implementirani u drugim
tehnologijama. Malo kompanija, koje su vlasnici ovakvih sistema, ima finansijska sredstva i ljudske
resurse da zastarele sisteme realizuje u novim tehnologijama. Zato se javlja potreba za komunikacijom
sistema koji su razliiti u pogledu implementacionih tehnlogija i platformi na kojima rade. Takva
komunikacija naziva se interoperabilnost. Web servisi uspeno reavaju ovaj problem jer za
komunikaciju koriste HTTP i XML protokol.
Uvod u web servise
Web servisi predstavljaju novu primenu standardnih softverskih tehnologija koja omoguava
povezivanje raznorodnih informacionih sistema na novi nain, korienjem internet protokola, i to
unutar jednog integrisanog ili vie poslovnih procesa. Osnovni motiv razvoja i korienja tehnologije
web servisa predstavlja mogunost integracije raznovrsnih informacionih sistema instaliranih u
distribuiranim okruenjima. Oni predstavljaju skup aplikacionih funkcija koje se mogu programski
pozivati putem interneta. Jedan web servis je bilo koji skup metoda za obradu i isporuku informacija,
dostupan posredstvom HTTP i SMTP protokola, a koji nije vezan za odrenenu operativnu platformu ili
programski jezik i koji koristi XML notaciju za razmenu poruka. Web servisi predstavljaju tehniku
evoluciju koncepta servisno orijentisane arhitekture. U arhitekturi okruenja koje karakteriu web
servisi, jedna mrena komponenta moe imati ulogu provajdera servisa, korisnika ili klijenta servisa, i
brokera servisa.

Slika 18. Uloge i interakcije u arhitekturi web servisa
Provajder servisa je odgovoran za kreiranje i aktiviranje web servisa u njegovoj nadlenosti, kao i
objavljivanje dostupnosti servisa, opisanog putem WSDL standarda u registar servisa, kao to je UDDI
poslovni registar. Uloga brokera servisa je registracija i kategorizacija objavljenih servisa i
obezbenenje funkcija za njihovo pretraivanje. U arhitekturi web servisa, UDDI ima ulogu registra
servisa opisanih putem korienjem WSDL standarda. Osnovna karakteristika internet standarda je da
su njihov fokus protokoli, a ne njihove implementacije. S obzirom na to da internet ini niz
heterogenih tehnologija, ovaj nivo generinosti garantuje funkcionisanje u nehomogenom okruenju i
visoku interoperabilnost. Mogunosti integracije jedinstvenog informacionog sistema, odnosno
prevazilaenja nekompatibilnosti njegovih komponenti se ostvaruju primenom skupa softverskih
standarda kao to su XML, SOAP (Simple Object Access Protocol), UDDI (Universal Description
Discovery and Integration), WSDL (Web Services Description Language), WSIL (Web Services
Inspection Language), WS-S (Web Services Security) i WS-I (Web Services interoperability). Ovi
standardi omoguuju definisanje, pakovanje, pristupanje i izvravanje podataka i programa preko
Interneta, bez potrebe za vonenjem rauna o pojedinanim implementiranim tehnologijama.

105
Slika 19. Relacije izmenu SOAP, UDDI, WSDL i WSIL protokola
Provajder servisa obezbenuje njegovu dostupnost uz pomo svoje tehnike infrastrukture, koja
podrava SOAP/HTTP ili SOAP/JMS (Java Messaging Services) komunikaciju. Web servis je opisan
u WSDL dokumentu koji se skladiti na serveru provajdera u posebnom repozitorijumu. Reference na
web servis, odnosno podaci koji ukazuju na WSDL dokument, mogu da postoje u UDDI registru ili
WSIL dokumentima. WSDL predstavlja otvorenu specifikaciju, zasnovanu na XML standardu koja
opisuje interfejse ka web servisima na mrei i njihove instance. WSDL sintaksom se opisuju sve vrste
aktivnosti koje moe da izvri neki web servis. Ona omoguava da se vorovi servisno orijentisane
arhitekture opiu, bez obzira na formate poruka koje razmenjuju ili mrene protokole koje koriste za
razmenu. Dostupnost WSDL dokumenata se obezbenuje kroz UDDI ili WSIL, ili javnim
objavljivanjem njihovog URL-a nekim drugim konvencionalnim sredstvom. Primenom njegove
sintakse, mogu se definisati sledee karakteristike web servisa:
- Naziv web servisa i informacije o njegovom adresiranju
- Protokol i encoding stil koji e se koristiti prilikom pristupanja javnim operacijama web servisa
- Strukturne informacije meta podaci servisa, kao to su operacije, parametri i tipovi podataka koji
ine interfejs web servisa.
Jedan WSDL dokument definie servise kao skup mrenih zavretaka (network endpoints) ili portova.
WSDL omoguava apstraktnu definiciju operacija i poruka i njihovo referenciranje - vezivanje
(binding) za tano odreneni mreni protokol i format poruke. Pritom, definicija operacija i poruka je
nezavisna od parametara njihovog vezivanja, odnosno korienih protokola i formata poruka.
Parametri vezivanja predstavljaju ugovor izmenu logike klijenta i logike servera servisa posrednika
izmenu meta opisa web servisa i njegove konkretne realizacije. U tradicionalnom distribuiranom
programiranju, realizacija poslovne logike, odnosno, logike na serverskoj strani, obuhvata veoma esto
statiko vezivanje (static binding) - generisanje proxy objekata koji su namenjeni klijentima, za
ostvarivanje njihove komunikacije sa serverom, primenom predvinenih protokola, od kojih jedan moe
da bude i SOAP. Ipak, jedan od osnovnih ciljeva servisno orijentisane arhitekture je dinaminost web
servisa oni mogu biti predmet izmene, bez ikakve prethodne najave, ili ak ponovne distribucije
klijentskih proxy-ja. Razlog za to je, izmenu ostalog i injenica da su njihovi vlasnici veoma esto
tree strane, a sadraj usluga definisanih web servisom unapred nepoznat. Oigledno, navedeni
princip obezbenuje karakteristiku proirivosti web servisa, ali i viestrukog korienja definisanih
formata poruka. Demonstracija ovog principa uz pomo elemenata strukture WSDL i njihov odnos je
prikazana na slici dole.

Slika 20. Elementi strukture WSDL
Za definisanje mrenih servisa, WSDL koristi sledee elemente sintakse:
106
- Tipovi (Types). Kontejneri za definicije tipova podataka, definisanih uz pomo XML sintakse,
odnosno odgovarajue XSD strukture. XML i XSD definicije tipova se koriste u cilju ostvarivanja
maksimalne neutralnosti formata.
- Poruka (Message). Apstraktna definicija podataka koji se razmenjuju u komunikaciji izmenu
provajdera i korisnika web servisa. Svaka poruka se moe sastojati iz jednog ili vie delova. Delovi
poruke su analogni atributima poziva jedne operacije.
- Operacija (Operation). Apstraktni opis akcije podrane od strane servisa.
- Tip porta (Port Type). Apstraktni skup operacija podran od strane jednog ili vie mrenih
zavretaka.
- Referenciranje - vezivanje (Binding). Specifikacija konkretnog protokola i specifikacija formata
podataka za odreneni tip porta. Kao protokol se obino koristi SOAP, dok format podataka moe biti
definisan kao dokument (document) ili nekodirani tekst (literal). Drugi izbor predstavlja HTTP
izborom ovog protokola, format poruke se ograniava na proste tipove (npr. tekst), dok se SOAP
koristi za sloenije strukture podataka.
- Port. Mreni zavretak definisan kao kombinacija parametara vezivanja i mrene adrese.
- Servis (Service). Skup mrenih zavretaka.
Prilikom implementacije web servisa uz pomo Java programskog jezika, poslovna logika web servisa
je enkapsulirana u Java bean-ovima ili EJB (Enterprise Java Bean). Savremene Java razvojne
platforme omoguavaju generisanje WSDL dokumenata na osnovu strukture postojeih Java bean-ova
ili EJB, i obrnuto. Sa stanovita klijenta web servisa, vano je istai da ove platforme mogu omoguiti
i generisanje Java proxy koda, namenjenog upravo klijentu, na osnovu strukture postojeeg WSDL
dokumenta i tako obezbediti lak i brzi razvoj klijenta za korienje usluga web servisa.
Razvoj web servisa
Razvoj web servisa predstavlja integralni deo razvoja ukupne servisno orijentisane arhitekture.
Osnovne aktivnosti procesa razvoja web servisa su:
- Otkrivanje (Discover). Pretraivanje UDDI poslovnih registara ili WSIL dokumenata u cilju lociranja
postojeih web servisa sa kojima je potrebno izvriti integraciju. - Kreiranje ili transformacija (Create
or Transform). Ovaj proces karakteriu dva mogua pristupa top-down ili bottom-up. Top-down
pristup podrazumeva kreiranje WSDL interfejsa uz pomo odgovarajueg editora i generisanje skeleta
odgovarajuih klasa na osnovu njegove strukture. Bottom-up pristup podrazumeva generisanje WSDL
datoteka na osnovu postojeih implementacija, sadranih u postojeim Java bean-ovima ili EJB.
- Postavljanje (Deploy). Instaliranje web servisa u okruenjima za testiranje.
- Testiranje (Test). Provera kvaliteta funkcionisanja web servisa, lokalno i u distribuiranom okruenju.
- Razvoj (Develop). Razvoj klijentskih aplikacija.
- Objavljivanje (Publish). Objavljivanje informacija o web servisu u UDDI registrima.
Integrisanje poslovnog softvera primenom web servisa
Dijagram sa primenom integracije dva poslovna informaciona sistema primenom web servisa je
prikazan na slici dole. WSDL datoteke svakog poslovnog okruenja obuhvataju skup metoda,
predstavljenih imenom, argumentima, tipom rezultata i poslovnom logikom, koje su dostupne
autorizovanim korisnicima ili su javne.

Slika 21. Primer integracije dva poslovna sistema posredstvom web servisa
Sa stanovita integracije izolovanih aplikacija i njihovih funkcija uz pomo web servisa, oni se mogu
organizovati na dva naina: uz pomo orkestracije (Orchestration) ili koreografije (Choreography).
Orkestracija se uobiajeno primenjuje u privatnim okruenjima (preduzea) i podrazumeva postojanje
centralni proces (koji takone moe biti web servis) sa ulogom koordinacije i kontrole svih ostalih web
servisa. Pritom, nijedan web servis, osim centralnog, nije svestan svoje uloge u orkestriranom
okruenju.
Slika 22. Orkestracija web servisa
Sa druge strane, u javnim okruenjima, u okviru kojih postoji veliki broj korisnika usluga i vei nivo
kolaboracije u ostvarenju nekog cilja, za integrisanje web servisa se primenjuje metod koreografije.
Akteri koreografije su web servisi koji tano znaju sa kim mogu razmenjivati poruke i kada.
107
Dalji razvoj klijent server sistema i Interneta
Originalna namena Interneta je bila povezivanje raunara i razmena podataka. Zato su bili razvijeni
protokoli koji su omoguili postizanje tog osnovnog cilja. Problem je to povezivanje raunara nee
biti jedini cilj globalne mree u budunosti i zato moraju da se pojave novi protokoli koji e omoguiti
ostvarivanje novih ciljeva. Kao to su personalni raunari bili fenomen 80-ih godina prolog veka, tako
su multimedijalne i video aplikacije postale fenomen deceniju kasnije i poetkom ovog veka. Zabava i
digitalna tehnologija nastavljaju da se spajaju, nameui nove zahteve koje globalne mree moraju da
ispune. Servis plaanja po gledanju je ve dostupan kod kablovskih sistema, a dostupno postaje i
prikazivanje videa na zahtev. Sve vei broj ljudi ve uiva u real-time video igrama preko Interneta.
Mobilnost je sledei aspekat razvoja. U trenutnoj Internet zajednici najvei deo host raunara nikada
ne menja lokacije. Premetaju se iz jedne kancelarije u drugu, ali to je problem lokalnog upravijanja. Iz
perspektive Internet protokola, oni zadravaju fiksne lokacije. Meutim, i to se menja. Mobilni
raunari i satelitske tehnologije obezbeuju sredstva za komunikaciju dva ureaja u svim delovima
sveta. Protokoli moraju da se razvijaju tako da omogue povezivanje miliona parova ureaja sa
proizvoljnih lokacija.
Neki ljudi vide tekue tehnologije, kao to su mobilni telefoni, pejeri, PDA i prenosivi raunari, kao
ureaje koji e eventualno prerasti od ureaja za line potrebe u ureaje koji mogu da ispune razliite
vrste zahteva. Iniciranje telefonskih poziva i prihvatanje poruka preko pejera predstavljaju sasvim
uobiajene funkcije, ali mnogi smatraju da e doi dan kada e ti ureaji omoguavati mnogo vie.
U kuama e moda postojati raunarizovani ureaji sa kojima e moi da se komunicira. Ako se
vraate svom domu kasnije nego to ste planirali, mogli biste da iskoristite personalni komunikacioni
ureaj za ukljuivanje svetla u kui, ili za ukljuivanje penice. Senzorski sistem moe da poalje
signal ako ste zaboravili da zakljuate sva vrata, ili da ugasite svetla, tako da biste mogli da to ispravite
opet korienjem istog sistema.
Moda ete moi da ukljuite ureaj u prenosivi kompjuter i da preuzimate fajlove sa bilo kog
udaljenog raunara kojem imate pristup, bez korienja telefona. Sistem biste mogli iskoristiti i da
nahranite svog sajber ljubimca koga ste ostavili kod kue. Sve ove aplikacije bi zahtevale
komunikacije nezavisne od mesta.
Bezbednost je sledei problem. Internet protokol nije preterano siguran. Zbog toga su za veinu
aplikacija veoma bitne lozinke, tehnike autentifikacije i firewall-i. Ljudi prepoznaju da paketi koji stiu
na Internet mogu da stignu doslovno iz bilo kog dela sveta i zato su za zatitu resursa neophodne
veoma jake mere zatite. U poslednjih nekoliko godina svedoci smo raznih prevara i upada na privatne
kompjutere, tako da je svima jasno da zatita uvek mora da bude prioritet broj jedan.
I pored svega toga, najvaniji cilj kod razvoja svakog novog protokola je mogunost koegzistencije sa
tekuim sistemima. Najvea prepreka za uvoenje novih tehnologija u raunarstvo je osiguravanje
konkurentnog izvravanja sa postojeim tehnologijama.