Poglavlje 2 - Informacioni Sistem PDF

Sadržaj
Poglavlje 2: Informacioni sistem ............................................................................................................. 2

1. Pojam informacioni sistem ......................................................................................................... 2
2. Fundamentalni model informacionog sistema ........................................................................... 3
2.1. Softver informacionog sistema ........................................................................................... 3
2.2. Arhitektura sistema, arhitektura informacionog sistema i arhitektura softvera................ 4
2.3. Arhitekturalni stilovi i obrasci softvera ............................................................................... 5
2.3.1. Slojevita/višeslojna arhitektura .................................................................................. 6
2.3.2. Događajem vođena arhitektura ................................................................................ 10
2.3.3. Arhitektura mikrojezgra ............................................................................................ 15
2.3.4. Mikroservisna arhitektura ......................................................................................... 18
2.3.5. Prostorno-bazirana arhitektura ................................................................................ 24
2.4. Arhitektura podataka ........................................................................................................ 29
2.4.1. Konceptualni model .................................................................................................. 30
2.4.2. Logički model ............................................................................................................ 30
2.4.3. Fizički model .............................................................................................................. 31
2.4.4. Uporedna analiza konceptualnog, logičkog i fizičkog modela .................................. 32
2.4.5. Klasifikacija logičkih modela...................................................................................... 32
2.4.6. Sažeto poređenje osnovnih modela ......................................................................... 37
2.5. Informaciona arhitektura .................................................................................................. 38
2.6. Komunikaciona arhitektura............................................................................................... 39
2.6.1. TCP/IP model ............................................................................................................. 39
Literatura uz Poglavlje 2........................................................................................................................ 42
Poglavlje 2: Informacioni sistem
U ovom odeljku pozabavićemo se pojmom informacioni sistem na način koji je bliži praksi i pogledu na
informacioni sistem koji imaju oni koji se bave razvojem informacionih sistema. Daćemo definiciju
pojma i vrlo sažeto objašnjenje osnovnih komponenti informacionog sistema. Rukovodeći se
osnovnom namenom ovoga teksta, detaljnije će biti objašnjena komponenta informacionog sistema
zvana softver.
1. Pojam informacioni sistem

Pre no što objasnimo pojam informacionog sistema, podsetićemo se značenja termina sistem [1]:
"Sistem je skup međusobno povezanih komponenti sa jasno definisanom granicom, koje zajedno rade
na ostvarivanju skupa zajedničkih ciljeva prihvatanjem ulaza i proizvođenjem izlaza u organizovanom
procesu transformacije. Siastemi imaju tri osnovne funkcije:
• Ulaz obuhvata prikupljanje i asembliranje elemenata koji ulaze u sistem da bi se obradili. Na
primer, sirovi materijali, energija, podaci, ljudski rad moraju se obezbediti i organizovati za
obradu.
• Obrada uključuje proces transformacije koji prevodi ulaz u izlaz. Primeri su proizvodni procesi,
proces disanja kod čoveka, ili matematička računanja.
• Izlaz obuhvata prenošenje elemenata proizvedenih transformacijom do njihovog krajnjeg
odredišta. Na primer, gotovi proizvodi, ljudske usluge i menadžerske informacije moraju se
preneti svojim ljudskim korisnicima."
Koncept sistema dobija punu vrednost kada se prethodnoj definiciji pridruže pojmovi povratne sprege
i upravljanja.
Povratna sprega može se definisati kao podatak o performansi sistema a upravljanje kao element koji
se bavi nadgledanjem i evaluacijom povratne sprege da bi se obezbedilo kretanja sistema ka
postavljenim ciljevima.
Šire gledano, informacioni sistem je oblik komunikacionog sistema u kome podaci predstavljaju oblik
socijalne memorije i obrađuju se kao oblik socijalne memorije.
Informacioni sistem se može smatrati i polu-formalnim jezikom koji podržava ljudsko odlučivanje i
akcije.
Stiven Alter posmatra informacioni sistem kao poseban tip sistema rada (work system), sistema u
kome ljudi ili mašine izvršavaju procese i aktivnosti koristeći resurse da bi proizveli specifične
proizvode ili servise za potrošače. Informacioni sistem je sistem rada čije aktivnosti su posvećene
prikupljanju, prenošenju, skladištenju, pretraživanju, manipulisanju i prikazivanju informacija.
(https://en.wikipedia.org/wiki/Information_system;
https://repository.usfca.edu/cgi/viewcontent.cgi?article=1034&context=at).
Bilo koji specifični informacioni sistem ima za cilj da podrži operativni rad, upravljanje i odlučivanje.
Sada ćemo dati nekoliko definicija pojma informacioni sistem.
"Informacioni sistem (IS) je kolekcija više komada opreme uključenih u diseminaciju informacija.
Hardver, softver, veze računarskih sistema i informacije, korisnici informacionog sistema i smeštaj
sistema, sve su to delovi IS-a." (https://www.techopedia.com/definition/24142/information-system-
is).
"Informacioni sistem (IS) je integrisani skup komponenti za prikupljanje, skladištenje i obradu
podataka i za obezbeđenje informacija, znanja i digitalnih proizvoda." "Glavne komponente
informacionih sistema su računarski hardver i softver, telekomunikacije, baze i skladišta podataka,
ljudski resursi i procedure." (https://www.britannica.com/topic/information-system).
"Informacioni sistemi (IS) su formalni, socio-tehnički, organizacioni sistemi projektovani da prikupljaju,
skladište i distribuiraju informacije. Iz socio-tehničke perspektive informacioni sistemi se sastoje od
četiri komponente: tehnologije, procesa, ljudi i organizacione strukture."
(https://en.wikipedia.org/wiki/Information_system)
"Informacioni sistem (IS) može da bude bilo koja organizaciona kombinacija ljudi, hardvera, softvera,
komunikacionih mreža, resursa podataka i politika i procedura koja skladišti, pretražuje, transformiše
i diseminira informacije u organizaciji. " [1]
Zajedničko za sve navedene definicije je da su u pitanju sistemi koji se bave kreiranjem (prikupljanje,
obrada i skladištenje) i razmenom (obezbeđivanje i konzumiranje) informacija i sastoje se od četiri
glavne komponente: tehnologije, procesa, ljudi, i organizacione strukture.
U današnjim uslovima ciljevi informacionog sistema se, najvećim delom, ostvaruju primenom
informaciono-komunikacione tehnologije (ICT). Ovaj tekst bavi se jednom od komponenti
informacionog sistema, tehnologijom preciznije jednom od komponenti tehnologije - softverom.
2. Fundamentalni model informacionog sistema

Informacioni sistem je sistem koji za ulaz ima podatke i koji te podatke obrađuje u informacione
proizvode (informacije) koji su njegov izlaz.
Model informacionog sistema koji predstavlja fundamentalni konceptualni okvir informacionog
sistema obuhvata glavne komponente informacionih sistema. Model komponente klasifikuje u dve
grupe: (1) resurse informacionog sistema i (2) procese informacionog sistema kojim se ulazni podaci
prevode u željeni informacioni izlaz.
Resursi informacionog sistema su:
• ljudi (krajnji korisnici i IS specijalisti),
• hardver (računari, U/I uređaji i mediji)
• softver (programi i procedure),
• podaci (baze podataka i znanja), i
• mrežni resursi (komunikaciona infrastruktura)
Procesi informacionog sistema obuhvataju:
• ulaz podataka (obuhvat podataka i priprema za obradu),
• obradu podataka u informacije (računanja, poređenja, sortiranja, klasifikovanja, sumiranja;
kontinualno korigovanje i ažuriranje podataka),
• izdavanje informacionih proizvoda (poruke, izveštaji, forme, grafici, video, audio,
multimedija).
• skladištenje podataka (organizovano pamćenje podataka za kasniju upotrebu),i
• upravljanje performansom sistema (povratne informacije o aktivnostima ulaza, obrade,izlaza
i skladištenja koje se pribavljaju, nadgledaju, evaluiraju i koriste za korigovanje aktivnosti).
U okviru ovoga kursa bavićemo se dominantno sa dva resursa informacionog sistema: softverom i
podacima. Ljudske resurse i hardver nećemo nikako razmatrati, a o mrežnim resursima u užem smislu
Izložićemo samo one aspekte koji su relevantni za razvoj, konstrukciju i operativni rad informacionog
sistema u Web okruženju.
2.1. Softver informacionog sistema

Koncept softverski resurs obuhvata sve skupove instrukcija za obradu informacija što znači da generički
koncept softvera, pored računarskih programa, obuhvata i ljudima namenjene instrukcije za obradu
koje se nazivaju procedure. Dakle, čak i informacioni sistemi koji ne koriste računare imaju
komponentu softverskog resursa.
Tipični primeri softverskih resursa u današnjim informacionim sistemima su sistemski softver,
aplikativni softver i procedure.
Sistemski softver obuhvata računarske programe namenjene obezbeđenju okruženja/platforme za
izvršavanje drugih tipova softvera (programi operativnog sistema, programi za upravljanje uređajima,
korisnički interfejs, numerički softver, SaAS podrška, ...).
Aplikativni softver obuhvata računarske programe koji izvršavaju obrade namenjene rešavanju
specifičnih zadataka za krajnje korisnike (analiza prodaje, podrška procesu učenja/obrazovanja,
obrada teksta, bankarski softver, ...).
Procedure obuhvataju operativne instrukcije namenjene ljudima koji koriste informacioni sistem
(uputstva za popunjavanje formi, uputstva za korišćenje softverskih paketa, uputstva za instaliranje
softvera,...). Pored procedura namenjenih krajnjim korisnicima, tu su i procedure namenjene onima
koji softver razvijaju, uvode ga u operativni rad, i održavaju ga.
Postoji mnogo klasifikacija softvera zasnovanih na različitim kriterijumima i, shodno tome,
komponovanih od različitih klasa. Uobičajena klasifikacija [1] kategoriše softver u dve osnovne
kategorije: (1) sistemski softver i (2) aplikativni softver.
Sistemski softver je softver koji služi za upravljanje i podršku rada računarskih sistema i mreža. Dalje
se klasifikuje na (1) programe za sistemski menadžment i (2) programe za sistemski razvoj.
• Programi za sistemski menadžment obuhvataju operativne sisteme, softvere za rad i
upravljanje mreže, sisteme za upravljanje bazama podataka, aplikativne servere, pomoćne
sistemske programe, bezbednosne monitore i monitore performanse.
• Programi za sistemski razvoj obuhvataju prevodioce programskih jezika, editore i alate,
računarski podržane (Computer-Aided Software Engineering, CASE) alate/pakete/okruženja
za softversko inženjerstvo.
Aplikativni softver izvršava zadatke obrade informacija za krajnje korisnike. Klasifikuje se na (1) opšte-
namenske aplikativne programe i (2) aplikaciono-specifične programe.
• U opšte-namenske aplikativne programe spadaju Web čitači, softveri za elektronsku poštu,
obrade teksta, tabelarne proračune, upravljanje bazama podataka, prezentacionu grafiku,
podršku grupnom radu, upravljanje ličnim informacijama, itd.
• U aplikativno-specifične programe spadaju poslovno-računovodstveni softveri, softveri za
obradu transakcija, softveri za upravljanje odnosima sa potroščima, ERP (Enterprise Resource
Planning) softveri, softveri za elektronsku trgovinu, naučne i inženjerske aplikacije,
obrazovanje, zabava, itd.
2.2. Arhitektura sistema, arhitektura informacionog sistema i

arhitektura softvera
Arhitektura sistema ( https://en.wikipedia.org/wiki/Systems_architecture) je konceptualni model koji
definiše strukturu, ponašanje i više pogleda na sistem. Opis arhitekture je formalan opis i
reprezentacija sistema kojim se podržava rasuđivanje o strukturama i ponašanju sistema.
Arhitekturni domen u arhitekturi „preduzeća“ (orig. enterprise) 1 je jasan pogled na preduzeće ili
sistem. On je delimična reprezentacija celokupnog sistema koja se bavi nekim predmetima
interesovanja nekih zainteresovanih strana. On je opis koji sakriva druge poglede na sistem. Prema
izvoru [5] postoje sledeći tipovi arhitekturnih domena:
• Poslovna arhitektura: Struktura i ponašanje poslovnog sistema (ne nužno povezana sa
računarima). Pokriva poslovne ciljeve, poslovne funkcije ili sposobnosti, poslovne procese i
1U originalu je termin enterprise koji se koristi da označi svaku vrstu preduzeća (preduzimanja) koje za cilj ima ostvarivanje
profita/vrednosti, ali i da označi organizaciju uspostavljenu sa ciljem realizacije određene vrste preduzeća - kompaniju i sl.
uloge, itd. Poslovne funkcije i poslovni procesi se često mapiraju na aplikacije i podatke koji su
potrebni za njihovo ostvarivanje.
• Arhitektura podataka: Strukture podataka koje koristi poslovanje i/ili aplikacije poslovanja.
Opisi uskladištenih podataka i podataka u kretanju (podataka koji prolaze kroz tokove
podataka). Opisi skladišta podataka, grupa podataka i stavki podataka. Mapiranje tih
artifakata podataka na kvalitete, aplikacije, lokacije, itd.
• Arhitektura aplikacija: Struktura i ponašanje aplikacija koje se koriste u poslovanju. Pri tome
je fokus na načinu njihove međusobne interakcije, interakcije sa korisnicima, podataka koje
konzumiraju i proizvode, a ne na internoj strukturi aplikacija. Aplikacije se obično mapiraju na
poslovne funkcije i na tehnološke platforme.
• Arhitektura aplikacije/komponentna arhitektura: Interna struktura, modularizacija softvera
unutar aplikacije. To je softverska arhitektura najfinije granulacije. Obično je finija od nivoa
modularizacije koji definišu arhitekte rešenja. Ne može se postaviti rigidna granica između
arhitekture aplikacija i komponentne arhitekture.
• Tehnološka/tehnička/infrastrukturna arhitektura: Struktura i ponašanje IT infrastrukture.
Pokriva klijentske i serverske čvorove hardvera, infrastrukturne aplikacije koje se na tim
čvorovima izvršavaju, infrastrukturne servise koji se nude aplikacijama, protokole i mreže koje
povezuju aplikacije i čvorove.
Arhitektura informacionog sistema (Information System Architecture, ISA) bavi se reprezentacijom
strukture komponenti informacionog sistema, njihovim vezama, principima i direktivama sa
primarnim ciljem podrške poslovanju, odnosno funkcionisanju sistema na koji se informacioni sistem
odnosi. ISA obično razlikuje tri aspekta definišući tri "podarhitekture":
• Arhitekturu softvera koja objedinjuje domene arhitekture aplikacija i komponentne
arhitekture definišući softverske elemente informacionog sistema i načine njihovog
povezivanja.
• Arhitekturu podataka koja predstavlja glavne tipove i strukture podataka informacionog
sistema.
• Tehnološku arhitekturu koja definiše glavne tehnologije korišćene u implementaciji
softverske arhitekture i infrastrukturnih elemenata koji omogućuju okruženje za operativni
rad informacionog sistema.
Iako se, po preovlađujućem shvatanju, ne smatra sinonimom za arhitekturu informacionog sistema,
softverska arhitektura u velikoj meri obuhvata arhitekturu informacionog sistema.
Arhitektura softvera predstavlja strukture visokog nivoa softverskog sistema i disciplinu kreiranja
takvih struktura i sistema. Svaka struktura obuhvata softverske elemente, relacije među softverskim
elementima, svojstva softverskih elemenata i svojstva relacija među softverskim elementima.[2]
Oblasti koje su povezane sa arhitekturom softvera ima mnogo, počeviš i od načina opisivanja
softverske arhitekture, preko arhitekturalnih stilova i obrazaca u softveru, do uloge softverske
arhitekture u različitim periodima i pristupima razvoju softvera. Za nas su od posebnog interesa različiti
arhitekturalni stilovi i obrasci koji se danas koriste u razvoju softvera pa ćemo se njima u nastavku
detaljnije pozabaviti.
2.3. Arhitekturalni stilovi i obrasci softvera

Česta je praksa da se razvoju softvera pristupa bez jasno artikulisane odluke o modelu softverske
arhitekture koja će biti korišćena za aplikaciju. Danas se, najčešće, primenjuje obrazac de facto
standardne tradicionalne slojevite arhitekture (višeslojna arhitektura), ali na način koji ne uvažava
važne principe softverskog inženjerstva poput SOLID 2 principa. Razvoj se odvija kroz kreiranje
2U objektno-orijetnisanom programiranju, SOLID je mnemonički akronim za pet principa dizajna koji za cilj imaju da dizajn
softvera učine razumljivijim, fleksibilnijim i pogodnim za održavanje.
implicitnih slojeva razdvajanjem modula izvornog koda u pakete što, nažalost, vodi kolekciji modula
izvornog koda bez jasnih uloga, odgovornosti i međusobnih relacija. Da bi se utvrdile arhitekturalne
karakteristike ovakve “tvorevine” mora se ostvariti uvid u svake komponentu i modul sistema [3]. Bez
jasnog opredeljenja za arhitekturalni stil (pojedinačni ili kombinaciju više njih) aplikacije, praktično je
nemoguće odgovoriti na osnovna pitanja pri uvođenju u produkciju koja se odnose na skalabilnost
arhitekture, performanse aplikacije, pogodnost aplikacije za promene, karakteristike uvođenja
aplikacije u produkciju, responzivnost arhitekture.
Arhitekturalni stilovi i obrasci su nivo apstrakcije softvera koji pomažu da se definišu osnovne
karakteristike i ponašanje aplikacije. Neki arhitekturalni obrasci su pogodni za visoko sklabilne
aplikacije, drugi su prikladni za visoko agline aplikacije. Zbog toga je poznavanje arhitekturalnih
obrazaca (prednosti i nedostaci) izuzetno korisno za razvoj softvera. U nastavku ovoga odeljka biće
prikazani osnovni arhitekturalni stilovi savremenog softvera kako su izloženi u izvoru [3].
U nastavku ovoga odeljka prikazani su arhitekturalni stilovi koji se danas primenjuju. Opis je
strukturiran na sledećinačin: prvo su date osnovne karakteristike stila, zatim je data ilustracija njegove
primene na primeru iz realnog sveta, a na kraju su date specifične karakteristike arhitekture. Pri tome,
ove karakteristike su prikazane tabelom koja sadrži ocenu i analizu karakteristika ove arhitekture.
Ocena je za svaku karakteristiku bazirana na prirodnoj tendenciji arhitekture sagledanoj kroz
sposobnost baziranu na tipičnoj implementaciji obrasca, kao i na saznanjima o svojstvima po kojima
je arhitekturalni obrazac poznat.
2.3.1. Slojevita/višeslojna arhitektura

Vrlo blisko odgovara tradicionalnim organizacionim strukturama i strukturama IT komunikacije u
većini organizacija i zato predstavlja prirodan izbor za većinu poslovnih aplikacija.
Ovo je još uvek najčešće korišćen arhitekturalni obrazac. To je de facto standard za većinu Web
aplikacija bez obzira na korišćene (softverske) tehnologije.
Slojevita arhitektura organizuje komponente u horizontalne slojeve od kojih svaki sloj ima specifičnu
ulogu u aplikaciji. Iako sam obrazac ne specificira broj i tip slojeva, u većini slučajeva susrećemo se sa
četiri standardna sloja:
• Prezentacioni sloj koji je odgovoran za rukovanje kompletnim korisničkim interfejsom i
komunikacionom logikom baruzera.
• Sloj poslovne logike koji je odgovoran za izvršavanje specifičnih poslovnih pravila pridruženih
zahtevima.
• Sloj perzistencije koji je odgovoran za perzistiranje (memorisanje) stanja aplikacije u sistemu
za skladištenje podataka.
• Sloj baze podataka koji je odgovoran za pristup podacima u skladištima podataka.
Svaki sloj slojevite arhitekture ima specifičnu ulogu i odgovornost u okviru aplikacije i predstavlja
apstrakciju zadatka koji treba da se izvrši da bi se zadovoljio određeni informacioni zahtev. Na primer,
prezentacioni sloj ne treba da zna o načinu na koji će pribaviti podatke koje je dužan da prikaže, on će
te podatke da dobije (po pravilu, od poslovnog sloja) i samo treba da ih formatira/prikaže na zahtevani
način (na primer, šifra proizvoda biće prikazana u levom gornjem uglu ekrana, tekstom crvene boje).
Slično, poslovni sloj se ne bavi formatiranjem podataka niti vodi računa o tome odakle ti podaci dolaze;
on treba da dobije podatke od sloja perzistencije, da izvrši poslovnu logiku nad podacima (nešto
sračuna, na primer) i da te informacije prosledi prezentacionom sloju.
Jedno od najvažnijih pozitivnih svojstava višeslojne arhitekture je razdvajanje nadležnosti među
komponentama. Komponente koje pripadaju određenom sloju rade samo sa logikom koja odgovara
tom sloju. Na taj način obezbeđene su jasno klasifikovane komponente koje omogućuju izgradnju
efektivnih modela uloga i odgovornosti u okviru arhitekture i olakšavaju razvoj, testiranje, upravljanje
i održavanje aplikacija zbog dobro definisanih komponentnih interfejsa i ograničenih opsega
komponenti.
Na slici 1 [3] dat je šematski prikaz višeslojne arhitekture koji ističe jedan od ključnih koncepata
arhitekture slojeve izolacije (layers of isolation). Svi slojevi na slici 1 deklarisani su kao zatvoreni.
Zatvoren sloj znači da zahtev u svom kretanju od sloja do sloja mora da prođe kroz sloj koji je
neposredno ispod tekućeg sloja na kome je zahtev da bi dospeo do sloja koji je na nižem nivou,
odnosno da ne može da "preskače" slojeve.
Slika 1. Zatvoreni slojevi i putanja pristupa zahteva

Postavlja se pitanje zašto, na primer, ne omogućiti informacionim zahtevima direktan pristup sloju
perzistencije i sloju baze podataka, jer postoje situacije u kojima to može značajno da doprinese
podizanju performansi aplikacije. Odgovor na ovo pitanje je u važnom konceptu softverskog
inženjerstva koji se zove slojevi izolacije.
Primena koncepta slojeva izolacije obezbeđuje da izmene u jednom sloju arhitekture ne utiču na
komponente drugih slojeva, odnosno trebale bi da budu izolovane u tom jednom sloju i maksimalno
u još jednom povezanom sloju da bi se izbegle nepoželjne zavisnosti između komponenti i tesno
sprezanje koje je generalno nepoželjno u softveru.
Naravno, postoje i situacije u kojima ima smisla "otvoriti" određene slojeve. Jedan primer takve
situacije može da bude dodavanje deljenog servisnog sloja koji sadrži neke servisne komponente
namenjene, prvenstveno, komponentama sloja poslovne logike (n.pr. pomoćne klase za manipulisanje
stringovima, klase logovanja i sl.) koje su potrebne i nekim komponentama prezentacionog sloja.
Kreiranjem otvorenog sloja, pristup ovim komponentama iz drugih "gornjih" slojeva omogućava se bez
nepotrebnog prolaska kroz sloj poslovne logike. Time se dolazi do "čistije" arhitekture koja olakšava
upravljanje pristupom ovim zajedničkim servisnim komponentama. Šematski prikaz slojevite
arhitekture sa otvorenim slojem dat je na slici 2 [3].
Slika 2. Slojevita arhitektura sa otvorenim slojem
Koncept otvorenog i zatvorenog sloja pomaže da se definišu odnosi između arhitekturalnih slojeva i
tokova zahteva i daje dizajnerima informacije za razumevanje različitih ograničenja pristupa u okviru
arhitekture. Vrlo je važno dobro dokumentovati status pojedinih slojeva u odnosu na
otvorenost/zatvorenost i razloge za taj njihov status, jer se u protivnom dolazi do arhitektura koje je
vrlo teško testirati, uvesti u produkciju i održavati.
U nastavku sledi jednostavan ilustrativni primer primene obrasca.
Način funkcionisanja višeslojne arhitekture ilustrovan je na primeru informacionog zahteva za
pretraživanjem informacija o određenom pojedinačnom potrošaču (slika 4) [3]. Na ovoj slici crne
strelice prikazuju informacioni zahtev koji ide od prezentacionog sloja do sloja baze podataka koji će
da obezbedi potrebne podatke i, zatim, nazad do sloja prezentacije koji će ih prikazati. Informacije o
potrošaču u primeru sadrže, pored opštih podataka o potrošaču, i podatke o njegovim narudžbama.
Slika 4. Primer primene višeslojne arhitekture

Komponenta Customer screen je odgovorna za prihvatanje zahteva i prikaz informacija o potrošaču.
Ona ne zna gde se nalaze podaci niti kako se oni pretražuju. Kada primi zahtev za prikazivanjem
informacija, ova komponenta ga prosleđuje modulu Customer Delegate. Taj modul treba da zna koji
moduli u sloju poslovne logike mogu da obrade zahtev, kako da te module pribavi i koji podaci su tim
modulima potrebni (ugovor, contract).
Modul Customer Object u sloju poslovne logike odgovoran je za agregiranje svih informacija
potrebnih za zadovoljenje informacionog zahteva (u primeru pribavljanje informacija o korisniku i
njegovim narudžbama). Modul Customer Object poziva modul Customer dao (data access object) u
sloju perzistencije da pribavi podatke o potrošaču i modul Order dao da pribavi informacije o
narudžbama. Ta dva modula izvršavaju SQL naredbe iz sloja upravljanja podacima da bi našli podatke
u skladištu (bazi podataka) i prosleđuju podatke nazad modulu Customer Object u sloju poslovne
logike. Kada modul Customer Object primi te podatke, on ih agregira i šalje komponenti Customer
Delegate koja ih prosleđuje komponenti Customer Screen na prikazivanje.
Iz tehnološke perspektive se ovi moduli mogu implementirati na različite načine i korišćenjem različitih
platformi.
Na primer, za Java platformu komponenta Customer Screen može da bude (JSF) Java Server Faces
ekran spregnut sa modulom Customer Delegate kao menadžovanom bin komponentom. Modul
Customer Object u sloju poslovne logike može da bude lokalni Spring bin ili udaljeni EJB3 bin. Objekti
za pristup podacima (Customer dao i Order dao) mogu se implementirati kao jednostavni POJO-i (Plain
Old Java Objects), MyBatis XML Mapper fajlovi, ili čak objekti koji enkapsuliraju JDBC pozive ili
Hibernate upite.
Za Microsoft platformu, Customer Screen može biti ASP (active server pages) modul koji koristi .NET
framework za pristup C# modulima u poslovnom sloju, i modulima za pristup podacima
implementiranim kao ADO (ActiveX Data Objects).
2.3.1.1. Specifične karakteristike arhitekture
Iako je ovo arhitekturalni obrazac opšte namene, postoje dve njegove specifičnosti koje valja
razmotriti pre primene.
Prva specifičnost poznata je pod nazivom anti-obrazac ponora (architecture sinkhole anti-pattern).
Ona predstavlja situaciju u kojoj informacioni zahtevi samo prolaze kroz slojeve arhitekture sa
minimumom ili bez ikakve primene logike u pojedinim slojevima. Ovo nije redak slučaj - svaka
višeslojna arhitektura ima bar jedan scenario koji spada u ovaj antri-obrazac. Odluka o primenljivosti
obrasca obično se donosi na bazi pravila 80-20 (bar 80% informacionih zahteva su regularni,
maksimalno 20% njih su samo "protrčavanja" kroz slojeve). Ako je odnos obrnut, treba razmotriti
otvaranje pojedinih slojeva.
Druga specifičnost ove arhitekture je da ona ima tendenciju ka monolitnosti aplikacije, što može da
donese probleme pri uvođenju, robusnosti i pouzdanosti, performansi i sklabilnosti aplikacije.
Tabela 1 Evaluacija višeslojne arhitekture
Kriterijum Ocena Analiza/obrazloženje
Ukupn agilnost je sposbnost brze reakcije na stalno promenljivo okruženje. Iako se
Ukupna agilnost Nisko promene mogu izolovati putem slojeva izolacije, ipak je potrebno dosta truda i
vremena za uključivanje promena u ovu arhitekturu zbog monolitne prirode većine
implementacija i zbog tesne sprege komponenti obično prisutne u ovom obrascu.
U zavisnosti od implementacije obrasca, posebno za veće aplikacije, instaliranje
Lakoća instaliranja/uvođenja u Nisko može da postane problem. Mala promena u komponenti može da zahteva
rad reinstalaciju cele aplikacije. Zbog toga ova arhitektura nije pogodna za kontinualnu
isporuku.
Arhitektura je pogodna za testiranje zbog pripadnosti komponenti određenim
Pogodnost za testiranje Visoko slojevima jer se slojevi kojima ne pripadaju komponente mogu isključiti iz
testiranja u određenim situacijama.
Iako neke višeslojne arhitekture imaju dobre performanse, potreba prolazaka kroz
Performansa Nisko sve slojeve ih u opštem slučaju snižava.
Zbog trenda tesne sprege i monolitnosti u implementaciji, aplikacije oslonjene na
Skalabilnost Nisko ovu arhitekturu u opštem slučaju su teške za skaliranje. Višeslojna arhitektura se
može skalirati razbijanjem slojeva na odvojene fizičke instalacije ili repliciranjem
ukupne aplikacije na više čvorova ali je takva granularnost pregruba što skaliranje
čini skupim.
Visoka ocena ove karakteristike dolazi od široke primene obrasca, njegove
Lakoća razvoja Visoko relativne jednostavnosti za implementaciju i poklapanja sa organizacionom i
3
komunikacionom strukturom kompanija ( Conway’s Law ).
2.3.2. Događajem vođena arhitektura

Arhitekturalni obrazac zvani Događajem vođena arhitektura je popularni arhitekturalni obrazac
distribuirane asinhrone arhitekture koji se koristi za visoko sklabilne aplikacije.
Sama arhitektura se sastoji visoko raspregnutih, jedno-namenskih komponenti za obradu događaja
koje asinhrono primaju i obrađuju događaje.
Sastoji se od dve glavne topologije, medijatora i brokera.
Topologija medijatora se koristi kada je potrebno orkestrirati više koraka u okviru događaja putem
centralnog medijatora.
Topologija brokera se koristi kada je potrebno ulančati događaje bez korišćenja centralnog medijatora.
Arhitekturalne karakteristike i implementacione strategije su različite za dve topologije.
2.3.2.1. Medijatorska topologija
Medijatorska topologija ove arhitekture pogodna je za događaje koji se sastoje od više koraka i
zahtevaju određeni nivo orkestracije za obradu.
Primer može da bude događaj trgovine na berzi koji može da zahteva da se, prvo, validira trgovina,
zatim proveri usaglašenost te trgovine sa različitim pravilima, trgovina dodeli brokeru, sračuna
provizija i konačno obavi trgovina sa tim brokerom. Svi ti koraci zahtevaju određeni nivo orkestracije
da bi se odredili njihov redosled i mogućenost serijskog i paralelnog izvršavanja.
Postoje četiri glavna tipa arhitekturalnih komponenti u medijatorskoj topologiji:
•Red čekanja događaja. Tok događaja započinje tako što klijent šalje inicijalni događaj redu
čekanja koji transportuje događaj komponenti Medijator.
• Medijator događaja prima inicijalni događaj i orkestrira ga slanjem dodatnih asinhronih
događaja komponentama Kanali događaja da bi se izvršio svaki korak procesa.
• Kanal događaja prima događaj koji je rezultat orkestracije medijatora događaja, odnosno koji
su pripremljeni za obradu od strane obrađivača događaja.
• Obrađivač događaja osluškuju kanale događaja, prima događaj obrađen od strane medijatora
događaja i izvršavaju specifičnu poslovnu logiku kojom se događaj obrađuje.
Slika 5 [3] je vizuelna ilustracija generalne medijatorske topologije događajima vođenog
arhitekturalnog obrasca.
3
"organizacije koje dizajniraju sisteme ... ograničene su na pravljenje dizajna koji su kopije komunikacione strukture
tih organizacija." (https://en.wikipedia.org/wiki/Conway%27s_law)
Slika 5 Događajima vođena softverska arhitektura - generalna medijatorska topologija
Uobičajeno je da arhitektura vođena događajima ima od nekoliko desetina do nekoliko stotina redova
čekanja događaja. Obrazac ne specificira implementaciju komponente red čekanja, to može da bude
red poruka, krajnja tačka web servisa ili njihova kombinacija.
U obrascu postoje dva tipa događaja inicijalni događaj i događaj za obradu. Inicijalni događaj je
originalni događaj koji je primio medijator, a događaji za obradu su događaji koje je generisao
medijator (dekompozicijom originalnog događaja na korake) i koje su primile komponente za obradu
događaja.
Komponenta medijator je odgovorna za orkestriranje koraka koji su sadržani u inicijalnom događaju.
Za svaki korak u inicijalnom događaju medijator događaja šalje specifičan događaj obrade (processing
event) kanalu događaja. Taj događaj zatim preuzima i obrađuje obrađivač događaja. Dakle,
MEDIJATOR DOGAĐAJA SAM NE IZVRŠAVA POSLOVNU LOGIKU POTREBNU ZA OBRADU INICIJALNOG
DOGAĐAJA, već ZNA KORAKE POTREBNE ZA OBRADU INICIJALNOG DOGAĐAJA.
Kanale događaja koristi medijator događaja da obrađivačima događaja asinhrono prosleđuje
specifične događaje obrade koji se odnose na svaki korak u inicijalnom događaju. Kanali događaja
mogu da budu redovi poruka ili imenovani kanali poruka (message topics) koji se i najčešće koriste jer
omogućuju da se događaji obrade od strane više obrađivača događaja od kojih svaki radi drugačiju
obradu koja zavisi od primljenog specifičnog događaja obrade.
Komponente obrađivači događaja sadrže poslovnu logiku aplikacije potrebnu za obradu događaja.
Obrađivači događaja su samosadržane, nezavisne i visoko raspregnute arhitekturalne komponente
koje izvršavaju specifičan zadatak u aplikaciji ili sistemu.
Granularnost komponenti obrađivača događaja može biti različita: od vrlo fine (n.pr. sračunavanje
površine kvadrata) do grube (n.pr. obrada zahteva za osiguranje). Pri odlučivanju o ovom aspektu bitno
je da komponenta u potpunosti obavlja jedan poslovni zadatak, odnosno da za obavljanje tog
poslovnog zadatka ne zahteva da drugi obrađivači završe svoje specifične zadatke.
Medijator događaja može se implementirati na različite načine. Najjednostavniji i najčešći način je
putem habova otvorenog koda za integraciju kao što su Spring Integration
(https://spring.io/projects/spring-integration), Apache Camel (camel.apache.org), Mule ESB
(https://www.mulesoft.com/resources/esb/what-mule-esb). U ovim integracijama se tokovi
događaja obično implementiraju putem koda na nekom programskom jeziku kao što je Java koda, ili
DSL-a (domain-specific language). Za sofisticiraniju medijaciju može se koristiti BPEL 4 u sprezi sa BPEL
4
BPEL, Business Process Execution Language (https://en.wikipedia.org/wiki/Business_Process_Execution_Language) je standardizovan
XML-iki jezik koji opisuje podatke i korake potrebne za obradu inicijalnog događaja.
endžinom poput Apache ODE (http://ode.apache.org/). Za velike aplikacije koje zahtevaju
sofisticiraniju orkestraciju (moguće i korake koji uključuju ljudsku interakciju) medijator se može
implementirati korišćenjem alata za upravljanje poslovnim procesom poput jBPM
(https://www.jbpm.org/).
Sledeći primer (slika 6) ilustruje način funkcionisanja medijatorske topologije.
Slika 6 Ilustracija načina rada medijatorske topologije

Pretpostavimo da je neko osiguran kod neke osiguravajuće kuće i da želi da se preseli sa trenutne
adrese na kojoj živi.
U tom slučaju inicijalni događaj bi mogao da bude nešto što se zove relocation event.
Koraci koji su uključeni u obradu događaja relocation event sadržani su u medijatoru događaja. Za svaki
korak inicijalnog događaja, medijator događaja kreira događaj obrade (n.pr. change address, recalc
quote, itd.), šalje taj događaj obrade kanalu događaja i čeka da odgovarajući obrađivač događaja (n.pr.
customer process, quote process, itd.) taj događaj efektivno obradi.
Proces se nastavlja dok svi koraci inicijalnog događaja ne budu obrađeni. Zajednička strelica iznad
koraka recalc quote i update claims u medijatoru događaja znači da se ti koraci mogu izvršavati
istovremeno.
2.3.2.2. Brokerska topologija
Brokerska topologija se od medijatorske topologije razlikuje u tome što ne postoji centralni medijator
događaja, već je tok poruke distribuiran u maniru lanca po komponentama za obradu događaja
pomoću jednostavnog brokera poruka (n.pr., ActiveMQ, HornetQ, ...). Ova topologija je dobra kada je
u pitanju relativno jednostavan tok obrade događaja koji ne zahteva centralnu orkestraciju događaja.
Brokerska topologija ima dva glavna tipa arhitekturalnih komponenti, brokersku komponentu i
komponentu obrađivača događaja.
Brokerska komponenta može da bude centralizovana ili federalizovana i sadrži sve kanale događaja
koji se koriste u toku događaja. Kanali događaja mogu da budu redovi poruka, imenovani kanali poruka
ili kombinacija redova i imenovanih kanala.
Topologija je prikazana na slici 7.
Slika 7 Brokerska topologija događajima vođene softverske arhitekture
U ovom modelu nema centralne komponente koja kontroliše i orkestrira inicijalni događaj, već je svaka
obrađivačka komponenta odgovorna za obradu događaja i publikovanje novog događaja koji indicira
da je akcija upravo izvršena.
Na primer, obrađivač događaja koji balansira portfolio deonica može da primi inicijalni događaj zvani
stock split. Na bazai tog inicijalnog događaja, obrađivač događaja može da uradi neki rebalans
portfolija i da, zatim, brokeru publikuje novi događaj koji se zove rebalance portfolio koji bi tada
preuzeo neki drugi obrađivač događaja. Valja zapaziti da ovde mogu da se pojave vremenski periodi
u kojima je događaj publikovan od strane nekog obrađivača ali nije preuzet od strane drugog
obrađivača. To je uobičajena situacija kada se aplikacija evoluira ili se obezbeđuju uslovi za buduće
funkcionalnosti ili proširenja.
Način rada brokerske topologije biće ilustrovan na istom primeru kao i za medijatorsku topologiju
(osiguranik koji menja adresu). Grafička ilustracija je na slici 8.
Kako nema centralne medijatorske komponente da primi inicijalni događaj, komponenta Customer
Process direktno prima događaj, menja adresu osigunarnika i izdaje događaj koji kaže da je ona
izmenula adresu osiguranika (n.pr., change address događaj).
U ovom primaru su dva obrađivača događaja koje zanima događaj change address: Quote Process i
Claims Process.
Komponenta Quote Process preračunava nove rate osiguranja na bazi promene adrese i publikuje
ostatku sistema događaj koji kaže šta je ona uradila (n.pr., recalc quote događaj). Komponenta Claims
Process prima isti događaj change address, ali u tom slučaju ažurira vanredni zahtev za osiguranje i
sistemu publikuje događaj
update claim. Ove nove događaje zatim preuzimaju obrađivačke komponente i lanac događaja se
nastavlja sve dok ima neobrađenih publikovanih događaja za taj određeni inicijalni događaj.
Slika 8 Ilustracija rada brokerske topologije
2.3.2.3. Specifične karakteristike arhitekture
Događajima vođena arhitektura je relativno složena za implementaciju, pre svega zbog asinhrone
distribuirane prirode.
Pri implementaciji se mora voditi računa o različitim pitanjima distribuirane arhitekture poput
raspoloživosti udaljenih procesa, odsustva responsivnosti, i logike rekonekcije brokera u slučaju otkaza
brokera ili medijatora.
Jedna od stvari koju treba uzeti u razmatranje pri izboru ovog arhitekturalnog obrasca je nedostatak
atomičkih transakcija za pojedinačni poslovni proces. Zbog visoke raspregnutosti i distribuiranosti
obrađivačkih komponenti veoma je teško održavati transakcije nad njima i mora se voditi računa da
se nedeljive transakcije ne distribuiraju na odvojene obrađivače.
Konačno, možda i najteži aspekt ove arhitekture je kreiranje, održavanje i upravljanje ugovorom
obrađivačke komponente. Svaki događaj obično ima specifičan pridruženi ugovor (ugovor sadrži
vrednosti i format podataka koji se prosleđuje obrađivaču događaja) pa je od vitalne važnosti usvajanje
standarda formata podataka (n.pr. XML, JSON, Java Object, itd.) i uspostavljanje prava politike
verzioniranja ugovora od samog početka.
Tabela 2 sadrži ocenu i analizu karakteristika ove arhitekture.
Tabela 2 Evaluacija arhitekture vođene događajima
Kako je svaka komponenta za obradu procesa jedno-namenska i potpuno
Ukupna agilnost Visoko raspregnuta od drugih komponenti za obradu procesa, promene su generalno
izolovane ja jednu ili mali broj procesorskih komponenti te se mogu brzo realizovati
bez uticaja na druge komponente.
Ukupan obrazac je relativno lako instalirati zbog raspregnute prirode komponenti
Lakoća instaliranja/uvođenja u Visoko za obradu procesa. Lakše je instalirati brokersku topologiju od medijatorske zbog
rad tešnje povezanosti medijatorske komponente sa procesorima događaja što,
generalno, zahteva da se pri promenama zahteva instaliranje i procesorske i
medijatorske komponente.
Testiranje individualnih jedinica nije preterano teško, ali zahteva neku vrstu
Pogodnost za testiranje Nisko specijalizovanog testnog klijenta/alata za generisanje događaja. I asinhrona
priroda arhitekture doprinosi usložnjavanju testiranja.
Iako infrastruktura poruka doprinosi smanjenju performanse, asinhronost
Performansa Visoko doprinosi njenom povećanju, odnosno pokazuje se da asinhrone operacije
amortizuju cenu rukovanja porukama.
Skalabilnost je prirodna odlika ove arhitekture koja proističe iz visoko raspregnutih
Skalabilnost Visoko procesora događaja. Svaki procesor događaja može nezavisno da skalira čime se
doprinosi fino granulisanoj sklabilnosti.
Razvoj može da bude dosta komplikovan zbog asinhrone pririode obrasca,
Lakoća razvoja Nisko kreiranja ugovora i naprednijeg rukovanja greškama u okviru koda za
neresponzivne procesore događaja i brokere u otkazu.
2.3.3. Arhitektura mikrojezgra

Arhitekturalni obrazac mikro-jezgra (Microkernel, Plug-in) je prirodan obrazac za implementaciju
produktno-baziranih aplikacija 5.
Arhitekturalni obrazac mikro-jezgra omogućuje da se jezgru aplikacije dodaju funkcionalnosti u obliku
plug-in komponenti što obezbeđuje proširivost, separaciju i izolaciju funkcionalnosti.
Grafički prikaz osnovne arhitekture mikro-jezgra je na slici 8.
Mikrokernel arhitektura ima dva tipa arhitekturalnih komponenti, jezgro sistema (core system) i plug-
in moduli. Logika aplikacije je podeljena između nezavisnih plug-in modula i osnovnog sistema jezgra
što je pogodno za proširivanje, obezbeđuje fleksibilnost i izolovanje funkcionalnosti aplikacije, kao i
prilagođavanje logike obrade.
Jezgro arhitekture mikro-jezgra tradicionalano sadrži samo minimum zahtevane funkcionalnosti koji
je potreban da bi sistem bio operativan. Iz perspektive poslovnih aplikacija, jezgro sistema se često
definiše kao opšta poslovna logika bez prilagođenog koda za specijalne slučajeve, specijalna pravila ili
složene uslovne obrade.
Plug-in moduli su samostalne, nezavisne komponente koje sadrže specijalizovane dodatne procesne
funkcionalnosti i prilagođeni kod namenjen unapređenju ili proširenju funkcionalnosti jezgra
dodatnim mogućnostima. Iako plug-in komponente u realnim uslovima ne mogu da budu potpuno
nezavisne, treba ih učiniti što nezavisnijim i izbegavati njihovu komunikaciju jer se time smanjuju i
problemi zavisnosti.
Slika 8. Arhitektura mikro-jezgra
Jezgro sistema treba da zna koji su plug-in moduli raspoloživi i kako da ih dobije. Uobičajeni način
implementacije ovoga zahteva je neka vrsta registra plug-in komponenti. Registar sadrži informacije o
svakom plug-in modulu (n.pr. ime, ugovor o podacima, detalji protokola za udaljeni pristup u zavisnosti
od načina povezivanja plug-in modula sa jezgrom sistema). Na primer, plug-in za poreski softver koji
5
Produktno-bazirana aplikacija je aplikacija koja je paketirana i stavljena na raspolaganje za preuzimanje u verzijama kao tipičan proizvod
treće strane, ali se i interni softveri često razvijaju i objavljuju kao softverski proizvodi sa verzijama i funkcionalnostima u obliku plug-in
komponenti.
označava visoko rizične poreske stavke može da ima zapis u registru koji sadrži ime servisa
(AuditChecker), ugovor o podacima (ulazni podaci i izlazni podaci) i dogovoreni format (XML). Može
da sadrži i WSDL (Web Services Definition Language) ako se plug-in-u pristupa putem protokola SOAP.
Plug-in moduli mogu se povezati na jezgro različitim načinima kao što su OSGi (Open Service Gateway
Initiative), poruke, web servisi, ili čak direktno putem point-to-point vezivanja (t.j., instanciranja
objekta). Obrazac ne specificira tip konekcije, on samo specificira da plug-in moduli moraju da budu
nezavisni jedan od drugog.
Kontrakti između plug-in modula i jezgra sistema mogu da variraju od standardnih do prilagođenih.
Prilagođeni kontrakti javljaju se u situacijama kada plug-in komponente razvija treća strana gde nema
kontrole nad kontraktom koji plug-in koristi. U takvim slučajevima se obično kreira adapter između
dva kontrakta tako da jezgru ne treba specijalizovani kod za svaki plug-in. Kda se kreira standardan
kontrakt (obično implementacijom putem XML-a ili Java Map-a) važno je kreirati strategiju
verzioniranja od samog početka.
Ono što je posebna prednost arhitekture mikro-jezgra je što se ona može ugrađivati ili koristiti kao
deo drugih arhitekturalnih obrazaca. Na primer može se koristiti višeslojni obrazac a mikroservisni
obrazac može da se iskoristi na nekom sloju, ili se može iskoristiti za implementaciju obrađivača
događaja u okviru obrasca arhitekture vođene događajima. Mikroservisna arhitektura je, takođe,
izuzetno pogodna za evolutivni i inkrementalni pristup razvoju softvera.
Richards [3] kaže da je, možda i najbolji, primer uspešne primene ove arhitekture Eclipse IDE
(https://www.eclipse.org/). Slika 9 prikazuje arhitekturu platforme Eclipse.
Slika 9 Arhitektura Eclipse IDE

Osnovni Eclipse paket obezbeđuje samo bazičnu platformsku infrastrukturu koja ne uključuje nikakav
korisnički interfejs. Sastoji se iz sledećih generičkih komponenti:
• org.eclipse.core.contenttype - Podrška za definisanje i upravljanje tipovima sadržaja fajlova.
• org.eclipse.core.expressions - Generički, XML-bazirani jezik izraza koji se koriste za markiranje
različitih tačaka proširenja.
• org.eclipse.core.filesystem - API generičkog fajl-sistema.
• org.eclipse.core.jobs - Infrastruktura za konkurentno programiranje u okruženju Eclipse.
• org.eclipse.core.resources - Upravljanje resursima - projekti, folderi i fajlovi.
• org.eclipse.core.runtime - Podrška za izvršnu platformu, osnovne pomoćne metode i registar
proširenja.
Puna funkcionalnost se dobija tek dodavanjem odgovarajućih plug-in komponenti.
Drugi dobar primer, prema istom izvoru, su Internet brauzeri koji, takođe, mogu da imaju različite
plug-in komponente specijalizovanih pregledača i sl. kojih nema u osnovnoj verziji brauzera (jezgru).
Konačno, pokazaćemo i poslovnu aplikaciju u kojoj primena obrasca mikro-jezgra ima svoje
opravdanje. Primer je, opet, situacija sa osiguranjem kuće/stana koja je već korišćena za ilustrovanje
prethodno prikazanih arhitekturalnih obrazaca.
Obrada zahteva osiguranja je veoma složen proces. Svaka država ima različita pravila koja se odnose
na to šta je obuhvaćeno osiguranjem, a šta nije. To stvara ogroman broj uslova u standardnoj obradi
zahteva. Monolitna aplikacija za obradu tih zahteva nije dobro rešenje jer vodi ka veoma složenom
sistemu u kome promena jednog pravila može da zahteva ozbiljne analize i intervencije da bi se održala
konzistentnost. Korišćenje arhitekture mirko-jezgra može značajno da olakša situaciju. Slika 10
ilustruje ideju primene arhitekture mikro-jezgra u ovoj situaciji. Grafički simbol naslaganih foldera
ovde predstavlja osnovna poslovna pravila koja primenjuje osiguravajuća kuća u obradi zahteva u
kome nema specifične, prilagođene obrade. Svaki plug-in modul sadrži specifična pravila koja se
primenjuju u određenoj državi. Sa ovakvom arhitekturom lako je dodavati nova specifična pravila ili
menjati postojeća, a da to ne utiče na poslovnu logiku iskazanu u drugim plug-in modulima.
Slika 10. Ilustracija primene arhitekture mikro-jezgra sa posebnim plug-in komponentama za

specifične poslovne logike
Tabela 3 Evaluacija arhitekture mikro-jezgra
Ukupna agilnost Visoko Promene se mogu dobro izolovati i brzo implementirati

putem slabo spregnutih plug-in modula. Takođe, poznato je
iz prakse da se samo jezgro arhitekture mikro-jezgra
relativno brzo stabilizuje i ne zahteva česte promene.
Lakoća instaliranja/uvođenja u Visoko U zavisnosti od načina implementacije obrasca, plug-in
rad moduli se mogu dinamički dodavati jezgru u vreme izvršenja
čime se smanjuje gubitak vremena pri instalaciji.
Pogodnost za testiranje Visoko Plug-in moduli mogu se izolovano testirati i lako simulirati
(mock objekti) od strane jezgra radi demonstriranja
određene funkcionalnosti a da se, pri tome, izmene jezgra
svedu na minimum, ili da ih uopšte i ne bude.
Performansa Visoko Iako se sam obrazac mikro-jezgra ne odlikuje visokom
performansom, većina aplikacija koje koriste ovaj obrazac
pokazuju odlike dobrih performansi. Razlog je što se
aplikacije mogu konfigurisati tako da se uključe samo one
funkcionalnosti koje su zaista potrebne. Dobar primer za to
je JBoss Application Server.
Skalabilnost Nisko Kako je većina implementacija arhitekture mikro-jezgra

produktno bazirana i generalno manje veličine, one su
implementirane kao pojedinačne jedinice i zbog toga nisu
visoko skalabilne. Skalabilnost se može obezbediti na nivou
funkcionalnosti plug-in modula ukoliko su plug-in moduli
adekvatno implementirani. Opšte je mišljenje da ovaj
obrazac ne rezultuje visoko skalabilnim aplikacijama.
Lakoća razvoja Nisko Arhitektura mikro-jezgra nije jednostavna za razvoj iz više
razloga. Među njima su upravljanje kontraktima
(verzioniranje), interni plug-in registri, granularnost plug-in
komponenti, širok repertoar konektivnosti plug-in
komponenti.
2.3.4. Mikroservisna arhitektura

Arhitektura pod nazivom Mikroservisna arhitektura je trenutno vrlo aktuelna tema u oblasti jer se
smatra validnom alternativom monolitnim aplikacijama i servisno-orijentisanim arhitekturama koje
danas dominiraju u softveru.
Vrlo sažeto, mikroservisni arhitekturalni stil je pristup razvoju pojedinačne aplikacije u obliku skupa
malih servisa od kojih se svaki izvršava u svom posebnom procesu i komunicira putem
laganih/jednostavnih mehanizama, često API-a HTTP resursa. Ovi servisi izgrađuju se oko poslovnih
funkcija (business capabilities 6) i nezavisno se instaliraju pomoću potpuno automatizovanog postupka
za instaliranje. Postoji minimum centralizovanog upravljanja ovim servisima koji mogu da budu
napisani u različitim programskim jezicima i mogu da koriste različite tehnologije skladištenja.
Kako ovaj arhitekturalni obrazac još uvek evoluira, ima i dosta konfuzije u tumačenjima šta obrazac
zapravo jeste i kako se implementira. Ovde će biti nabrojane i vrlo sažeto opisane karakteristike od
kojih se većna očekuje u većini arhitektura ovog stila.
Te karakteristike mikroservisne arhitekture prema [4] su sledeće.
1. Komponentizacija putem servisa. Uz pretpostavku da je softverska komponenta jedinica
softvera koja se pojedinačno može zamenjivati i nadograđivati [4], osnovni mehanizam
mikroservisne arhitekture za komponentizaciju je razbijanje aplikacije na servise. Servis je
vanprocesna komponenta (za razliku od biblioteka koje predstavljaju unutarprocesne
komponente) koja komunicira mehanizmima kao što su zahtevi web servisa ili udaljeni pozivi.
Osnovni razlog za korišćenje servisa kao komponeti je što se servisi mogu nezavisno
instalirati. Drugi razlog je eksplicitniji interfejs komponente što se postiže korišćenjem
eksplicitnih mehanizama udaljenog poziva. Iako na osnovu do sada rečenog može da se
zaključi da se servisi mapiraju na izvršne procese, oni mogu da se sastoje i od više procesa koji
se uvek razvijaju i instaliraju zajedno (na primer, aplikacioni proces i baza podataka koje koristi
samo taj servis).
2. Organizacija oko poslovnih funkcija. Za razliku od, na primer, višeslojne arhitekture gde se
aplikacija dekomponuje po izolovanim slojevima (n.pr. korisnički interfejs, poslovna logika,
upravljanje podacima) koji se svi koriste za obezbeđenje konkretnog informacionog zahteva
poslovne funkcije, mikroservisna arhitektura promoviše dekompoziciju po servisima
organizovanim oko poslovnih funkcija tako da servis sadrži sve što je potrebno da se zadovolje
informacioni zahtevi poslovne funkcije (korisnički interfejs, poslovna logika, podaci).
6
Business capability je izraz artikulacije kapaciteta, materijala i ekspertize koje orgnizaciji trebaju da bi obavljala svoje osnovne funkcije
(https://searchmicroservices.techtarget.com/definition/business-capability)
3. Proizvodi, ne projekti. Za razliku od konvencionalnog pristupa koji zagovara projektni model
(cilj je da se isporuči komad softvera koji se smatra završenim i da se preda drugoj organizaciji
na održavanje), mikroservisna arhitektura zastupa princip Amazon-a - "you build, you run it" 7.
4. Pametne krajnje tačke, jednostavna komunikacija. Mikroservisna arhitektura zagovara
mehnizam koji složenu logiku komunikacije prebacuje na krajnje tačke koje imaju sopstvenu
domensku logiku i deluju kao filtri u klasičnom Unix smislu: primaju zahtev, primenjuju logiku
na odgovarajući način i proizvode odgovor. Proces se uređuje korišćenjem jednostavnih REST
protokola 8 bez centralizacije. Dva najčešće korišćena protokola su HTTP zahtev-odgovor sa
API-ma resursa i jednostavna razmena poruka (lightweight messaging). Koriste se principi i
protokoli na kojima je izgrađen web. Drugi uobičajeni pristup je razmena poruka preko
jednostavne magistrale. Uloga infrastrukture koja se koristi je pouzdano rutiranje asinhronih
poruka (implementacije poput RabbitMQ ili ZeroMQ) a logika/inteligencija je u servisima koji
proizvode i konzumiraju poruke.
5. Decentralizovano upravljanje programskom podrškom. Razbijanje komponenti monolita na
servise pruža mogućnost izbora načina implementacije svakog servisa. To se odnosi na izbor
programskog jezika, izbor načina i sistema za upravljanje podacima (različiti modeli podataka,
različiti sistemi za upravljanje bazama podataka), itd. Menja se i pristup standardima. Umesto
krutog pridržavanja propisanih standarda, otvara se mogućnost njihove kreativne primene
kroz razvoj dobre prakse koja proističe iz uspešnih implementacija i, posebno, još šire primene
pristupa otvorenog koda. Vredno je pomenuti i kulturu "tolerancije" prema kontraktima
servisa koja zagovara maksimalnu toleranciju pri čitanju podataka od servisa - uzimati samo
potrebne elemente podataka, ignorisati sve što nije neophodno, praviti minimalne
pretpostavke o strukturi.
6. Decentralizovano upravljanje podacima. Decentralizacija upravljanja podacima, posebno

izražena u mikroservisnoj arhitekturi, javlja se u različitim oblicima.
Na najapstraktnijem nivou to znači da se konceptualni model sveta razlikuje među sistemima
počevši od različitih entiteta, preko različitih atributa istih entiteta, do zajedničkih atributa sa
suptilno različitim značenjem. Ta situacija je uobičajena među razdvojenim aplikacijama ali
može da se desi i unutar jedne aplikacije posebno kada je aplikacija razdeljena na odvojene
komponente. Mikroservisna arhitektura decentralizuje odluke o konceptualnim modelima
putem primene pojma ograničeni kontekst (Bounded Context) koji potiče iz domenom
vođenog dizajna (Domain-Driven Design, DDD). Koncept ograničenog konteksta deli složeni
domen u više ograničenih konteksta i uspostavlja relacije među njima. Zgodno ga je
primenjivati u mikroservisnoj arhitekturi, jer postoji prirodna korespondencija između servisa
i granica konteksta.
Pored decentralizacije odluka o konceptualnim modelima, mikroservisna arhitektura
decentralizuje i odluke o skladištenju podataka. Za razliku od monolitnih aplikacija koje
preferiraju JEDNU LOGIČKU BAZU PODATAKA ZA ŠIROK OPSEG APLIKACIJA, mikroservisna
arhitektura zagovara POSEBNU BAZU PODATAKA ZA SVAKI SERVIS. To mogu da budu različite
instance iste tehnologije ili potpuno različiti sistemi baza podataka zvani poliglotska
perzistencija (Polyglot Persistence).
Decentralizacija odgovornosti za podatke postavlja ključno pitanje konzistentnosti podataka.
Ovaj zadatak se u mikroservisnoj arhitekturi rešava na način potpuno različiti od
tradicionalnog pristupa baziranog na transakcijama. Mikroservisne arhitekture naglašavaju
7
Princip koji zagovara da razvojni tim preuzima punu odgovornost za softver u produkciji.
8
Representational State Transfer (REST) je softverski arhitekturalni stil koji definiše skup ograničenja za kreiranje web servisa
(RESTfull web servisi). Ovi servisi dozvoljavaju zahtevanje i manipulisanje tekstualnim reprezentacijama web resursa korišćenjem
predefinisanog skupa operacija bez stanja. Protokol bez stanja je komunikacioni protokol u kome pošiljalac/primalac ne čuvaju
informaciju jedan od rugom što znači da nisu svesni stanja druge strane.
beztransakcionu koordinaciju među servisima sa eksplicitno artikulisanim stavom da
konzistentnost može da se ostvari samo u konačnom, uz tolerisanje određenog nivoa
nekonzistentnosti do konačnog trenutka koja se otklanja reverznim procesom.
7. Automatizacija infrastrukture. Tehnike automatizacije infrastrukture, koje su doživele
eksplozivan razvoj poslednjih godina, smanjili su operativnu složenost izgradnje, instaliranja i
korišćenja mikroservisa. Tome su posebno doprinele tehnike automatizovane infrastrukture
koje se koriste za kontinualnu isporuku softvera kako je prikazano na slici 11.
Slika 11 Kontinualna isporuka softvera

Ključna stvar za mikroservinu arhitekturu u ovom procesu je automatizovano testiranje kojim
se proverava ispravnost rada softvera. Pomeranjem testiranog softvera duž toka kontinualne
isporuke postiže se automatizovana instalacija za svako novo okruženje.
Druga oblast u kojoj se korišćenje automatizacije pokazuje kao izuzetno korisno je upravljanje
mikroservisima u produkciji gde tehnike kontinualne isporuke značajno doprinose održavanju
i unapređenju servisa.
8. Dizajn za otkaz. Posledica korišćenja servisa kao komponenti je da aplikacije treba dizajnirati
tako da budu tolerantne na otkaz servisa. Svaki poziv servisa može da otkaže zbog
neraspoloživosti i klijent treba na takvu situaciju da reaguje na prikladan način, odnosno na
način koji će se uklopiti u normative standardnog korisničkog iskustva. Da bi se to postiglo,
potrebno je sprovoditi kontinualni monitoring i logovanje, odnosno neku vrstu automatskog
testiranja u produkciji. Važno je brzo otkrivanje otkaza i automatsko restaurisanje servisa a,
po mogućstvu, i predikcija otkaza i preventivno delovanje. Da bi se obezbedili uslovi za brzo
otkrivanje otkaza i restauraciju servisa, potrebno je razvijati relevantne metrike i pomoćne
alate za praćenje statusa servisa, protoka i kašnjenja.
9. Evolutivni dizajn. Većina onih koji primenjuju mikroservisnu arhitekturu dolaze iz miljea
evolutivnog dizajna softvera i servisnu dekompoziciju vide kao sredstvo za kontorolu promena
u aplikacijama koje će omogućiti česte, brze i dobro kontrolisane promene softvera. Ključno
svojstvo komponente koje opravdava ovakav stav je nezavisna zamena i nadogradnja. Prisutan
je i stav da brzina promena servisa može da bude dobar kriterijum za njihovo definisanje,
odnosno spajanje. Takođe, čini se da mikroservisna arhitektura ima kapacitet za planiranje
finije granulacije i ubrzavanje izdavanja verzija softvera. Konačno, stav je da princip tolerancije
koji je prethodno pomenut treba da se iskoristi za izbegavanje verzioniranja 9 tako što će se
servisi dizajnirati da budu maksimalno tolerantni na promene onih koji ih obezbeđuju.
Iz prethodnog izlaganja može se zaključiti da se, bez obzira na topologiju ili stil implementacije, ovaj
arhitekturalni obrazac oslanja na sledeća tri ključna koncepta.
• Prvi i, verovatno, najvažniji koncept ove arhitekture je koncept servisne komponente koja
može da varira po granularnosti od jednog modula do velikog dela aplikacije. Dizajniranje
9
Mikroservisna arhitektura zagovara integraciju koja verzioniranje koristi samo kada nema drugog rešenja.
(https://martinfowler.com/articles/enterpriseREST.html#versioning)
dobre granularnosti servisne komponente je jedan od ključnih izazova mikroservisne
arhitekture.
• Drugi važan koncept je pojam odvojena instalacija (separately deployed units). To znači da se
svaka komponenta mikroservisne arhitekture instalira kao odvojena jedinica čime se doprinosi
lakšoj instalaciji, povećanoj skalabilnosti, i većem rasprezanju komponente i aplikacije.
• Treći koncept je distribuiranost arhitekture što znači da su sve komponente raspregnute i da
im se pristupa nekim protokolom za udaljeni pristup (n.pr., REST, SOAP, RMI, itd.).
Slika 12 je ilustracija osnovnog obrasca mikroservisne arhitekture.
Slika 12 Osnovni obrazac mikroservisne arhitekture

Mikroservisna arhitektura je rešenje koje je nastalo kao rezultat nastojanja da se reše postojeći praktični
problemi monolitnih aplikacija slojevite arhitekture i distribuiranih aplikacija servisno-orijentisane
arhitekture. Pri tome, problemi monolitnih aplikacija se odnose na tesnu spregu komponenti koja usporava
kontinualnu isporuku, a problemi sevisno-orijentisane arhitekture se odnose na njenu preveliku složenost.
2.3.4.1. Topologije mikroservisne arhitekture

Iako postoje bukvalno desetine načina za implementaciju mikroservisnog obrasca, kao najuobičajenije i
najpopularnije danas se izdvajaju tri topologije:
• API REST-bazirana topologija,
• Aplikaciono REST-bazirana topologija, i
• Topologija centralizovanih poruka
API REST-bazirana topologija pogodna je za web sajtove koji izlažu male, samosadržane pojedinačne
servise putem nekog API-a. Šematski prikaz topologije dat je na slici 13. Arhitektura se sastoji od servisnih
komponenti vrlo fine granulacije (obično sadrže jedan do dva modula) koje izvršavaju specfične poslovne
funkcije nezavisne od ostalih servisa. Komponentama se pristupa korišćenjem REST-baziranog interfejsa
implementiranog putem odvojenog web-baziranog API sloja. Primeri su neki od pojedinačnih,
jednonamenskih, klaud-baziranih web servisa koje nude Yahoo, Google i Amazon.
Slika 13 API REST-bazirana topologija
Druga topologija, zvana aplikaciono-REST bazirana topologija (ili samo REST-bazirana topologija),
karakteristična je po tome što se klijentski zahtevi ne primaju putem posebnog API sloja, nego putem
ekranskih formi (korisničkog interfejsa) tradicionalnih web-baziranih aplikacija ili aplikacija debelih klijenata
(fat-client). Šema arhitekture prikazana je na slici 14.
Slika 14 REST-bazirana topologija

Ovde je sloj korisničkog interfejsa aplikacije instaliran kao posebna web aplikacija koja udaljeno pristupa
odvojeno instaliranim servisnim komponentama (poslovna funkcionalnost) kroz jednostavne REST-
bazirane interfejse.
Servisne komponente ove topologije razlikuju se od komponenti API-REST-bazirane topologije po tome što
su veće, grublje granulacije i predstavljaju male delove ukupne poslovne aplikacije, a ne fino granulisane
servise pojedinačnih akcija. Topologija je pogodna za male i srednje poslovne aplikacije koje su nižeg nivoa
složenosti.
Teća uobičajena topologija javlja se u većim poslovnim aplikacijama koje zahtevaju sofisticiraniju kontrolu
na transportnom sloju između korisničkog interfejsa i servisnih komponenti. Naziva se topologija
centralizovanih poruka (centralized messaging topology) i prikazana je šematski na slici 15.
Slika 15 Topologija bazirana na centralizovanoj razmeni poruka
Slična je REST-baziranoj topologiji od koje se razlikuje po tome što za udaljeni pristup koristi jednostavni
broker poruka (n.pr., ActiveMQ, HornetQ, itd.) umesto REST-a. Pri tome je vrlo važno zapaziti da broker
poruka u ovoj topologiji ne vrši nikakvu orkestraciju, transformaciju ili složeno rutiranje kao što je to slučaj
obrasca servisno orijentisane arhitekture, već predstavlja samo jednostavan transport za pristup udaljenim
servisnim komponentama.
Prednost ove topologije nad jednostavnom REST-baziranom topologijom leži u naprednim mehanizmima
redova čekanja, razmeni asinhronih poruka, upravljanju greškama i boljoj ukupnoj sklabilnosti i
balansiranju opterećenja.
Pitanja jedinstvene tačke otkaza i uskog grla ove arhitekture, koja se obično povezuju sa centralizovanim
brokerom, rešavaju se klasterovanjem/federiranjem brokera (razbijanje jedne instance brokera na više
brokerskih instanci) na način da se razdeli protok poruka po funkcionalnim oblastima sistema.
2.3.4.2. Izbegavanje zavisnosti i orkestracije

Jedan od osnovnih problema mikroservisnog arhitekturalnog obrasca je određivanje korektnog nivoa
granularnosti servisnih komponenti.
Komponente pregrube granularnosti imaju za posledicu gubitke na skalabilnosti, pogodnosti testiranja i
slabog sprezanja. Komponente prefine granularnosti vode ka potrebi orkestracije servisa što se smatra
jednim, moguće i najvećim problemom praktične primene servisno-orijentisane arhitekture koji
mikroservisna arhitektura nastoji da reši.
Ako se pojavi potreba da se servisne komponente orkestriraju iz korisničkog interfejsa ili API sloja, u pitanju
su komponente sa prefinom granulacijom. Pojava potrebe za međuservisnom komunikacijom pri obradi
jednostavnog pojedinačnog zahteva takođe ukazuje da su u pitanju komponente sa prefinom granulacijom
ili da komponente nisu dobro određene u odnosu na poslovnu funkcionalnost.
Međuservisna komunikacija, koja sama može pisilno da dovede do neželjenog sprezanja komponenti,
može se rešavati putem deljene baze podataka. Na primer, servisna komponenta koja rukuju Internet
narudžbama i zahteva informacije o kupcu može u bazi potražiti potrebne podatke, umesto da poziva
funkcionalnost druge servisne komponente koja rukuje kupcima. Na ovaj način rešava se samo deo
problema - deljeni podaci. Drugi deo problema je deljena funkcionalnost - jedna servisna komponenta
zahteva funkcionalnost sadržanu u drugoj servisnoj komponenti. Ovaj problem se u praksi najčešće rešava
kopiranjem deljene funkcionalnosti u više servisnih komponenti (iako se time narušava princip don’t repeat
yourself), odnosno pravljenjem malih pomoćnih klasa.
Ukoliko se orkestriranje komponenti ne može ni na koji način izbeći, to je pouzdan znak da mikroservisni
obrazac nije dobro rešenje za posmatrani problem. Naime, distribuirana priroda ovoga obrasca čini
praktično nemogućim održavanje transakcione jedinice po/među servisnim komponentama.
Obrazac mikroservisne arhitekture odlikuje se sledećim dobrim osobinama:
• Aplikacijama sa većom robusnošću, boljom skalabilnošću, boljom podrškom kontinualnoj isporuci
softvera.
• Mogućnošću instaliranja u realnom vremenu što znači i kontinualnu raspoloživost. Ako je u pitanju
jedna servisna komponenta, može se napisati specijalizovani kod u korisničkom interfejsu koji
detektuje aktivnu instalaciju i redirektuje korisnika na stranicu greške ili stranicu čekanja.
Alternativno, može se izvršiti uzajamna zamena komponenti (in, out) u toku instalacije u realnom
vremenu što omogućuje kontinualnu raspoloživost u toku ciklusa instalacije (ovo je, praktično,
nemoguće sa višeslojnom arhitekturom).
Naravno, ima i karakteristika ove arhitekture koje nisu baš najbolje. U stvari, kako je mikroservisni
arhitekturalni obrazac distribuirana arhitektura, on ima iste složene probleme kao i događajima-vođen
arhitekturalni obrazac. Tu spadaju kreiranje, održavanje i upravljanje kontraktima, raspoloživost udaljenog
sistema, autentikacija i autorizacija udaljenog pristupa.
Tabela 4 Evaluacija mikroservisne arhitekture
Zbog jedinica koje se odvojeno istaliraju (servisne komponente). promene se
Ukupna agilnost Visoko izolovane u pojedinačnim servisnim komponentama što omogućuje brzu i laku
instalaciju. Bildovanje aplikacije je, takođe, slabo spregnuto što dalje olakšava
promene.
Lakoća instaliranja, koja je posledica potpuno dekuplovane prirode servisnih
Lakoća instaliranja/uvođenja u Visoko komponenti, je jedna od najvećih prednosti aplikacija koje slede ovaj obrazac.
rad
Zbog razdvajanja i izolovanja poslovne funkcionalnosti u nezavisne celine testiranje
Pogodnost za testiranje Visoko se može bolje usmeriti. Regresiono testiranje je takože mnogo lakše na servisnim
komponentama nego na monolitnim aplikacijama. Slaba sprega među servisnim
komponentama umanjuje šanse da izmena na jednoj komponenti proizvede
negativan rezultat na drugom delu aplikacije što, takođe, olakšava testiranje.
Zbog svoje distribuirane prirode ovaj arhitekturalni obrazac ne spada u arhitekture
Performansa Nisko visoke performanse. Ipak, mogu se napraviti aplikacije mikroservisne arhitekture
sa zadovoljavajućim performansama.
Zbog razbijanja na jedinice koje se mogu odvojeno instalirati, obrazac omogućuje
Skalabilnost Visoko individualno skaliranje komponenti, odnosno sofisticirano skaliranje cele
aplikacije.
Izolacija funkcionalnosti u odvojene i različite servisne komponente u velikoj meri
Lakoća razvoja Visoko olakšava razvoj i smanjuje potrebu za koordinacijom među pojedincima i/ili
razvojnim timovima.
2.3.5. Prostorno-bazirana arhitektura

Većina web-baziranih poslovnih aplikacija ima isti tok zahteva: zahtev od brauzera ide prvo na web
server, zatim na aplikativni server i na kraju na server baze podataka. Povećanje opterećenja (broja
konkurentnih korisnika) dovodi pojave uskih grla po slojevima i na kraju završava na bazi podataka
koju je i najteže skalirati.
Prostorno-bazirani arhitekturalni obrazac (klaud arhitekturalni obrazac) je namenjen rešavanju
problema sklabilnosti i konkurentnosti i kao takav je posebno koristan za aplikacije koje imaju
varijabilan i nepredvidiv obim konkurentnih korisnika. Arhitekturalno rešavanje problema varijabilne
i ekstremne skalabilnosti je bolji pristup od skaliranja baze ili dodavanja tehnika keširanja
neskalabilnim arhitekturama.
Ovaj obrazac umanjuje faktore koji ograničavaju skaliranje aplikacije. Ime je dobio po konceptu prostor
torki (tuple space) koji potiče iz distribuirane deljene memorije. Prostor torki je implementacija
paradigme asocijativne memorije za paralelno/distribuirano računarstvo. On obezbeđjuje
repozitorijum torki 10 kojima se može konkurentno pristupati. Jedan primer može da bude situacija u
kojoj postoji grupa procesora koji proizvode delove podataka i grupa procesora koji te delove
podataka koriste. Procesori-proizvođači postavljaju svoje podatke kao torke u prostor, a procesori-
potrošači traže u tom prostoru podatke koji zadovoljavaju određeni kriterijum.
Visoku sklabilnost ovaj obrazac postiže uklanjanjem ograničenja centralne baze podataka i
korišćenjem repliciranih memorijskih gridova podataka umesto baze. Podaci aplikacije se drže u
centralnoj memoriji i repliciraju se među svim aktivnim procesnim jedinicama. Procesne jedinice se
mogu dinamički pokretati i zaustavljati u skladu sa opterećenjem.
Aplikacije koje odgovaraju ovom obrascu su web sajtovi koji primaju zahteve od brauzera i izvršavaju
neku akciju. Tipičan primer su aukcijski sajtovi gde sajt kontinualno prima ponude, evidentira ponudu
sa vremenskom oznakom i ažurira poslednju informaciju ponude i šalje informaciju nazad brauzeru.
Arhitektura ima dve glavne komponente jedinicu obrade (Processing Unit) i virtualizovani srednji sloj
(Virtualized Middleware) kao što je prikazano na slici 16.
Slika 16 Prostorno-bazirani arhitekturalni obrazac

2.3.5.1. Jedinica obrade
Jedinica obrade (slika 17) sadrži komponente aplikacije (ili njihove delove) što obuhvata web-bazirane
komponente i pozadinsku poslovnu logiku. Sadržaj procesne jedinice varira u zavisnosti od aplikacije -
manje web-bazirane aplikacije su u jednoj procesnoj jedinici, dok za veće aplikacije funkcionalnost
može da bude raspodeljena među više procesnih jedinica na bazi funkcionalnih oblasti aplikacije.
Procesna jedinica obično sadrži aplikacione module zajedno sa memorijskim gridom podataka i
opcionim asinhronim perzistentnim skladištem za fejlover (failover, modul za preuzimanje funkcija u
slučaju prekoračenja opterećenja). Sadrži i modul za replikaciju koji koristi virtualizovani srednji sloj da
bi se u drugim aktivnim procesnim jedinicama replicirale promene u podacima koje proizvede jedna
procesna jedinica.
10
U matematici, torka je konačna uređena lista (sekvenca) elemenata. n-torka je sekvenca od n elemenata,
gde je n nenegativan ceo broj. Postoji samo jedna 0-torka (prazna torka). n-torka se definiše induktivno
korišćenjem konstrukcije uređenog para. Uređeni par (a, b) je par objekata gde je redosled objekata značajan.
Uređeni parovi su 2-torke, odnosno sekvence dužine 2. Objekti uređenog para mogu da budu drugi uređeni
parovi što omogućuje rekurzivno definisanje uređenih n-torki, n.pr.: (a,b,c) = (a, (b,c)).
Slika 17. Komponenta procesne jedinice
2.3.5.2. Virtualizovani srednji sloj

Komponenta virtualizovanog srednjeg sloja bavi se održavanjem konzistentnosti i komunikacijama.
Sadrži komponente koje kontrolišu različite aspekte sinhronizacije podataka i rukovanja zahtevima.
Dinamika obrasca. „Magija“ prostorno-bazirane arhitekture je u virtualizovanom srednjem sloju i u
memorijskom gridu podataka koji se sadrže u svakoj jedinici obrade/procesnoj jedinici. Slika 17
prikazuje arhitekturu tipične procesne jedinice koja sadrži aplikacione module, memorijski grid
podataka, opciono asinhrono skladište perzistencije za fejlover i modul za replikaciju podataka.
Virtuelizovani srednji sloj je u osnovi kontroler arhitekture i upravlja zahtevima, sesijama, replikacijom
podataka, obradom distribuiranih zahteva i instaliranjem procesnih jedinica. Postoje četiri glavne
arhitekturalne komponente u virtuelizovanom srednjem sloju:
• Grid za razmenu poruka,
• Grid podataka,
• Procesni grid, i
• Menadžer instaliranja.
Grid za razmenu poruka. Grid za razmenu poruka prikazan je na slici 18. On upravlja ulaznim
zahtevima i informacijama sesije. Kada zahtev prispe u komponentu virtuelizovanog srednjeg sloja,
grid za razmenu poruka određuje koje su aktivne procesne komponente raspoložive da prime zahtev
i prosleđuje zahtev jednoj od raspoloživih procesnih jedinica. Složenost ove komponente može da
varira od jednostavnog round-robin algoritma do složenijeg algorima tipa sledeći-raspoloživi koji čuva
evidenciju o tome koji je zahtev obrađen od strane koje procesne jedinice.
Grid podataka. Ova komponenta je ključna, možda i najvažnija komponenta ovoga obrasca. Ostvaruje
interkaciju sa modulom za replikaciju podataka u svakoj procesnoj jedinici sa ciljem upravljanja
replikacijom podataka među procesnim jedinicama kada se desi ažuriranje podataka. Kako grid poruka
može da prosledi zahtev svakoj raspoloživoj procesnoj jedinici, od suštinskog je značaja da svaka
procesna jedinica sadrži tačno iste podatke u svom memorijskom gridu podataka. Na slici 19 prikazana
je situacija sinhrone replikacije podataka među procesnim jedinicama. U stvarnosti to se radi paralelno
asinhrono i vrlo brzo.
Slika 18 Komponenta grid poruka
Slika 19 Komponenta grid podataka

Procesni grid. Komponenta procesni grid, ilustrovana slikom 20, je opciona komponenta u
virtuelizovanom srednjem sloju koja upravlja obradom distribuiranih zahteva u situacijama kada ima
više procesnih jedinica od kojih svaka rukuje delom aplikacije. Ako dođe zahtev kome je potrebna
koordinacija između tipova procesnih jedinica (n.pr. procesne jedinice za narudžbe i procesne jedinice
za kupce) procesni grid je deo arhitekture koji vrši medijaciju i orkestraciju zahteva između te dve
procesne jedinice.
Slika 20 Komponenta procesni grid
Upravljač instalacija. Ova komponenta upravlja dinamičkim startovanjem i terminiranjem procesnih
jedinica na bazi uslova punjenja. Ona kontinualno nadgleda vremena odziva i korisnička opterećenja i
startuje nove procesne jedinice kada opterećenje raste, odnosno terminira procesne jedinice kada
opterećenje opada. To je kritična komponenta za ostvarivanje potreba varijabilne skalabilnosti unutar
neke aplikacije.
Prostorno-bazirana arhitektura je obrazac koji je složen i skup za implementaciju. Ona je dobar
arhitekturalni izbor za manje web-bazirane aplikacije sa promenljivim opterećenjem (n.pr. sajtovi
društvenih medija, aukcijski sajtovi i sl.). Nije baš pogodna za tradicionalne, velike aplikacije relacionih
baza podataka sa velikim količinama operativnih podataka. Iako sam obrazac ne zahteva
centralizovano skladište podataka, ono se obično pojavljuje za obavljanje funkcija punjenja
memorijskog grida podataka i asinhronu perzistenciju ažuriranja podataka od strane procesnih
jedinica. Uobičajena praksa je kreiranje odvojenih particija koje izoluju privremene i često korišćene
transakcione podatke od neaktivnih podataka da bi se smanjio volumen memorijskog grida podataka
svake procesne jedinice.
Iako je drugo ime ovog obrasca klaud-bazirana arhitektura, procesne jedinice kao i virtuelizovani
srednji sloj ne moraju da budu rezidentni na klaud-baziranim servisima ili PaaS (Platform As A Service),
već mogu da budu raspoređeni i na lokalne servere.
Za aplikacije koje slede ovaj obrazac postoje mnogi proizvodi (n.pr. From GemFire, JavaSpaces,
GigaSpaces, IBM Object Grid, nCache, Oracle Coherence) koji omogućuju implementaciju mnogih
arhitekturalnih komponenti. Pri tome, implementacije mogu mnogo da se razlikuju po mogućnostima
i ceni.
Tabela 5 Evaluacija prostorno-bazirane arhitekture
Aplikacija dobro reaguje na promene u opterećenju zbog mogućnosti brzog
Ukupna agilnost Visoko startovanja i terminiranja procesnih jedinica. Aplikacije oslonjene na ovaj
arhitekturalni obrazac generalno dobro reaguju i na promene u kodu zbog male
veličine aplikacije i dinamičke prirode obrasca.
Iako se prostorno-bazirana arhitektura generalno ne odlikuje raspregnutošću i
Lakoća instaliranja/uvođenja u Visoko distribuiranošću, ona je dinamička i postoje sofisticirani klaud alati koji omogućuju
rad lako postavljanje aplikacija na servere što pojednostavljuje instalaciju.
Testiranje je teško zbog skupog i vremenski zahtevnog testiranja sklabilnosti (teško
Pogodnost za testiranje Nisko je obezbediti veliko opterećenje u testnom ambijentu).
Visoka performansa postiže se pristupom podacima u centralnoj memoriji i
Performansa Visoko mehanizmima keširanja što je ugrađeno u sam obrazac.
Visoka sklabilnost je posledica male ili nikakve zavisnosti od centralizovane baze
Skalabilnost Visoko podataka čime se uklanja glavno usko grlo u skalabilnosti.
Ova arhitektura je zahtevna za razvoj zbog složenosti obrasca i opšteg nedostatka
Lakoća razvoja Nisko prakse i poznavanja alata za njenu implementaciju. Mora se i posebno voditi
računa da ništa od izvornog koda ne utiče negativno na performansu i skalabilnost.
Sve zajedno zahteva ljudske razvojne resurse vrlo visokog kvaliteta.
2.4. Arhitektura podataka

Najopštija definicija termina podatak kaže da je podataka bilo koja sekvenca jednog ili više simbola
[6]. Postoje i druge definicije, koje termin podatak eksplicitno povezuju sa terminom informacija,
među kojima i definicije koje se odnose na računarske podatke (podatke kojima manipuliše računar,
uključujući i njihovo trajno skladištenje). Ove definicije termin podatak prepoznaju kao (odvojene)
delove informacije obično oblikovane i uskladištene na način saglasan specifičnoj nameni [7]. Kada su
u pitanju računarski podaci, jedna prihvatljiva definicija podatka je sledeća: Podatak je odvojen deo
informacije koji se prenosi i skladišti elektronski (digitalno).
Prema izvoru [8] arhitektura podataka sastoji se od modela, politika, pravila i standarda koji određuju
koji će se podaci prikupljati i kako će se skladištiti, uređivati, integrisati i uvoditi u upotrebu u
sistemima podataka i organizacijama.
Za reprezentaciju arhitekture podataka koriste se modeli podataka.
Model podataka je apstraktni model koji organizuje elemente podataka i standardizuje njihov međusobni
odnos i odnos prema entitetima realnog sveta. Tako, model podataka entiteta realnog sveta kuća može da
specificira da je podatak koji predstavlja kuću sastavljen od više drugih elemenata podataka koji, na primer,
predstavljaju površinu kuće, boju fasade i identifikaciju njenog vlasnika.
Termin model podataka koristi se u dva različita ali tesno povezana značenje.
Prvo značenje je apstraktna formalizacija objekata i relacija u određenom aplikativnom domenu
(n.pr. kupci, proizvodi i narudžbe u nekoj proizvodnoj organizaciji).
Drugo značenje je skup koncepata koji se koriste za definisanje takvih formalizacija (n.pr. koncepti
entitet, atribut, relacija, tabela).
Model podataka eksplicitno određuje strukturu podataka. U računarstvu, struktura podataka je
organizacija, rukovanje i format skladištenja podataka za efikasan pristup podacima i modifikaciju
podataka [9]. Operativno, struktura podataka je kolekcija vrednosti podataka, relacija među njima i
funkcija/operacija koje se nad tim podacima mogu primenjivati.
Modeli podataka se izražavaju korišćenjem notacija za modeliranje podataka koje su najčešće grafičke
notacije. Danas se najčešće koriste notacije UML (Unified Modeling language) i ERM (Entity Relation
Model).
Model podataka se izgrađuje na osnovu podataka, relacija među podacima, semantike podataka i
ograničenja podataka. On obezbeđuje detalje o informaciji koju treba skladištiti i koristi se
prvenstveno kada je finalni proizvod generisanje izvornog koda aplikativnog softvera ili priprema
funkcionalne specifikacije softvera.
Modeli podataka klasifikuju se prema različitim kriterijumima. Jedan kriterijum je nivo apstrakcije. Na
osnovu ovoga kriterijuma, model ANSI-SPARC Architecture 11 [10] identifikuje tri nivoa (eksterni nivo,
konceptualni nivo i interni nivo) koji, u suštini, odgovaraju različitim nivoima apstrakcije. Na osnovu
toga su izvedeni sledeći modeli podataka:
• konceptualni model,
• logički model, i
• fizički model.
U nastavku su vrlo sažeto objašnjeni navedeni modeli.
2.4.1. Konceptualni model

Osnovni cilj konceptualnoga (često se naziva i domenskim) modela je da uspostavi entitete, njihove
atribute i njihove relacije, odnosno da definiše semantiku podataka informacionog sistema. Ovaj nivo
modela nema detalja o strukturi podataka. Tri osnovna koncepta modela podataka ovde su: entitet
(fizička ili nefizička stvar realnog sveta); atribut (karakteristike ili svojstva entiteta); relacija (zavisnost
ili asocijacija) između entiteta.
Primer: Dva entiteta su Kupac (Customer) i Proizvod (Product). Atributi entiteta Customer su ime
kupca (customer name) i broj kupca (customer number). Atributi entiteta Product su naziv proizvoda
(product name) i cena proizvoda (product price). Relacija među ovim entitetima je prodaja (Sale).
UML dijagram (ne baš najstrožiji) konceptualnog modela prikazan je na slici 21.
Karakteristike konceptualnog modela podataka su:
• Obuhvata poslovne koncepte za određeni domen.
• Razvija se za potrebe domenskog auditorijuma 12, najčešće i u saradnji sa domenskim
ekspertima.
• Model je u potpunosti nezavisan od bilo kakve tehnologije.
Konceptualni modeli podataka kreiraju zajednički rečnik za sve zainteresovane strane kroz
uspostavljanje osnovnih koncepata i opsega domena. U primeru se radi o domenu prodaje proizvoda
u kome su identifikovani termini kupac i proizvod.
Slika 21 Primer jednostavnog konceptualnog modela
2.4.2. Logički model

Logički model podataka je model podataka specifičnog problemskog domena izražen nezavisno od
konkretnog rešenja za upravljanje bazom podataka ili tehnologije skladištenja, ali u terminologiji
struktura podataka kao što su relacione tebele i kolone, objektno-orijentisane klase ili XML tagovi.
Logički model podataka dodaje informacije elementima konceptualnog modela. Definiše strukturu
elemenata podataka i postavlja relacije među njima. Na slici 22 ilustativno je prikazan logički model
koji odgovara konceptualnom modelu sa slike 1. U ilustrativnom primeru atributima entiteta sistema
dodate su informacije o tipu.
11 Apstraktni standard dizajna za sisteme upravljanja bazama podataka, prvi put predložen 1975. godine
12 Pod terminom domenski auditorijum podrazumevaju se akteri sa određenim nivooom ekspertize u nekom domenu
Slika 22 primer jednostavnog logičkog modela
Logički modeli podataka predstavljaju apstraktnu strukturu informacionog domena. Oni su često
dijagramski i koriste se najčešće u poslovnim procesima koji nastoje da identifikuju i obuhvate stvari
koje su važne za organizaciju i načine na koje su te stvari povezane.
Logički model treba da se zasniva na strukturama identifikovanim konceptualnim modelom, jer logički
model treba da odslikava semantiku informacionog konteksta koju definiše konceptualni model
podataka.
Karakteristike logičkog modela su sledeće:
• Definiše podatke za jedan projekat/problem ali se može integrisati sa drugim logičkim
modelima u opsegu projekta.
• Dizjanira se i razvija nezavisno od SUBP-a.
• Atributima se dodeljuju tipovi podataka, ali bez precizne specifikacije (n.pr., preciznost za
numeričke vrednosti, dužine za stringove).
• Vrši se normalizacija 13 ( obično do 3NF).
2.4.3. Fizički model

Fizički model podataka (dizajn baze podataka) je reprezentacija dizajna podataka na način kako su
podaci implementirani (ili nameravani za implementaciju) u konkretnom sistemu za upravljanje bazom
podataka. Obično se ovaj model izvodi iz logičkog modela, iako ima i situacija inverznog inženjerstva -
izvođenje modela iz postojeće implementacije baze podataka. Potpun fizički model sadrži sve artifakte
baze potrebne za kreiranje relacija između tabela (ako je u pitanju relacioni model), artifakte za
dostizanje željene performanse kao što su indeksi, organičenja, vezne tabele povezivanja,
particionirane tabele, klastere. Fizički model može da se iskoristi i za procenu potrebnih skladišnih
kapaciteta. Primer Ilustracije fizičkog modela gde su definisani ključevi entiteta prikazan je na slici
23.
Slika 23 Ilustrativni primer fizičkog modela podataka

Karakteristike fizičkog modela su:
• Fizički model razvija se za konkretan SUBP/tehnologiju skladištenja, odnosno potpuno je
zavisan od tehnologije.
13 Normalizacija baze podataka je proces strukturiranja relacione baze podataka u skladu sa serijom tzv. normalnih formi
(ima ih ukupno 6) da bi se redukovala redundancija podataka i unapredio integritet podataka.
• Svi podaci i artifakti opisa organizacije podataka moraju biti u potpunosti definisani (tipovi,
dužine i pretpostavljene vrednosti za atribute/kolone; primarni i strani ključevi, indeksi,
progledi, itd.).
• Iako fizički model opisuje podatke za konkretan problemski zadatak, on se može integrisati sa
drugim fizičkim modelima u okviru zadatka.
2.4.4. Uporedna analiza konceptualnog, logičkog i fizičkog modela

U Tabeli 6 data je uporedna analiza konceptualnog, logičkog i fizičkog modela podataka u odnosu na
sledeće kriterijume:
• Uključene konstrukte;
• Imenovanje elemenata u modelu prilagođeno ciljnom auditorijumu;
• Tehnološku zavisnost;
• Primenu normalizacije;
Tabela 6 Uporedna analiza konceptualnog, logičkog i fizičkog modela podataka
Konceptualni model
Kriterijum Logički model podataka Fizički model podataka
podataka
Entiteti (tabele), atributi Tabele, kolone, ključevi, tipovi podataka, pravila
Uključeni Konstrukti podataka visokog
(kolone/polja) i relacije validacije, okidači, uskladištene procedure,
konstrukti nivoa (semantika podataka).
(ključevi) domeni, i ograničenja pristupa.
Netehnička imena koja ne
Definisanija i manje generička imena za tabele i
Imenovanje zahtevaju tehničko Poslovna imena za entitete i
kolone uzrokovana ograničenjima konkretnog
elemenata obrazovanje, razumljiva atribute.
DBMS-a ili kompanijskih standarda.
rukovodećem kadru.
Potpuna nezavisnost od Nezavisnost od tehnologije Zavisnost od tehnologije; uključuje atrefakte za
Tehnološka
svake tehnologije (samo koja se odnosi na platformu dostizanje performansi (primarne ključevi, indeksi,
zavisnost
semantika podataka). i/ili SUBP. ...).
Može da bude denormalizovana radi dostizanja
Može da bude Normalizovano do četvrte performansi u zavisnosti od prirode baze podataka;
Normalizacija
nenormalizovana. normalne forme (4NF). denormalizacija je uobičajena za skladišta
podataka (datawarehouse).
2.4.5. Klasifikacija logičkih modela

Kao što je već rečeno, logički modeli podataka predstavljaju apstraktnu strukturu informacionog
domena. Zbog toga što u sebi objedinjuju semantiku domena i strukturu podataka sa dovoljnim
nivoom detaljnosti a nezavisno od tehnologije, oni su od presudnog interesa za razvoj (dizajn i
implementaciju) softvera.
Logički modeli se dalje, na osnovu apstraktnih matematičkih struktura na koje se oslanjaju za
organizovanje podataka i teorijskih osnova, klasifikuju na relacione modele, mrežne modele, i
hijerarhijske modele 14. U ovom odeljku biće dat sažet prikaz ovih modela, a modeli koji su posebno
značajni za Veb informacione sisteme biće detaljnije izloženi u nastavku ove knjige.
2.4.5.1. Relacioni model
Relacioni model je danas najšire korišćen model za upravljanje bazama podatka. Struktura podataka
na koju se model oslanja je tabela. To je model čija je teorijska osnova predikatska logika prvog reda i
gde su svi podaci predstavljeni pomoću torki grupisanih u relacije. Zbog njegove široke zastupljenosti
u industriji ovde ćemo ga objasniti malo detaljnije. Naravno, izlaganje koje ovde dajemo je samo
14 To su tri “fundamentalna” modela podataka. Postoje i drugi modeli, kao što su objektni model, NoSQL model, grafovski
model.
preglednog karaktera a za dublje razumevanje koje omogućuje i njegovu praktičnu primenu potrebno
je mnogo više. Sledeća slika ilustruje relacioni model podataka.
Slika 24 Ilustracija relacionog modela podataka

Smatra se da je autor relacionog modela podataka Edgar Kod (1923 - 2003) koji je svoje ideje prvi put
prikazao u radu "A Relational Model of Data for Large Shared Data Banks" 15 objavljenom 1970. godine.
Nakon toga, početkom 1980-tih, relacione baze podataka preuzimaju dominaciju u oblasti koju su i do
danas zadržale. Najpoznatiji sistemi za upravljanje bazama podataka, poput sistema Oracle,
implementirani su u osnovi kao relacioni model.
Fundamentalna pretpostavka relacionog modela je da se svi podaci predstavljaju kao n-arne
matematičke relacije, gde je n-arna relacija podskup Dekartovskog proizvoda n domena. Na taj način
se manipulisanje podacima svodi na rezonovanje u matematičkom modelu dvo-vrednosne predikatske
logike, gde rezultat za svaki iskaz (tvrđenje) može da bude true ili false (bez treće vrednosti
poput unknown, ili not applicable koja se često asocira sa konceptom NULL). Nad podacima se operiše
korišćenjem dva jezika sa ekvivalentnom izražajnom snagom: relacione algebre 16 ili relacionog
računa 17.
Relacioni model pruža mogućnost kreiranja konzistentne logičke reprezentacije informacija.
Konzistentnost se postiže putem deklarisanih ograničenja.
Osnovni relacioni gradivni blok je domen ili tip podatka. Torka je uređeni skup atributskih vrednosti.
Atribut je uređeni par imena atributa i imena tipa. Atributska vrednost je specifična validna vrednost
za tip atributa. To može da bude skalar ili složeniji tip.
Relacija se sastoji iz zaglavlja i tela. Zaglavlje je skup atributa. Telo (n-arne relacije) je skup n-torki.
Zaglavlje relacije je i zaglavlje svake od torki te relacije.
Relacija je definisana kao skup n-torki. I u matematici i u modelu relacione baze podataka, skup je
neuređena kolekcija jedinstvenih (nedupliciranih) entiteta. Međutim, neki sistemi za upravljanje
bazama podatka nameću svojim podacima uređenje a u matematici torka ima uređenje i dozvoljava
dupliciranje. Iako je E.F. Codd, koji je “izmislio” relacioni model, krenuo sa definisanjem torki koristeći
te matematičke definicije, kasnije se došlo do saznanja da je korišćenje imena atributa umesto
njihovog uređenja mnogo pogodnije jer na taj način Dekartovski proizvod postaje komutativan.
Tabela je vizuelna reprezentacija relacije a vrsta u tabeli je vizuelna reprezentacije torke.
Relaciona varijabla (zovu je relvar) je imenovana varijabla nekog specifičnog relacionog tipa kojoj se
uvek dodeljuje neka relacija tog tipa, iako ta relacija može da bude “prazna” - da sadrži nula torki.
15 Dostupno na https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
16 Relaciona algebra je proceduralni upitni jezik u kome je redosled izvršavanja operacija važan.
17 Relacioni račun je deklarativni upitni jezik u kome redosled izvršavanja nije važan.
Osnovni princip relacionog modela je Informacioni Princip: sve informacije reprezentuju se
vrednostima podataka u relacijama. Dakle, relaciona baza podataka nije ništa drugo do skup relacionih
varijabli a rezultat svakog upita se predstavlja kao relacija.
Velika prednost relacionog modela je što on omogućuje da se konzistentnost relacione baze obezbedi
putem ograničenja koja se deklarišu kao deo logičke šeme. Na taj način, sistem za upravljanje bazom
void računa o konzistentnosti i aplikacije o tome ne moraju da vode računa.
Generalno, ograničenja se izražavaju relacionim operatorima poređenja, od kojih su najvažnija
ograničenja kandidatski ključ (candidate key, superkey) i strani ključ (foreign key), a teorijski je
dovoljan samo jedan operator ("je podskup od" (⊆).
Relacija je ključni koncept u relacionom modelu podataka pa je za razumevanje relacionog modela
neophodno razumeti nameravani unterpretaciju relacije. Ovde ćemo pokušati da ovu interpretaciju
objasnimo putem formulacije bazirane na teoriji skupova.
Telo relacije se ponekad naziva proširenjem. Ovakav naziv potiče iz činjenice da se relacija ponekad
interpretira kao reprezentacija proširenja 18 nekog predikata što je skup tačnih propozicija (iskaza) koji
se može formirati tako što se svaka slobodna varijabla 19 u tom predikatu zameni imenom (terminom
koji označava nešto).
Postoji jedan-na-jedan korespondencija između slobodnih varijabli predikata i imena atributa u
zaglavlju relacije. Svaka torka tela relacije sadrži vrednosti atributa za instanciranje predikata
supstitucijom tih vrednosti u svaku od njegovih slobodnih varijabli. Rezultat je propozicija koja se
smatra istinitom ako u telu relacije postoji pojava neke torke koja za koju je predikat zadovoljen.
Nasuprot tome, svaka torka čije zaglavlje je saglasno sa relacijom, ali koja se ne pojavljuje u telu smatra
se netačnom. Dakle, važi pretpostavka zatvorenog sveta.
Sledi formalna (matematička) formulacija ovih ideja zasnovana na teoriji skupova.
Osnovni pojmovi u relacionom modelu su imena relacija, imena atributa i atomske vrednosti. Imena
relacija i atributa se predstavljaju stringovima a atomska vrednost sadrži vrednosti koje se dalje ne
mogu "dekomponovati" kao što su brojevi i stringovi.
Definicija 1. Torka je parcijalna funkcija 20 koja preslikava imena atributa na atomske vrednosti.
Definicija 2. Zaglavlje je konačan skup imena atributa.
Definicija 3. Projekcija torke 𝑡𝑡 nad konačnim skupom atributa 𝐴𝐴 je 𝑡𝑡[𝐴𝐴] = {(𝑎𝑎, 𝑣𝑣 )| (𝑎𝑎, 𝑣𝑣 ) ∈ 𝑡𝑡, 𝑎𝑎 ∈ 𝐴𝐴}.
Definicija 4. Relacija je torka (𝐻𝐻, 𝐵𝐵) sa zaglavljem 𝐻𝐻 i telom 𝐵𝐵 koje je skup torki koje sve imaju domen
𝐻𝐻.
Definicija 5. Relacioni univerzum 𝑼𝑼 nad zaglavljem 𝐻𝐻 je neprazan skup relacija sa zaglavljem 𝐻𝐻.
Definicija 6. Relaciona šema (𝐻𝐻, 𝐶𝐶 ) sastoji se od zaglavlja 𝐻𝐻 i predikata 𝐶𝐶 (𝑅𝑅) koji je definisan za sve
relacije 𝑅𝑅 i zaglavlje 𝐻𝐻. Relacija zadovoljava relacionu šemu ako ima zaglavlje 𝐻𝐻 i zadovoljava predikat
𝑅𝑅.
U relacionoj bazi, najjednostavniji i najvažniji tipovi ograničenja relacija su ograničenja ključa. Ovo
ograničenje kaže da u svakoj instanci određene relacione šeme torke mogu da se identifikuju
vrednostime njihovih određenih atributa.
Definicija 7. Superključ je skup atributa koji jednoznačno identifikuje torku. Superključ 𝐾𝐾 važi za
relaciju (𝐻𝐻, 𝐵𝐵) ako su zadovoljeni uslovi
18 Proširenje predikata – funkcija sa vrednošću tačno/netačno – je skup torki vrednosti takvih da kao argumenti zadovoljavaju
predikat (za taj argument predikat se evaluira na vrednost 𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡). Takav skup torki je relacija.
19 U matematici i drugim disciplinama koje se bave formalnim jezicima, slobodna varijabla je koncept (simbol) koji specificira
mesto u izrazu na kome se može izvršiti supstitucija (zamenuti vrednost) i nije parametar tog ili bilo kojeg drugog
kontejnerskog izraza.
20 Parcijalna funkcija je binarna relacija nad dva skupa koja svakom elementu prvog skupa pridružuje najviše jedan element
drugog skupa.
• 𝐾𝐾 ⊆ 𝐻𝐻
• Ne postoje dve različite torke 𝑡𝑡1 , 𝑡𝑡2 ∈ 𝐵𝐵 takve da je 𝑡𝑡1 [𝐾𝐾 ] = 𝑡𝑡2 [𝐾𝐾 ].
Superključ važi u relacionom univerzumu 𝑈𝑈, ako važi u svim relacijama u 𝑈𝑈.
Teorema. Superključ 𝐾𝐾 važi u relacionom univerzumu 𝑈𝑈 nad 𝐻𝐻 ako i samo ako u 𝑈𝑈 važi 𝐾𝐾 ⊆ 𝐻𝐻 i 𝐾𝐾 →
𝐻𝐻.
Kandidatski ključ je superključ koji se dalje ne može dekomponovati tako da formira drugi superključ.
Superključ 𝐾𝐾 važi kao kandidatski ključ za relacioni univerzum 𝑈𝑈 ako važi kao superključ za 𝑈𝑈 i nema
pravog podskupa skupa 𝐾𝐾 koji važi kao superključ za 𝑈𝑈.
Funkcionalna zavisnost (functional dependency – FD, piše se kao 𝑋𝑋 → 𝑌𝑌 gde su 𝑋𝑋, 𝑌𝑌 konačni skupovi
imena atributa) je svojstvo da vrednost u torci može da se izvede iz druge vrednosti u toj torci.
Funcionalna zavisnost 𝑋𝑋 → 𝑌𝑌 važi u relaciji (𝐻𝐻, 𝐵𝐵) ako važi:
• 𝑋𝑋, 𝑌𝑌 ⊆ 𝐻𝐻, i
• Za svake dve torke 𝑡𝑡1 , 𝑡𝑡2 ∈ 𝐵𝐵, 𝑡𝑡1 [𝑋𝑋] = 𝑡𝑡2 [𝑋𝑋] ⇒ 𝑡𝑡1 [𝑌𝑌] = 𝑡𝑡2 [𝑌𝑌]
Funkcionalna zavisnost 𝑋𝑋 → 𝑌𝑌 važi u relacionom univerzumu 𝑈𝑈 ako važi za sve relacije u 𝑈𝑈.
Trivijalna funkcionalna zavisnost pod zaglavljem 𝐻𝐻 je funkcionalna zavisnost koja važi u svim
relacionim univerzumima nad 𝐻𝐻.
Teorema: Funkcionalna zavisnost 𝑋𝑋 → 𝑌𝑌 je trivijalna pod zaglavljem 𝐻𝐻 ako i samo ako je 𝑌𝑌 ⊆ 𝑋𝑋 ⊆ 𝐻𝐻.
Zatvaranje podskupa 𝑆𝑆 tačaka u topološkom prostoru 21 sastoji se od svih tačaka iz 𝑆𝑆 zajedno sa svim
tačkama granice (limit point) 22 skupa 𝑆𝑆. Zatvaranje se može ekvivalentno definisati i kao unija skupa i
njegove granice ili kao presek svih zatvorenih skupova koji sadrže dati skup.
Intuitivno, zatvaranje se može zamisliti kao sve tačke koje su u datom skupu ili su mu "blizu".
Tačka koja pripada zatvaranju skupa je tačka zatvaranja tog skupa.
Armstrongovi aksiomi: Zatvaranje skupa funkcionalnih zavisnosti 𝑆𝑆 nad zaglavljem 𝐻𝐻 (označava se sa
𝑆𝑆 + ) je najmanju nadskup od 𝑆𝑆 takav da zadovoljava uslove refleksivnosti, tranzitivnosti i augmentacije:
• 𝑌𝑌 ⊆ 𝑋𝑋 ⊆ 𝐻𝐻 ⇒ 𝑋𝑋 → 𝑌𝑌 ∈ 𝑆𝑆 + (refleksivnost)
• 𝑋𝑋 → 𝑌𝑌 ∈ 𝑆𝑆 + ⋀ 𝑌𝑌 → 𝑍𝑍 ∈ 𝑆𝑆 + ⇒ 𝑋𝑋 → 𝑍𝑍 ∈ 𝑆𝑆 + (tranzitivnost)
• 𝑋𝑋 → 𝑌𝑌 ∈ 𝑆𝑆 + ⋀ 𝑍𝑍 ⊆ 𝐻𝐻 ⇒ (𝑋𝑋 ⋃ 𝑍𝑍) → (𝑌𝑌 ⋃ 𝑍𝑍) ∈ 𝑆𝑆 + (augmentacija)
Teorema. Armstrongovi aksiomi su saglasni i kompletni; za zadato zaglavlje 𝐻𝐻 i skup 𝑆𝑆 funkcionalnih
zavisnosti koji sadrži samo podskup od 𝐻𝐻, 𝑋𝑋 → 𝑌𝑌 ∈ 𝑆𝑆 + ako i samo ako 𝑋𝑋 → 𝑌𝑌 važi u svim relacionim
univerzumima nad 𝐻𝐻 u kojima važe sve funkcionalne zavisnosti u 𝑆𝑆.
Završavanje/kompletiranje (completion) konačnog skupa atributa 𝑋𝑋 pod konačnim skupom
funkcionalnih zavisnosti (označava se sa 𝑋𝑋 + ) je najmanji super skup od 𝑋𝑋 za koji važi:
• 𝑌𝑌 → 𝑍𝑍 ∈ 𝑆𝑆 ⋀ 𝑌𝑌 → 𝑍𝑍 ∈ 𝑆𝑆 + ⇒ 𝑍𝑍 ⊆ 𝑋𝑋 +
Kompletiranje skupa atributa može da se koristi za određivanje da li je konkretna zavisnost u
zatvaranju skupa funkcionalnih zavisnosti na osnovu sledeće teoreme.
Teorema. Ako je zadat skup 𝑆𝑆 funkcionalnih zavisnosti, 𝑋𝑋 → 𝑌𝑌 ∈ 𝑆𝑆 + ako i samo ako je 𝑋𝑋 → 𝑌𝑌 ⊆ 𝑋𝑋 + .
21 Topološki prostor može se definisati kao skup tačaka zajedno sa skupom susedstva svake tačke u kome je zadovoljen skup
aksioma koji povezuju tačke i susedstva.
22 Granična tačka skup 𝑆𝑆 u topološkom prostoru 𝑋𝑋 je tačka 𝑥𝑥 koja se može "aproksimirati" tačkama iz skupa 𝑆𝑆 tako da svako
susedstvo od 𝑥𝑥 u odnosu na topologiju nad 𝑋𝑋 takođe sadrži tačku is skupa 𝑆𝑆 različitu od same tačke 𝑥𝑥 . Granična tačka skupa
ne mora sama da bude element tog skupa.
Nesvodljivo pokrivanje skupa 𝑆𝑆 funkcionalnih zavisnosti je skup funkcionalnih zavisnosti 𝑇𝑇 takav da
važi:
• 𝑆𝑆 + = 𝑇𝑇 + ,
• Ne postoji 𝑈𝑈 ⊂ 𝑇𝑇 takvo da je 𝑆𝑆 + = 𝑈𝑈 + ,
• 𝑋𝑋 → 𝑌𝑌 ∈ 𝑇𝑇 ⇒ 𝑌𝑌 je singltonski skup, i
• 𝑋𝑋 → 𝑌𝑌 ∈ 𝑇𝑇 ∧ 𝑍𝑍 ⊂ 𝑋𝑋 ⇒ 𝑍𝑍 → 𝑌𝑌 ∉ 𝑆𝑆 +
2.4.5.2. Hijerarhijski model
Hijerarhijski model podataka je najstariji. Kao osnovnu strukturu podataka koristi strukturu stabla.
Podaci se skladište kao zapisi (record) koji su međusobno povezani linkovima. Zapis je kolekcija polja
od kojih svako sadrži samo jednu vrednost. Tip zapisa definiše polja u zapisu. Smatra se prvim
modelom podataka koji je IBM kreirao 1960-tih godina.
Hijerarhijski model podataka ima ograničenje da svaki naslednički (dete) zapis ima samo jedan
predački (roditelj) zapis, dok jedan roditeljski čvor može da ima više nasledničkih čvorova.
Sledeća slika [11] ilustruje hijerarhijski model podataka:
Slika 25 Primer hijerarhijskog modela podataka

Hijerarhijski model obuhvata sledeće uobičajene operacije:
• Nabrajanje svih stavki 23
• Nabrajanje sekcije stabla
• Traženje stavke
• Dodavanje stavke na zadatu poziciju u stablu
• Brisanje stavke
• Orezivanje (Pruning): Uklanjanje cele sekcije stabla
• Kalemljenje (Grafting): Dodavanje sekcije stablu
• Nalaženje korena za neki čvor
• Nalaženje najmanjeg zajedničkog pretka za dva čvora
Vrlo često se operacija izvršava kada pokazivač pokazuje na određeni čvor. To „pozicioniranje“
omogućuje obilaskom stabla (walk of the tree) koristeći veze između roditelja i dece. Stablo se može
obilaziti na različite načine od koji spominjemo samo dva: pre-uređen obilazak (prvo se prolazi kroz
svaki roditeljski čvor, zatim kroz njegovu decu); obilazak po nivou (omogućuje pretragu “po širini”)
gde se prvo posećuje korenski čvor, zatim deca korenskog čvora i njihovi “rođački” čvorovi, zatim
“unuci” korenskog čvora i njihovi “rođački” čvorovi, I tako dalje sve dok se ne prođe kroz sve čvorove
(ili se ne zaustavi na nekoj “dubini”).
Ovaj model je 1980.-tih potisnut pojavom relacionog modela zbog svoje nefleksibilnosti uzrokovane
ograničenošću na relacije tipa jedan-na-više. Kasnih 1990-tih ponovo dobija na značaju sa pojavom
XML-a. Trenutno se koristi u aplikacijama koje zahtevaju visoke performanse i raspoloživost. Primeri
23 Stavka (entity)/ „strelica“ (arrow) ovde označava uređen par roditelj-dete

primene su aplikacije u bankarstvu i telekomunikacijama, ali i u operativnim sistemima (Windows
Registry u Microsoft Windows operativnom sistemu).
2.4.5.3. Mrežni model
Mrežni model (poznat i pod imenom CODASYL model) je usvojilo telo CODASYL (Programming
Language Committee, of the Conference of Data Systems Language) Data Base Task Group 24 1969.
godine, a 1971 model je pretrpeo glavnu reviziju. Primenjivan je u sistemima baza podataka tokom
1970-tih, a 1980-tih je i on zamenjen modelom koji je dugo dominirao (i još uvek dominira) oblašću –
relacionim modelom.
Mrežni model je sličan hijerarhijskom modelu. Napravljen je sa idejom da podrži fleksibilan način za
predstavljanje objekata i njihovih veza. Njegova najznačajnija odlika je šema predstavljena grafom u
kome su tipovi objekata čvorovi a tipovi relacije su lukovi (veze) pri čemu ne postoji restrikcija na
hijerarhiju ili rešetku, već čvorovi mogu da imaju višestruke roditelje. Mrežni model se oslanja na dve
strukture podataka: rekord/slog (Record) 25 i Skup (Set) 26. Ilustracija mrežnog modela prikazana je na
slici 26 .
Slika 26 Primer mrežnog modela podataka
2.4.6. Sažeto poređenje osnovnih modela

U Tabeli 7 koja sledi dato je vrlo sažeto poređenje tri navedena osnovna modela preuzeto iz [12].
Tabela 7 Poređenje osnovnih modela
Hijerarhijski model Mrežni model Relacioni model
Za skladištenje podataka u ovom
Organizuje slogove u obliku tabele, a
modelu se koristila hijerarhijska Međusobno organizuje slogove putem
relacije između tabela se uspostavljaju
metoda (relacija roditelj-dete). Ona se linkova ili pokazivača.
korišćenjem zajedničkih polja.
danas više ne koristi.
Za organizovanje slogova, koristi se Slogove organizuje u obliku
Organizuje rekorde u obliku tabela.
struktura tipa stabla. usmerenog grafa.
Implementira relacije 1:1, 1:n, i više- Implementira relacije 1:1, 1:n, i više-
Implementira relacije 1:1 i 1:n.
na-više. na-više.
Prisutna je anomalija umetanja 27. Ne postoji anomalija umetanja. Ne postoji anomalija umetanja.
Prisutna je anomalija brisanja 28 , t.j.
Ne postoji anomalija brisanja. Ne postoji anomalija brisanja.
teško se briše roditeljskih čvor.
24 Data Base Task Group (DBTG) bila je radna grupa osnovana 1965. godine inicijalno pod imenom List Processing Task
Force koje je izmenjeno u DBTG 1967. godine.
25 Rekord je osnovna struktura podataka koja predstavlja kolekciju obično fiksnog broja polja moguće i različitih tipova
podataka, uređenih u sekvencu.

26 Skup je apstraktni tip podataka koji može da skladišti jedinstvene vrednosti bez posebnog uređenja.
27 Anomalija umetanja je pojava kada se naslednički čvor (dete) ne može umetnuti bez roditeljskog čvora.
28 Anomalija brisanja dešava se kada se obriše slog koji sadrži atribute koji ne bi trebali da budu izbrisani.
Hijerarhijski model Mrežni model Relacioni model
Model pati od nedostatka nezavisnosti Postoji delimična nezavisnost Model obezbeđuje nezavisnosz
podataka. podataka u modelu. podataka.
Koristi se za pristup poaximyIt is used
Koristi se za pristup složenim, Koristi se za pristup složenim,
to access the data which is complex
asimetričnim podacima. simetričnim podacima.
and symmetric.
U originalnoj specifikaciji korišćen je
na mini računarima iz 1980-tih( VAX- Praktično svi SUBP ga implementiraju
Ovaj model koriste &XML i XAML.
DBMS, DMS-1100 of UNIVAC i (Oracle, SQL, …).
SUPRADBMS’s).
Danas postoje još mnogi logički modeli podataka i sa njima povezani modeli baza podataka. U osnovi,
oni predstavljaju hibride navedenih osnovnih modela, posebno relacionog i mrežnog modela. Među
njima se ističu grafovski modeli koji se koriste za reprezentaciju semantike podataka. O njima će još
biti reči u nastavku knjige.
2.5. Informaciona arhitektura

Informaciona arhitektura (Information architecture, IA) je praksa odlučivanja o načinu uređivanja
nečega tako da bude razumljivo. 29
Izvor [12] naglašava da postoje razlike u značenju termina IA u različitim granama informacionih
sistema ili informacione tehnologije:
1. Strukturalni dizajn okruženja deljenih informacija.
2. Umetnost i nauka organizovanja i označavanja veb sajtova, intranet mreža, onlajn
zajednica i softvera radi podrške nalaženju i iskoristivosti.
3. Nastajuća zajednica praksi fokusirana na uvođenje principa dizajna i arhitekture u
digitalni pejsaž.
4. Kombinacija orgnaizovanja, označavanja, sistema za pretragu i navigaciju u veb
sajtovima i intranet sistemima.
5. Izdvajanje potrebnih parametara/podataka inženjerskog dizajna u proces kreiranja
baze znanja koja povezuje različite sisteme i standarde.
6. Plan i navigacijska pomoć sadržaju sistema bogatih informacijama.
7. Podskup arhitekture podataka gde se upotrebljiv podatak (a.k.a. informacija)
konstruiše i dizajnira ili uređuje na način koji je najkorisniji korisnicima podataka.
8. Praksa organizovanja informacija/sadržaja/funkcionalnosti veb sajta na način koji
omogućuje najbolje korisničko iskustvo u smislu da informacije i servisi mogu lako
da se nađu i koriste.
9. Konceptualni okvir koji okružuje informacije, obezbeđuje kontekst, svest o lokaciji i
održivoj strukturi.
Različito tumačenje termina IA je posledica činjenice da se termin koristi u oblastima koje objedinjuju
više, najčešće raznorodnih oblasti. Ipak, postoji definicija koja je, po mišljenju autora ove knjige,
prihvatljiva kao polazna osnova za dalje prilagođavanje specifičnim potrebama. Definiciju je
formulisao Endru Dilon u [13] i ona glasi:
“IA je termin koji se koristi da opiše proces dizajna, implementacije i evaluacije informacionih prostora
koju su personalno i socijalno prihvatljivi za njihove nameravane interesente.”
U istom izvoru razlikuju se dve “vrste” informacione arhitekture: mala IA i velika IA.
29 What is IA?, The Information Architecture Institute, dostupno na: https://www.iainstitute.org/what-is-ia, pristup:
30.01.2021
Pod terminom mala IA autor podrazumeva primenu informacione nauke u veb dizajnu što se odnosi
na pitanja klasifikacije i traženja informacija. Ovaj pogled smatra WWW razlogom postojanja IA i svoj
auditorijum nalazi u onima koji se bave bibliotekarskom naukom i/ili onima koji imaju izričito
interesovanje za organizaciju.
Termin velika IA se, pak, koristi da označi nešto mnogo ambicioznije. Ovde je stanovište da
informacioni prostori zahtevaju dizajn na više nivoa i da je korisničko iskustvo života u takvom prostoru
zadatak (i rezultat) rada onoga koji se bavi informacionom arhitekturom.
Mi ćemo se ovde baviti malom IA jer je ona jedan od temelja Veb informacionih sistema. U nastavku
će posebno poglavlje biti posvećeno temi informacione arhitekture za Veb.
2.6. Komunikaciona arhitektura

Komunikaciona infrastruktura za Veb informacione sisteme je Internet. Pri tome, valja naglasiti da se
ovde pod terminom Internet podrazumeva mreža koja nije nužno globalna. Čak i kada je informacioni
prostor ograničen logički (a i fizički), koncepti pa čak i tehnologije su isti. Model komunikacije na
Internetu je TCP/IP model pa je i model komunikacione arhitekture za Veb informacione sisteme
TCP/IP model.
U nastavku ćemo samo vrlo sažeto navesti najvažnije o TCP/IP modelu.
2.6.1. TCP/IP model

Pretpostavka za razumevanje TCP/IP modela je razumevanje koncepta otvorenog komuniciranja koji
je uveden ISO/OSI referentnim modelom 1984. godine i gde skraćenica OSI znači Open Systems
Interconnection. Ovaj model predstavlja slojevitu arhitekturu od 7 slojeva, od kojih svaki obavlja
specifičnu funkcionalnost a slojevi u saradnji ostvaruju prenos podataka koji obezbeđuje potpunu
komunikaciju globalnih razmera. Model je nezavisan od protokola komunikacije. Model definiše
način komuniciranja koji omogućuje povezivanje uređaja različitih proizvođača, što nije postojalo
pre njegove pojave. Izradu modela iniciralo je Ministarstvo odbrane SAD sa ciljem da spreči (ili bar
ublaži) zavisnost od isporučilaca opreme. Na slici ??? prikazana je vizuelna reprezentacija ISO/OSI
referentnog modela. Sažet opis ISO/OSI referentnog modela dat je u Dodatku 1: ISO/OSI referentni
model.
Slika ??? ISO/OSI referentni model

OSI Model je referentni/logički model koji funkcije komunikacionog sistema opisuje tako što deli
proces komunikacije u manje i jednostavnije komponente. Bitna njegova osobina je da je neutralan
u odnosu na protokole komunikacije.
TCP/IP model je, takođe, referentni model koji je razvijen u Ministarstvu odbrane SAD šezdesetih
godina prošlog veka. Njegova bitna osobina je da nije neutralan u odnosu na protokole
komunikacije, već je bazirana na standardnim protokolima. Ideja slojevitog protokola je osnova
TCP/IP modela kao i OSI modela, ali se modeli razlikuje po broju slojeva. Standardan TCP/IP model
razlikuje četiri sloja, ali ima i model koji razlikuje pet slojeva. Mi ćemo se ovde držati standarda koji
prepoznaje sledeće slojeve:
1. Procesni/Aplikacioni sloj
2. Host-to-Host/Transportni sloj
3. Internet sloj
4. Sloj mrežnog pristupa/Link sloj
Iako je broj slojeva različit između TCP/IP i OSI modela, među slojevima postoji veza – neka vrsta
mapiranja. Dijagramska reprezenatcija ovoga mapiranja prikazana je u sledećoj tabeli:
TCP/IP model OSI model

Aplikativni
Aplikativni Prezentacioni
Sesija
Host-to-Host/Transportni Transportni
Internet Mrežni
Link podataka
Sloj mrežnog pristupa/Link
Fizički
Još jedna krakateristika koja će se moći zapaziti i iz narednih izlaganja je o TCP/IP modelu da u praksi
nije uvek moguće protokole komunikacije klasifikovati u disjunktne slojeve referentnog modela. Ima
protokola koji su diskutabilni iz aspekta pripadnosti slojevima kao što je, na primer, ARP (Address
Resolution Protocol) protokol.
Pa da opišemo TCP/IP model po slojevima.
Ako se gleda iz aspekta pošiljaoca, prvi sloj je Aplikacioni sloj. Ako se pak gleda iz aspekta primaoca,
prvi sloj je Sloj mrežnog pristupa. U nastavku ćemo stvar gledati iz aspekta primaoca.
2.6.1.1. Sloj pristupa mreži (Network Access Layer)
Ovaj sloj se mapira na slojeve link podataka i fizički sloj u OSI modelu. On se bavi hardverskim
adresiranjem i protokoli u njemu omogućuju fizički prenos podataka. Na ovom sloju su, na primer,
protokoli ARP, NDP, OSPF, L2TP, PPP, MAC (Ethernet, Wi-Fi, …). Za prvi pomenuti protokol iz ovoga sloja,
ARP protokol, postoji neslaganje da li je protokol sloja Internet ili sloja mrežnog pristupa. Prihvaćeno
je da je to protokol koji se nalazi u Internet sloju ali je enkapsuliran 30 protokolima sloja mrežnog
pristupa.
2.6.1.2. Internet sloj
Ovaj sloj se mapira na Mrežni sloj OSI modela. On definiše protokole koji su odgovorni za logički prenos
podataka kroz celu mrežu. Najvažnij protokoli ovoga sloja su:
30 https://en.wikipedia.org/wiki/Encapsulation_(networking)
1. IP – Internet Protocol koji je odgovoran za isporuku paketa od izvorišnog hosta do
odredišnog hosta a na osnovu IP adresa 31 u zaglavljima paketa.
2. ICMP – Internet Control Message Protocol koji je enkapsuliran u IP datagrame i
odgovoran je za obaveštavanje hostova o problemima sa mrežom.
3. ARP – Address Resolution Protocol koji ima zadatak da odredi hardversku adresu hosta
iz poznate IP adrese. Ima više vrsta ovoga protokola: Reverse ARP, Proxy ARP,
Gratuitous ARP i Inverse ARP. Enkapsuliran je u protokolima mrežnog pristupa (n.pr u
Ethernet frejmu).
2.6.1.3. Host-to-Host sloj
Ovo je sloj koji odgovara transportnom sloju OSI modela. Odgovoran je za komunikaciju sa-kraja-na-
kraj i isporuku podataka bez greške. Cilj ovoga sloja je da sakrije složenost rada sa podacima od
Aplikativnog nivoa. Na ovom sloju su dva glavna protokola:
1. Transmission Control Protocol (TCP) – je konkecijski-orijentisan protokol koji je
odgovoran za pouzdanu komunikaciju bez grešaka između krajnjih sistema. Obavlja
sekvencioniranje i segmentiranje podataka koji se prenose mrežom. Poseduje
sposobnost potvrđivanja i kontroliše tok podataka (kuda će se podaci kretati po mreži).
U pitanju je vrlo složen protokol, sa velikim mogućnostima ali i “skup” (zahteva velike
resurse) za korišćenje .
2. User Datagram Protocol (UDP) – je bezkonekcijski protokol koji nema mogućnosti kao
TCP i pogodan je za primene koje ne zahtevaju pouzdan transport. Ne zahteva velike
resurse.
2.6.1.4. Aplikacijski sloj
Oavj sloj obavlja funkcije softverskih slojeva OSI modela. Odgovoran je za komunikaciju od-čvora-do-
čvora i upravlja specifikacijama korisničkog interfejsa. Neki protokoli ovoga sloja su 32: HTTP, HTTPS,
FTP, TFTP, Telnet, SSH, SMTP, SNMP, NTP, DNS, DHCP, NFS, X Window, LPD. U kontekstu Veb
informacionih sistema od njih su sigurno najznačajnija prva dva, HTTP i HTTPS.
31 Postoje dve verzije IP-a: IPv4 (32-bitska adresa) i IPv6 (128-bitska adresa).
32 https://www.geeksforgeeks.org/protocols-application-layer/
Literatura uz Poglavlje 2
1. O’Brien J.A., Marakas G.M. (2015) Introduction to information systems, Fifteenth Edition.
McGraw Hill
2. Clements P., Bachmann F., ; Bass L., Garlan D., Ivers J., Little R., Merson P., Nord R., Stafford
J. (2010) Documenting Software Architectures: Views and Beyond, Second Edition. Boston:
Addison-Wesley. ISBN 978-0-321-55268-6.
3. Richards M. (2015) Software Architecture Patterns, O’Reilly Media, Inc.
4. Lewis J., Fowler M. (2014), Microservices a definition of this new architectural term,
dostupno na https://martinfowler.com/articles/microservices.html, pristup: 6. januar, 2019.
5. Enterprise and Solution Architecture Reference Model Version 3.0 (2010), British Computer
Society, 2010, dostupno na https://www.bcs.org/upload/pdf/reference-model-enterprise-
solution-architecture.pdf, pristup: 2. februar, 2019.
6. Data (computing), Wikipedia, dostupno na :
https://en.wikipedia.org/wiki/Data_(computing), pristup: 20. januar, 2021.
7. Data Definition & Meaning, Webopedia, dostupno na :
https://www.webopedia.com/definitions/data/, pristup: 20. januar, 2021.
8. Data architecture, Wikipedia, dostupno na: https://en.wikipedia.org/wiki/Data_architecture,
pristup: 2. februar, 2019.
9. Data Structure, Wikipedia, dostupno na: https://en.wikipedia.org/wiki/Data_structure,
pristup: 20. januar, 2021.
10. ANSI-SPARC Architecture, Wikipedia, dostupno na: https://en.wikipedia.org/wiki/ANSI-
SPARC_Architecture, pristup: 20. januar, 2021.
11. Difference between Hierarchical, Network and relational Data Model, GeeksforGeeks,
dostupno na https://www.geeksforgeeks.org/difference-between-hierarchical-network-and-
relational-data-model/?ref=rp, pristupljeno: 29. januar, 2021
12. Information architecture, Wikipedia, dostupno na:
https://en.wikipedia.org/wiki/Information_architecture, pristup 31. januar, 2021
13. Dillon, A (2002). "Information Architecture in JASIST: Just where did we come
from?". Journal of the American Society for Information Science and Technology. 53 (10):
821–23. doi:10.1002/asi.10090

Poglavlje 2 - Informacioni Sistem PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Poglavlje 2 - Informacioni Sistem PDF

Uploaded by

Copyright:

Available Formats

Sadržaj

Poglavlje 2: Informacioni sistem ............................................................................................................. 2

1. Pojam informacioni sistem

2. Fundamentalni model informacionog sistema

2.1. Softver informacionog sistema

2.2. Arhitektura sistema, arhitektura informacionog sistema i

2.3. Arhitekturalni stilovi i obrasci softvera

2.3.1. Slojevita/višeslojna arhitektura

Slika 1. Zatvoreni slojevi i putanja pristupa zahteva

Slika 4. Primer primene višeslojne arhitekture

2.3.2. Događajem vođena arhitektura

Slika 6 Ilustracija načina rada medijatorske topologije

2.3.3. Arhitektura mikrojezgra

Slika 8. Arhitektura mikro-jezgra

Slika 9 Arhitektura Eclipse IDE

Slika 10. Ilustracija primene arhitekture mikro-jezgra sa posebnim plug-in komponentama za

Ukupna agilnost Visoko Promene se mogu dobro izolovati i brzo implementirati

Skalabilnost Nisko Kako je većina implementacija arhitekture mikro-jezgra

2.3.4. Mikroservisna arhitektura

6. Decentralizovano upravljanje podacima. Decentralizacija upravljanja podacima, posebno

Slika 11 Kontinualna isporuka softvera

Slika 12 Osnovni obrazac mikroservisne arhitekture

2.3.4.1. Topologije mikroservisne arhitekture

Slika 14 REST-bazirana topologija

2.3.4.2. Izbegavanje zavisnosti i orkestracije

2.3.5. Prostorno-bazirana arhitektura

Slika 16 Prostorno-bazirani arhitekturalni obrazac

2.3.5.2. Virtualizovani srednji sloj

Slika 19 Komponenta grid podataka

2.4. Arhitektura podataka

2.4.1. Konceptualni model

Slika 21 Primer jednostavnog konceptualnog modela

2.4.2. Logički model

2.4.3. Fizički model

Slika 23 Ilustrativni primer fizičkog modela podataka

2.4.4. Uporedna analiza konceptualnog, logičkog i fizičkog modela

2.4.5. Klasifikacija logičkih modela

Slika 24 Ilustracija relacionog modela podataka

Slika 25 Primer hijerarhijskog modela podataka

23 Stavka (entity)/ „strelica“ (arrow) ovde označava uređen par roditelj-dete

Slika 26 Primer mrežnog modela podataka

2.4.6. Sažeto poređenje osnovnih modela

podataka, uređenih u sekvencu.

2.5. Informaciona arhitektura

2.6. Komunikaciona arhitektura

2.6.1. TCP/IP model

Slika ??? ISO/OSI referentni model

TCP/IP model OSI model

You might also like