diplomski rad br. 1982 vrednovanje performanci web … · 2019. 8. 12. · temelju arhitekture...

SVEUČILIŠTE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

DIPLOMSKI RAD br. 1982

VREDNOVANJE PERFORMANCI

WEB-APLIKACIJE TEMELJENE NA

ARHITEKTURI MIKROUSLUGA

Branko Sirotković

Zagreb, lipanj 2019.

Sadržaj

1. Uvod ....................................................................................................................................................1

2. Arhitektura mikrousluga ................................................................................................................3

2.1. Karakteristike mikrousluga ....................................................................................................4

2.1.1. Modularizacija ........................................................................................................................4

2.1.2. Decentralizacija podataka ...................................................................................................5

2.1.3. Heterogenost i višejezičnost ..............................................................................................6

2.1.4. Pametna sučelja i jednostavna komunikacija ...............................................................7

2.1.5 Organizacija tima ....................................................................................................................8

2.1.6 Horizontalno skaliranje ...................................................................................................... 10

3. Pregled korištenih tehnologija .................................................................................................. 12

3.1. Maven ........................................................................................................................................ 12

3.2. Radni okvir Spring ................................................................................................................. 13

3.2.1. Injekcija ovisnosti i inverzija kontrole .......................................................................... 14

3.2.2. Spring Boot .......................................................................................................................... 16

3.2.3. Spring Cloud Config .......................................................................................................... 22

3.2.4. Spring Cloud Netflix .......................................................................................................... 25

3.3. Restful API ............................................................................................................................... 31

3.4. Bootstrap ................................................................................................................................. 33

3.5. Ajax i jQuery ............................................................................................................................ 33

3.6. JSON Web Token ................................................................................................................... 34

4. Online Book Store web-aplikacija ............................................................................................ 36

4.1. Neregistrirani korisnik .......................................................................................................... 36

4.2. Registrirani korisnik ............................................................................................................. 47

4.3. Izdavač ...................................................................................................................................... 52

4.4. Administrator .......................................................................................................................... 57

5. Pregled mikrousluga web-aplikacije Online Book Store .................................................... 60

5.1. Mikrousluga Config ............................................................................................................... 60

5.2. Mikrousluga Eureka Server ................................................................................................. 61

5.3. Mikrousluga Gateway ........................................................................................................... 62

5.4. Mikrousluga User Interface ................................................................................................. 64

5.5. Mikrousluga Authentication................................................................................................ 67

5.6. Mikrousluga User................................................................................................................... 69

5.7. Mikrousluga Book ................................................................................................................. 71

5.8. Mikrousluga Author .............................................................................................................. 73

5.9. Mikrousluga Subscription ................................................................................................... 74

5.10. Mikrousluga Commerce ..................................................................................................... 75

6. Vrednovanje performanci web-aplikacije Online Book Store ........................................... 77

6.1 Osnovni pojmovi teorije repova ......................................................................................... 77

6.2 Model aplikacije Online Book Store ................................................................................... 78

7. Zaključak ......................................................................................................................................... 85

8. Literatura ......................................................................................................................................... 87

Sažetak ................................................................................................................................................. 91

Summary .............................................................................................................................................. 92

1

1. Uvod

Današnji poslovni zahtjevi u svijetu traže evoluciju i prilagodbu. Napredak jedne

tehnologije ili jednog načina rada za sobom povlači lavinu promjena. Onaj koji je

sposoban prvi se prilagoditi, onaj koji prvi kapitalizira nove tehnologije te onaj koji prvi

uspije pružiti nove, revolucionarne usluge će zasigurno izaći na vrhu i ostvariti

maksimalnu korist.

Moderno društvo se sada već nekoliko desetljeća maksimalno oslanja na računarstvo

i razvoj programske podrške za svladavanje nailazećih poslovnih zahtjeva i izazova.

No vrijeme je pokazalo da naručitelji programske podrške precjenjuju dugoročnu

vrijednost svog proizvoda, nije potrebno mnogo vremena da programska podrška

postane zastarjela, a samim time i suboptimalna. Od 1981. godine troškovi

održavanja i usavršavanja programske podrške pokazuju trend konstantnog rasta,

tolikog da od 2000. godine, navedeni troškovi prelaze 90% ukupnog troška potrebnog

za razvoj programske podrške [1].

Veći problem je vidljiv danas i učestalom pojavom izraza „nasljedni kod“ (engl. legacy

code) koji predstavlja programsku podršku koja je izgrađena zastarjelim radnim

okvirima (engl. framework) ili programskim jezicima koji danas nemaju podršku svojih

izdavatelja. Nedostatak podrške, u većini slučajeva, sa sobom dovodi do sigurnosnih

ranjivosti ili grešaka. Presudna karakteristika nasljednog koda koji je još u uporabi je

njegova kompleksnost i robusnost zbog koje se izbjegava refaktoriranje čime se

propušta prilika za evoluciju programske podrške i dodavanje vrijednosti [2].

S vremenom se javlja težnja da se programska podrška od samoga početka razvija s

lakšom mogućnošću prilagodbe budućim poslovnim zahtjevima. Takav kod bi trebao

biti teško lomljiv, zrnast i prije svega slabo povezan (engl. loosely-coupled).

Osmišljeno je više inačica arhitekturnih obrazaca i načela s ovim vrijednostima u

centru pažnje, od kojih je najvrjednije spomenuti arhitekturni obrazac SOA (engl.

Service-Oriented Architecture).

Tek daljnjim napretkom tehnologija vezanih uz razvoj web-aplikacija dolazi do

mogućnosti za usavršavanje obrazaca sličnim SOA-i te 2005. godine Dr. Peter

2

Rodgers u svom izlaganju „Micro-Web-Services“ [3] postavlja temelje arhitekturnom

stilu danas poznatom kao mikrousluge. Mikrousluge se nadalje predstavljaju kao

„sitnozrnata SOA“ ili „SOA napravljena ispravno“ što nagovještava veliki broj

zajedničkih karakteristika, ali i značajni broj poboljšanja.

U 2019. godini arhitektura mikrousluga je relevantna više nego ikad što pokazuje i

istraživanje [4] Red Hat organizacije iz 2017. godine gdje 87% ispitanika odgovorilo

da koristi ili planira koristiti arhitekturu mikrousluga. Popularnost je lako vizualizirati i

pomoću Google Trends alata koji na slici 1. prikazuje da je u posljednjih godinu dana

interes za mikrousluge na svome vrhuncu [5].

Slika 1. – Relativni broj pretraživanja riječi „microservices“ Google tražilicom u

odnosu na vrijeme [5].

Ovolikom zanimanju za arhitekturni stil mikrousluga nedvojbeno su pomogle velike

tvrtke poput Amazona, Netflixa, Twittera, Ubera te mnogih ostalih koje su uspješno

implementirale mikrousluge u svoje proizvode i aplikacije. Također, Netflix i Amazon

su veoma aktivni u stvaranju rješenja otvorenog koda što je mikrousluge još više

približilo ostatku svijeta.

U nastavku ovog rada bliže će se promotriti tema arhitekture mikrousluga, koje su

njene prednosti i nedostatci, koji su joj arhitekturni stilovi prethodili te koje su

alternative. Uz ovaj rad ostvarena je web-aplikacija Online Book Store koristeći

arhitekturu mikrousluga. Opis aplikacije i njena izvedba dostupni su u nastavku rada.

3

2. Arhitektura mikrousluga

Mikrousluge su arhitekturni stil razvoja programske podrške. Glavna ideja i najbitnije

svojstvo koje programska podrška mora ispunjavati kako bi se smatrala

implementacijom arhitekture mikrousluga jest da se sastoji od više autonomnih

programskih modula ili procesa, točnije mikrousluga. Nužno svojstvo mikrousluga je

da se mogu razvijati (engl. develop), raspodjeljivati (engl. deploy) i koristiti neovisno

jedni o drugima. Svaka mikrousluga se modelira oko dijela cjelokupne poslovne

domene te se implementira u dosegu te domene. Potpuna korist i funkcionalnost

ovako definirane programske podrške će svakako proizaći iz međudjelovanja svih

mikrousluga. Međudjelovanje mikrousluga se najčešće postiže mrežnom

komunikacijom, to jest protokolom HTTP i aplikacijskim programskim sučeljima (API).

Shema arhitekture i interakcije mikrousluga usporedno s načinom interakcije

komponenti u aplikaciji monolitne arhitekture prikazana je na slici 2.

Slika 2. – Usporedba arhitekture mikrousluga (desno) s tradicionalnom monolitnom

arhitekturom (lijevo) [6].

Mikrousluge kao arhitekturni stil se u potpunosti suprotstavljaju tradicionalnom

monolitnom stilu razvoja programske podrške, a nadograđuju i usavršavaju SOA

arhitekturu. Usporedba zrnatosti tih triju stilova prikazana je na slici 3.

4

Slika 3. – Apstraktni prikaz zrnatosti tri osnovna arhitekturna stila (monolitni, SOA i

arhitektura mikrousluga) [7].

2.1. Karakteristike mikrousluga

Mikrousluge je teško egzaktno definirati, njihova pojava je relativno nova, a evoluira

upotrebom u praksi koja se odvija paralelno u različitim programskim timovima i

tvrtkama. U svim takvim instancama upotrebe mikrousluga nastat će određene razlike

i implementacijski detalji, ali osnovne značajke arhitekturnog stila bit će sveprisutne.

Kako bismo dobili bolji pregled mikrousluga u nastavku poglavlja ćemo navesti i

opisati njihove glavne karakteristike.

2.1.1. Modularizacija

U arhitekturi mikrousluga svrha je postići modularizaciju, odnosno razbiti do sada

standardni monolit u više interaktivnih komponenti. Nije lako definirati što je

komponenta i koliki bi njen doseg trebao biti, no ključna svojstva koja želimo zadržati

za komponentu su da je ona: zamjenjiva neovisno o drugim komponentama i

5

nadogradiva neovisno o drugim komponentama. Stoga mikrousluga, kao jedna

komponenta u arhitekturi mikrousluga, treba imati strogo određene granice i doseg,

svrha toga je što želimo u potpunosti izbjeći preklapanje funkcionalnosti i zavisnost

među mikrouslugama. Mikrousluga treba biti strogo vezana uz svoju domenu, a u

slučaju kada preuzme još odgovornosti i implementira više funkcionalnosti

preporučeno je rasporediti je u više mikrousluga. Amazon doseg jedne mikrousluge

opisuje: „Mikrousluga treba raditi samo jednu „stvar“, ali je treba raditi dobro“ [8].

Modularizaciju u ovom kontekstu je moguće ostvariti i u monolitnoj arhitekturi, no u

praksi se pokazalo da zahtjeva mnogo discipline te su razvojni inženjeri skloni kršenju

dogovorenih smjernica. Za usporedbu, mikrousluge komuniciraju preko dobro

definiranih sučelja te takvim dizajnom postižemo modularizaciju, koju je teško narušiti,

na prirodan način.

2.1.2. Decentralizacija podataka

Raspodjela u mikrousluge vodi do decentralizacije podataka. Na slici 4 prikazan je

tradicionalni način pristupa podacima u aplikaciji monolitne arhitekture.

Slika 4. – Shema pristupa podacima u aplikaciji monolitne arhitekture [9].

Kontrastno tome na slici 5 prikazana je decentralizirana organizacija podataka

karakteristična za arhitekturu mikrousluga. „Users“, „Messages“ i „Friends“

predstavljaju različite mikrousluge gdje je svaka odgovorna za svoju bazu podataka,

odnosno podatke u svojoj domeni.

6

Slika 5. – Shema organizacije podataka u arhitekturi mikrousluga [9].

Decentralizacija podataka je pogodna za arhitekturu mikrousluga jer povećava

modularnost i neovisnost mikrousluga u cjelokupnoj aplikaciji. U ovako postavljenoj

arhitekturi, po prirodi raspodijeljenog sustava, javlja se problem eventualne

konzistentnosti. Problem se najčešće rješava dodatnom programskom logikom koja je

zadužena za rukovanje iznimkama u konzistentnosti. Ovo je jedan od primjera zbog

kojih arhitektura mikrousluga doprinosi dodatnim komplikacijama u odnosu na

monolitnu arhitekturu, no pokazalo se da prednosti nadmašuju nedostatke

decentralizacije podataka, a jedan od glavnih razloga tema je sljedećeg poglavlja.

2.1.3. Heterogenost i višejezičnost

Razdvojenost koju postižemo arhitekturom mikrousluga dopušta nam korištenje

različitih tehnologija i programskih jezika u različitim mikrouslugama. Opće je poznato

da ne postoji programski jezik ili tehnologija koja na najbolji način može riješiti sve

probleme [10]. U praksi su prisutni slučajevi gdje bi se u razvoj projekta krenulo s

tehnologijom koja je optimalno podobna jednom modulu projekta, ali bi se ostatak

projekta morao razvijati u manje optimalnoj tehnologiji jer nas je monolitna arhitektura

vezala za nju. Mikrousluge odstranjuju taj problem jer nam dopuštaju da svaka

7

mikrousluga bude implementirana u onim tehnologijama koje su za nju optimalne. Za

programske jezike je dovoljno da mogu komunicirati na zajednički način, što je u

mikrouslugama najčešće protokol HTTP. Taj uvjet ispunjava većina programskih

jezika te nam omogućava da jedna mikrousluga bude implementirana u jeziku Java, a

druga na primjer u jeziku Python. Isto vrijedi i za programske jezike za korisnička

sučelja (engl. frontend) kao i za baze podataka. Nije rijetko da različitim

mikrouslugama, pa tako i različitim formatima podataka s kojima djeluju pogoduju

drugačiji sustavi upravljanja bazama podatka. Arhitektura mikrousluga nas

osposobljava da koristimo različite tehnologije, na primjer MySQL, MongoDB ili

PostgreSQL.

2.1.4. Pametna sučelja i jednostavna komunikacija

Prelaskom s monolitne arhitekture na arhitekturu mikrousluga pred razvojnim

inženjerima se našao izazov: kako dizajnirati komunikaciju među mikrouslugama? U

počecima razvoja aplikacija pomoću slabo povezanih komponenti naglasak je bio

postavljen na neelegantne komunikacijske protokole, odnosno komunikacijske

sabirnice. Najpoznatiji primjer neuspješne implementacije takvog sustava je

komunikacijski sustav ESB (engl. Enterprise Service Bus). Korisne funkcionalnosti je

postigao sofisticiranom suradnjom velikog broja postrojenja, no ubrzo se u praksi

pokazala sklonost jednoj točki ispada (engl. single point of failure) te kompleksnošću

pri održavanju [11]. S vremenom se javlja sklonost razvijanja programske podrške na

principu decentralizirane komunikacije pametnih sučelja i krajnjih točaka (engl. smart

endpoints). Usporedba komunikacije preko centralne sabirnice (ESB) i

decentralizirane komunikacije prikazana je na slici 6.

8

Slika 6. – Shematski prikaz komunikacije centralnom sabirnicom (lijevo) i

decentralizirane komunikacije (desno) [11].

Programska logika u krajnjim točkama je zadužena za manipulaciju tokom podataka

te konzumiranjem i stvaranjem istih. Takav princip bio je prisutan u Unix operacijskom

sustavu te je služio kao inspiracija prilikom začetaka arhitekture mikrousluga [3].

Zahtjevi postavljeni na komunikaciju su minimalni te se u arhitekturi mikrousluga kao

industrijski standardi nameću protokol HTTP zbog opće prihvaćenosti i dobro

definiranog standarda te protokoli zasnovani na lakoj (engl. lightweight) komunikaciji

poput protokola RabbitMQ.

2.1.5 Organizacija tima

Prvi faktor koji se promatra pri organizaciji razvojnog tima je njegova veličina. Jeff

Bezos, osnivač jednog od predvodnika razvoja arhitekture mikrousluga Amazona, za

opis idealne veličine tima je upotrijebio pravilo dvije pizze (engl. two pizza rule) [12],

odnosno da je idealna veličina tima ona kada ga se može nahraniti s dvije pizze.

Pravilo na simpatičan način želi naglasiti potrebu za malim timom. Opće poznato je

da je produktivnost veća u manjem timu, a i sama arhitektura mikrousluga poziva na

organizaciju timova tako da jedan mali tim bude zadužen za jednu ili neznatno veći

9

broj mikrousluga. Time se mikrousluge razvijaju onako kako i komuniciraju, preko

dobro dizajniranih i definiranih sučelja te se ostavlja malo prostora za narušavanje

slabe povezanosti mikrousluga.

Druga svojstvo koje se predlaže pri organizaciji timova prilikom razvoja aplikacije na

temelju arhitekture mikrousluga povlači se iz Conwayovog zakona (engl. Conway's

Law). Conwayev zakon [13] tvrdi da će krajnji produkt razvoja nekog tima biti preslika

strukture i organizacije unutar samog tima. Pri dosadašnjem razvoju aplikacija

monolitne i slojevite arhitekture timovi su se organizirali u odgovarajućim slojevima

(Slika 7, gore). U arhitekturi mikrousluga se stoga nametnula takva organizacija da se

u jednom timu nalaze članovi različitih sposobnosti i zaduženja (Slika 7, dolje).

Slika 7. – Usporedba organizacije timova u monolitnoj arhitekturi (gore) i u arhitekturi

mikrousluga (dolje) [14].

10

Ovakva raspodjela inženjera u timove odgovara heterogenosti mikrousluga. Na

primjer, svaki tim ima članove koji su zaduženi za perzistenciju podataka, a oni

neovisno o drugim mikrouslugama mogu odabrati najbolju tehnologiju za

implementaciju.

2.1.6 Horizontalno skaliranje

U slučaju da nam je potrebno umnožavanje programske podrške u svrhu

ujednačavanja opterećenja, povećanja skalabilnosti i dostupnosti mikrousluge se

pokazuju efektivnije u odnosu na monolitnu arhitekturu.

Svakako vrijedi da je višestruko raspodjeljivanje programske podrške temeljene na

monolitnoj arhitekturi jednostavnije za izvesti jer se raspodjeljuje identična instanca

programske podrške na više poslužitelja, primjer je prikazan lijevo na slici 8. Zbog

samo jednog modula koji je veoma resursno zahtjevan ili rijetko raspoloživ javlja se

potreba za replikacijom cijele aplikacije iako bi u tom slučaju najviše odgovarala

replikacija samo tog modula. Takav pristup moguće je ostvariti u arhitekturi

mikrousluga.

Aplikacija implementirana arhitekturom mikrousluga se može horizontalno skalirati

optimalno u odnosu na memorijski prostor tako da se repliciraju samo oni dijelovi

aplikacije koji se često pokreću te su resursno zahtjevni. Usporedba replikacija

aplikacije razvijene monolitnom arhitekturom te aplikacije razvijene arhitekturom

mikrousluga prikazana je na slici 8.

11

Slika 8. – Shematski primjeri replikacije monolitne aplikacije (lijevo) i aplikacije

mikrousluga (desno) [11].

12

3. Pregled korištenih tehnologija

U sklopu pismenog rada razvijena je web-aplikacija Online Book Store. Aplikacija je

poglavito izrađena u programskom jeziku Java, no oslanja se na veliki broj drugih

tehnologija i knjižnica otvorenog koda. U ovom poglavlju napravit će se kratki pregled

ključnih komponenti pomoću kojih je implementirana web-aplikacija Online Book

Store.

3.1. Maven

Maven je programski alat prvenstveno namijenjen za uporabu uz programski jezik

Java. Alat se pokazao korisnim za veći broj problema s kojima se Java razvojni

inženjeri susreću te je danas, uz alate Ant i Gradle, postao vodeći standard

automatizirane izgradnje Java aplikacija. Izgradnja aplikacije Maven alatom zasniva

se na Maven životnim ciklusima (engl. lifecycle): clean, default i site. Svaki od životnih

ciklusa je podesiv Maven dodacima (engl. plugins) i Maven ciljevima (engl. goals).

Prilikom razvoja Online Book Store aplikacije Maven životni ciklusi su se pozivali

sljedećom naredbom:

ključnom riječi package započeli bi izvršavanje default životnog ciklusa do istoimene

package faze. Rezultat te akcije je generiranje jar datoteka koje će se kasnije koristiti

za pokretanje programa. Ključna riječ clean briše jar datoteke nastale prijašnjim

izvršavanjima default životnog ciklusa.

Uz izgradnju aplikacija ključno svojstvo alata je upravljanje zavisnostima. Maven

omogućava brz i jednostavan način deklariranja zavisnosti o drugim Java

knjižnicama. Vanjske Java knjižnice referenciraju se s njihovim parametrima: groupId,

artifactId te version. Alat Maven tada pretražuje lokalni repozitorij te centralni Maven

repozitorij kako bi zadovoljio navedenu zavisnost.

Sve zavisnosti kao i konfiguracije samog alata navode se u pom.xml datoteci. „Project

Object Model“ datoteka centralno je mjesto svakog Maven projekta. Zavisnosti se

mvn clean package

13

definiraju između <dependencies> oznaka unutar pom.xml datoteke. U sljedećem

odsječku prikazane su neke od zavisnosti Author mikrousluge.

Službena dokumentacija alata Maven dostupna je na web adresi [15].

3.2. Radni okvir Spring

Spring je radni okvir namijenjen prvenstveno za Java programski jezik. Primarni fokus

radnog okvira postavljen je na infrastrukturnu podršku na aplikacijskom sloju te

<dependencies>

<dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-data-mongodb</artifactId>

</dependency>

<dependency>


<artifactId>spring-boot-starter-web</artifactId>

</dependency>

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>

</dependency>

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-config</artifactId>

</dependency>

<dependency>

<groupId>io.jsonwebtoken</groupId>

<artifactId>jjwt</artifactId>

<version>0.9.1</version>

</dependency>

</dependencies>

14

injekciju ovisnosti. Spring pruža veliki broj komponenti koje su spremne za uporabu

uz minimalnu konfiguraciju (engl. „Out of the box“ component) i time pojednostavljuje

posao razvojnom inženjeru olakšavajući integraciju svih komponenti potrebnih za

ostvarenje web-aplikacije [16]. Tvrtka Pivotal koja je razvila radni okvir smatra da je

pružanje izbora u svakoj fazi razvoja programske podrške jedna od njegovih temeljnih

filozofija [17]. S takvom filozofijom razvijen je fleksibilan radni okvir koji omogućava

razvoj agilnih aplikacija. Na primjer, moguće je zamijeniti tehnologiju koja se koristi za

perzistenciju podataka usred razvoja projekta bez potrebe za izmjenom postojećeg

Java koda te uz minimalnu konfiguraciju. Java razvojni inženjeri su prepoznali

prednosti ovakvih karakteristika te je Spring danas jedan od najkorištenijih web radnih

okvira, a u istraživanju kojeg je 2017. godine proveo JRebel [18] zauzimaju uvjerljivo

prvo mjesto po popularnosti Java web radnih okvira.

Cijeli Spring radni okvir složen je od većeg broja samostalnih Spring projekata te je na

razvojnom inženjeru da odabere i ukomponira projekte i pripadajuće knjižnice koje su

mu potrebne. Ovakva organizacija radnog okvira je jako pogodna uzevši u obzir da je

ostvarena potpuna kompatibilnost Springa i alata Maven te sve zavisnosti Spring

radnog okvira se na standardan način deklariraju unutar pom.xml datoteke i efektivno

dodaju u izvršnu okolinu (engl. runtime environment) aplikacije.

U nastavku će se opisati načelo injekcije ovisnosti u radnom okviru Spring (poglavlje

3.2.1), a zatim napraviti kratki pregled osnovnih Spring projekata s naglaskom na one

korištene u Online Book Store aplikaciji (poglavlja 3.2.2 – 3.2.4).

3.2.1. Injekcija ovisnosti i inverzija kontrole

Spring implementira načelo injekcije ovisnosti (engl. dependency injection). Injekcija

ovisnosti je jedna od osnovnih karakteristika modernog programskog inženjerstva

zbog prednosti koje doprinosi razvoju, a posebice testiranju programske podrške. Na

primjeru programskog jezika Java, injekciju ovisnosti postižemo tako da objekt A ne

stvara novu instancu objekta B već se očekuje da će instancu objekta B primiti kroz

konstruktor ili setter metodu. Ovako opisan način rukovanja ovisnostima u kodu se

povećanjem linija koda brzo komplicira. Spring zato injekciju ovisnosti implementira

15

koristeći princip inverzije kontrole, skraćeno IoC (engl. inversion of control). Često se

u praksi izrazi koriste kao sinonimi, no IoC stavlja važnost na svojstvo da će postojati

određena komponenta zaslužena za stvaranje objekata o kojima neka druga

komponenta zavisi i umetanje istog u zavisni objekt.

Spring implementira inverziju kontrole IoC kontejnerom. IoC kontejner čita

konfiguraciju i njene metapodatke, na temelju njih stvara bean objekte (objekte o

kojima se zavisi) te ih ubacuje u zavisne objekte u vremenu izvršavanja. Opisana

procedura prikazana je na slici 9. Generalno, IoC kontejner se brine za cjelokupni

životni ciklus bean objekata.

Slika 9. – Shematski prikaz injekcije ovisnosti u Spring radnom okviru pomoću

Spring IoC kontejnera. [19]

Deklaracija ovisnosti se može definirati na tri mjesta u Java objektu. Na varijabli

objekta, na konstruktoru te setter metodi, a deklarira se pomoću jedne od anotacija:

@Inject, @Autowired i @Resource. U Online Book Store aplikaciji korištena je

@Autowired anotacija, a primjer iz Gateway mikrousluge prikazan je u nastavku:

@Autowired

CustomPreFilter preFilter;

16

Dok je stvaranje instance razreda CustomPreFilter definirano na sljedeći način:

3.2.2. Spring Boot

Spring Boot projekt omogućava brzi razvoj samostalnih aplikacija koje se mogu

pokretati kao jar datoteke ili Spring skripte. Kao što mu samo ime implicira, Spring

Boot-om želimo postići što ranije pokretanje i efektivan rad projekta. Spring Boot

pruža veliki broj automatskih konfiguracija za osnove funkcionalnosti, kao i module

koji se odmah mogu integrirati u aplikaciju zahvaljujući njihovoj automatski zadanoj

konfiguraciji. Uz to osigurana su razna nefunkcionalna svojstva poput ugrađenih

poslužitelja (Tomcat, Jetty ili Undertow) te pristup metrikama aplikacije [20].

Za početak integracije Spring Boot-a u projekt definiramo spring-boot-starter-parent

kao „roditeljski“ projekt u pom.xml datoteci:

Iz navedenog „roditeljskog“ projekta će se automatski povlačiti korisne konfiguracije

prilikom rada na projektu te verzije ostalih Spring Boot modula koji će se dodati kao

zavisnosti u projekt.

@Configuration

public class GatewayFilterConfiguration {

@Bean

public CustomPreFilter preFilter() {

return new CustomPreFilter();

}

<parent>


<artifactId>spring-boot-starter-parent</artifactId>

<version>2.1.2.RELEASE</version>

</parent>

17

Za Spring Boot karakterističan je osnovi razred preko kojega se aplikacije pokreće.

Razred je anotiran s anotacijom @SpringBootApplication, a primjer takvog razreda

preuzetog iz User mikrousluge prikazan je u nastavku:

Razvojnim inženjerima je omogućeno uključivanje drugih Spring Boot modula u

projekt i to na jednostavan način kao Maven zavisnosti. Prepoznatljivi su po prefiksu

spring-boot-starter u identifikatoru artefakta. Slijedi pregled korištenih starter modula u

Online Book Store aplikaciji.

spring-boot-starter-web

Uključivanjem navedenog startera u projekt, omogućuje se razvoj web upravitelja

(engl. controller). U Online Book Store aplikaciji korišteni su Rest upravitelji za

izlaganje Rest API-a te MVC upravitelji za dostavljanje korisničkog sučelja u

preglednik. MVC upravitelji funkcioniraju po principu MVC obrasca (engl. Model-View-

Controller).

Razred koji predstavlja Rest upravitelj anotiran je sa @RestController. Primjer Rest

upravitelja iz Book mikrousluge:

@SpringBootApplication

public class UserServiceApplication {

public static void main(String[] args) {

ApplicationContext applicationContext =

SpringApplication.run(UserServiceApplication.class, args);

}

}

@RestController

@RequestMapping("/api/genres")

public class GenreRestEndpoints

18

@RequestMapping anotacijom definiramo putanju URL-a (engl. Uniform Resource

Locator) kojom pristupamo upravitelju. Anotacija se koristi iznad metode koja se

izvršava slanjem zahtjeva na navedenu URL putanju, no može se koristiti i na razini

razreda kao u prethodnom primjeru čime će vrijednost /api/genres biti dodana kao

prefiks ostalim definiranim putanjama unutar @RequestMapping anotaciji. Osim

putanje kao parametar anotacije može se postaviti i HTTP metoda na koju metoda

upravitelja odgovara. U odsječku su prikazane dvije metode iz GenreRestEndpoints

razreda:

@GetMapping i @PostMapping anotacije su ekvivalentne anotacijama

@RequestMapping(method = RequestMethod.GET) i @RequestMapping(method =

RequestMethod.POST).

Pomoću @RequestBody anotacije deserijalizira se tijelo HTTP zahtjeva i preslikava u

instancu razreda Genre.

@RequestHeader anotacija omogućava preslikavanje zaglavlja HTTP zahtjeva u

String objekt.

Povratna vrijednost metoda je instanca razreda ResponseEntity. ResponseEntity

predstavlja HTTP odgovor, a u metodi mu se postavlja statusni kod kao i tijelo

odgovora. Po automatskoj konfiguraciji tijelo HTTP odgovora se serijalizira u json

format te se u zaglavlje Content-Type odgovora postavlja vrijednost application/json.

MVC upravitelji u velikoj su mjeri slični Rest upraviteljima. Anotacija na razini razreda

mijenja se u @Controller dok je druga razlika povratna vrijednost upravitelja. U Online

Book Store aplikaciji MVC upravitelji vraćaju ili instancu String objekta koji predstavlja

ime HTML datoteke koju želimo vratiti kao pogled korisniku ili instancu objekta

RedirectView. Pomoću RedirectView razreda šaljemo HTTP odgovor sa statusnim

@GetMapping

public ResponseEntity getGenres()

@PostMapping

public ResponseEntity addGenre(@RequestBody Genre genre, @RequestHeader(name = "Authorization") String token)

19

kodom 300-399 čime se obavještava preglednika da preusmjeri svoj zahtjev na novo

odredište.

Na primjeru prethodne metode vrijedi primijetiti dodatnu funkcionalnost anotacije

@RequestMapping gdje je dopušteno kao dio putanje definirati varijablu, varijabla je

određena vitičastim zagradama: {id}. Ista varijabla se preslikava kao ulazni parametar

metode pomoću anotacije @PathVariable.

spring-boot-starter-thymeleaf

Ponašanje MVC upravitelja iz prethodnog poglavlja definirano je dijelom i Thymeleaf

starterom. Ovaj starter omogućava da String vrijednost koju metoda MVC upravitelja

vrati definira ime HTML datoteke koja će biti poslana kao HTTP odgovor. HTML

datoteke se po zadanome nalaze u projektu na putanji src/main/resources/templates.

Thymeleaf omogućava jednostavan način manipulacije podacima u HTML datoteci.

Podaci su Thymeleaf-u proslijeđeni preko modela kao Java objekti. U sljedećem

programskom odsječku je primjer generiranja reda tablice unutar Subscriptions

mikrousluge:

@GetMapping(path = "/author/{id}")

public String getSingleAuthorView(@PathVariable ObjectId id, HttpServletRequest request, Model model)

<th:block th:each="subscription : ${subscriptions}">

<tr>

<td th:text="${subscription.getIndex()}"></td>

<td th:text="${subscription.getType()}"></td>

<td th:text="${subscription.getValue()}"></td>

<td th:text="${subscription.getSubscriptionDate()}"></td>,

<td><a class="btn btn-outline-danger btn-sm" id="triggerCancelSubscriptionEvent" role="button">Cancel Subscription</a></td>

</tr>

</th:block>

20

spring-boot-starter-data-mongodb

spring-boot-starter-data-mongodb starter zaslužan je za integraciju aplikacije sa

MongoDB bazom podataka. Nakon dodavanja startera u pom.xml datoteku potrebno

je minimalno konfigurirati aplikaciju. U application.properties datoteci se definiraju

ugostitelj (engl. host), vrata usluge (engl. port) te ime baze podataka. Primjer iz

mikrousluge User:

Sljedeći korak je implementirati razred koji će služiti kao predložak entiteta koji se

sprema u MongoDB bazu podataka. Razred je potrebno anotirati sa @Document te u

anotaciju upisati ime MongoDB kolekcije kao na primjeru:

Kada se instanca razreda User zapisuje u MongoDB bazu, objekt se serijalizira u

JSON format principom da se par (ime_varijable, vrijednost_varijable) preslikava u

standardni JSON par (ključ: vrijednost).

Dodatne funkcionalnosti i ograničenja se postižu anotacijama na razini varijabli unutar

Java razreda kao što je prikazano na primjeru:

@Id anotacija označava varijablu koja je obavezna i jedinstvena, to je također ona

varijabla koja će se u MongoDB bazi spremiti s imenom „_id“. Spring dopušta

označavanje anotacijom @Id samo razrede String, BigInteger i ObjectId.

Anotacijom @Indexed obavještavamo MongoDB bazu podataka da izgradi indeks

nad označenim svojstvom (engl. property). Podržano je i postavljanje uvjeta na

jedinstvenost vrijednosti tog svojstva dodavanjem „unique = true“:

spring.data.mongodb.host=localhost

spring.data.mongodb.port=27017

spring.data.mongodb.database=UserDB

@Document(collection = "Users")

public class User

@Id

private ObjectId id;

21

Zadnji uvjet koji razred označen s anotacijom @Document mora ispunjavati je

postojanje getter i setter metoda za svaku varijablu kako bi Spring mogao izvršavati

serijalizaciju i deserijalizaciju.

Nakon implementacije predloška preostalo je implementirati sučelje koje ćemo koristiti

za interakciju s MongoDB bazom. U programskom odsječku nalazi se razred

UserRepository iz User mikrousluge:

Sučelje se označava anotacijom @Repository te proširuje sučelje

MongoRepository<T, String> gdje je T razred predložak, odnosno razred označen

anotacijom @Document.

Korištenje repozitorij sučelja će se pokazati jednostavno zbog IoC kontejnera Spring

radnog okvira. U Java razredu gdje želimo instancu repozitorija samo je potrebno

pozvati kontejner da je umetne, kao što je već opisano u ovome radu. Primjer

korištenja repozitorija unutar Rest upravitelja:

U samom sučelju repozitorija nužno je navesti metode koje želimo koristiti. Metode

navedene u sučelju će predstavljati MongoDB upite. Korisno svojstvo spring-boot-

starter-data-mongodb startera je da se metode za jednostavne upite pišu bez potrebe

poznavanja MongoDB upitnog jezika ako su u skladu s normama imenovanja:

@Indexed(unique = true)

private String email;

@Repository

public interface UserRespository extends MongoRepository<User, String>

@Autowired

UserRespository userRepository;

List<User> findByRole(String role);

List<User> findByUserName(String userName);

User findByEmail(String email);

User findById(BigInteger id);

22

Metode u sučelju koje predstavljaju upite su očite i lako razumljive. Postoji li potreba

za prilagođenim upitima oni se ostvaraju anotacijom @Query kao na primjeru iz Book

mikrousluge:

?0 i ?1 u MongoDB upitu će redom biti zamijenjeni za varijablama lowerPrice i

upperPrice.

3.2.3. Spring Cloud Config

Projekt Spring Cloud Config te tema sljedećeg poglavlja Spring Cloud Netflix dio su

kolekcije projekata Spring Cloud. Spring Cloud krase ista svojstva i pogodnosti kao

Spring Boot samo s naglaskom na razvoj aplikacija u raspodijeljenoj okolini. Spring

Cloud pruža „out-of-the-box“ komponente za upravljanje konfiguracijama, mrežno

usmjeravanje, registraciju usluga, raspodijeljene sjednice i mnoge druge [21]. Spring

Cloud, kao takav, odličan je alat otvorenog koda pri izradi aplikacije u arhitekturi

mikrousluga.

Spring Cloud Config pruža podršku sa strane klijenta i poslužitelja za upravljanje

vanjskim konfiguracijama. Imamo mogućnost centralizirati svu konfiguraciju na

jednom konfiguracijskom poslužitelju (engl. Config Server) [22]. Obrazac

konfiguracijskog poslužitelja pokazuje se korisnim jer omogućava da jedna

komponenta preuzme funkcijsku domenu konfiguracije. Time uspješno

implementiramo slabu povezanost, a u našem slučaju i posebnu mikrouslugu.

Prilikom razvoja web-aplikacija moguće je imati više konfiguracijskih poslužitelja za

svaku okolinu na koju se aplikacija raspodjeljuje (na primjer: razvojnu, testnu i

produkcijsku okolinu) što je čest slučaj u praksi.

Konfiguracijski poslužitelj podatke može spremati i čitati lokalno u datotekama ili iz git

repozitorija. Opcija sa git repozitorijem je implementirana u Online Book Store

aplikaciji te je pogodna za dinamičke promjene konfiguracija. Pomoću git alata i

podrške Spring-a poslužitelj prepoznaje da se konfiguracija promijenila, točnije da je

@Query("{ 'price' : { $gt: ?0, $lt: ?1 } }")

List<Book> findBooksWithPriceBetween(double lowerPrice, double upperPrice);

23

izvršena git push naredba nad repozitorijem te se zatim mikrousluge dinamički

ažuriraju. Shema je prikazana na slici 10.

Slika 10. – Shema prijenosa podataka između git repozitorija, konfiguracijskog

poslužitelja i mikrousluga. [23]

Za ostvariti konfiguracijski poslužitelj potrebno je kreirati novi Java projekt. U

application.properties datoteci projekta konfiguriramo udaljeni git repozitorij.

Konfiguracija Online Book Store konfiguracijskog poslužitelja prikazana je u nastavku:

spring.cloud.config.server.git.uri=https://github.com/bSirotkovic/bookstore-project-config

spring.cloud.config.server.git.username=bSirotkovic

spring.cloud.config.server.git.password=*********

spring.cloud.config.server.git.search-paths=config-files

24

search-paths svojstvo definira strukturu direktorija unutar git repozitorija dok su ostala

svojstva potrebna za lociranje repozitorija i autorizaciju. Pod direktorijem search-paths

nalazit će se razne <ime_mikrousluge>.properties datoteke gdje će svaka

mikrousluga čitati svojstva iz one datoteke s kojom dijeli ime.

Kako bi se konačno implementirao konfiguracijski poslužitelj potrebno je uz

uobičajenu @SpringBootApplication anotaciju nadodati i anotaciju

@EnableConfigServer.

Za postavljanje mikrousluga kao konfiguracijskih klijenata dovoljno je dodati svojstava

unutar bootstrap.properties datoteke u projektu. Primjer bootstrap.properties datoteke

User mikrousluge:

spring.application.name je svojstvo po kojemu će se povezati mikrousluga i njena

pripadajuća konfiguracija.

spring.cloud.config.uri definira URI (engl. Uniform Resource Identifier) na kojem je

pokrenut konfiguracijski poslužitelj. Ovo je jedini mogući način definiranja

konfiguracijskog poslužitelja što podrazumijeva da se mikrousluge mogu oslanjati na

samo jednu instancu poslužitelja. Isti problem je primijećen u programerskoj zajednici

te je pokrenuta rasprava na GitHub stranici projekta Spring Cloud Config [24] [25].

Zaključak rasprave je da bi konfiguracijski poslužitelj uvijek trebao biti visoke

raspoloživosti, a u slučaju ispada moguće je imati i repliku (engl. backup)

konfiguracije lokalno na mikrousluzi.

Kako bi se postiglo svojstvo dinamičnog osvježavanja konfiguracije uslijed njene

promjene potrebno je dodati @RefreshScope anotaciju nad Java razredom koji čita i

koristi svojstva iz konfiguracijskog poslužitelja.

spring.application.name=user-service

spring.cloud.config.uri=http://localhost:1111

25

3.2.4. Spring Cloud Netflix

Spring Cloud Netflix projekt integrira rješenja otvorenog koda koje je implementirala

tvrtka Netflix [26]. Funkcionalnosti se analogno drugim Spring projektima jednostavno

uključuju u aplikaciju dodavanjem zavisnosti na Spring Cloud Netflix startere. Slijedi

pregled startera korištenih u Online Book Store aplikaciji.

spring-cloud-starter-netflix-eureka-server

Pomoću navedenog startera moguće je implementirati aplikaciju koja će izvršavati

funkciju Eureka poslužitelja. Eureka poslužitelj služi kao središnja točka u arhitekturi

mikrousluga. Mikrousluge se prilikom pokretanja registriraju na Eureka poslužitelj.

Kada su mikrousluzi potrebni podaci o drugoj mikrousluzi, poput URL adrese kako bi

joj mogla poslati HTTP zahtjev, obraća se Eureka poslužitelju za te podatke.

Ovakvom arhitekturom izbjegavamo potrebu snažnog povezivanja mikrousluga te

omogućujemo jednostavnost u izvedbi horizontalne replikacije.

Kako bi se Eureka poslužitelj implementirao potrebno je postaviti

@EnableEurekaServer anotaciju nad Java razredom koji je već označen

@SpringBootApplication anotacijom.

Dodatna konfiguracija odvija se unutar application.properties datoteke:

Postavljenim svojstvima u prethodnom isječku tražimo od Eureka poslužitelja da ne

registrira sebe kao Eureka klijenta.

Eureka poslužitelj periodično šalje zahtjev svakoj od mikrousluga kako bi provjerio

jesu li i dalje aktivne i da se uvjeri da nije nastupio ispad iz mreže. Sljedećim

svojstvom se definira vrijeme u milisekundama u kojem se očekuje odgovor od

mikrousluge prije nego Eureka poslužitelj pretpostavi da je mikrousluga ispala iz

mreže.

eureka.client.register-with-eureka=false

eureka.client.fetch-registry=false

eureka.server.eviction-interval-timer-in-ms=2000

26

Implementacija Eureka klijenta započinje na sličan način, anotacijom

@EnableDiscoveryClient.

Uz to potrebno je navesti URL adresu Eureka poslužitelja u <ime-

mikrousluge>.properties datoteci poput u primjeru:

Za razliku od konfiguracijskog poslužitelja, Eureka poslužitelj posjeduje mogućnost

horizontalne replikacije. U primjeru su navedena tri poslužitelja koja obnašaju istu

funkcionalnost. Ako isto ovo svojstvo navedemo unutar application.properties

datoteke Eureka poslužitelja oni će se međusobno automatski usklađivati i

razmjenjivati podatke o prijavljenim mikrouslugama.

Cjelokupni tok podataka i komunikacija više replika Eureka poslužitelja i Eureka

klijenata, to jest mikrousluga prikazan je na slici 11.

Slika 11. – Tok podataka i komunikacije između Eureka klijenata i Eureka poslužitelja

[27].

eureka.client.serviceUrl.defaultZone=

http://localhost:2222/eureka,



27

spring-cloud-netflix-starter-zuul

Tehnologija Zuul startera se u arhitekturi mikrousluga koristi kao pristupna točka iz

vanjskog sustava u sustav aplikacije izvedene mikrouslugama. Prirodna uloga mu je

filtriranje i dinamičko usmjeravanje (engl. routing) dolaznih zahtjeva u odgovarajuću

mikrouslugu. S obzirom na to da će svaki vanjski zahtjev sigurno proći kroz pristupnik

Zuul (engl. Zuul gateway) preporučen je i za razne druge funkcionalnosti poput

autentikacije, autorizacije, testiranja na stres i ujednačavanje opterećenja [28].

Zuul je implementiran tako da dolazni zahtjevi prolaze kroz četiri tipa filtera: [29]

- Filter prije (engl. pre filter). Filter prije samoga usmjeravanja, najčešće korišten

u svrhu bilježenja dolaznih zahtjeva ili sigurnosnih razloga.

- Usmjerivački filter (engl. routing filter). Filter zaslužan za samu logiku

preusmjeravanja zahtjeva do odgovarajuće mikrousluge.

- Filter poslije (engl. post filter). Filter koji unazad prosljeđuje odgovor od

mikrousluge, najčešće služi za prikupljanje statistike i metrike uz eventualno

dodavanje HTTP zaglavlja.

- Filter za greške (engl. error filter). Filter koji se izvršava samo u slučaju da

nastupi greška prilikom rada drugih filtera.

Filter svakog tipa može biti višestruko implementiran unutar jednog Zuul pristupnika, u

tom slučaju se svakom filter pridjeljuje prioritetni broj. Kada se javi potreba za

izvršenjem pred filtera, izvršavaju se svi pred filteri slijedno po prioritetu. Prikaz

redoslijeda izvršavanja filtera unutar Zuul pristupnika prikazan je na slici 12.

28

Slika 12. – Zuul pristupnik te putanja HTTP zahtjeva kroz aplikaciju mikrousluga [30].

Zuul pristupnik se razvija kao standardna Spring Boot aplikacija uz anotaciju

@EnableZuulProxy.

Unutar gateway-service.properties datoteke definiramo pravila usmjeravanja. Kada se

Zuul pristupnik koristi bez povezanog Eureka poslužitelja pravila usmjeravanja bi

izgledala na sljedeći način:

Po pravilima iz prethodnog primjera Zuul pristupnik bi sve HTTP zahtjeve poslane na

putanje /auth/token i /auth/renew slao na mikrouslugu za autentikaciju sa URL-om

http://localhost:3333.

Zahvaljujući Eureka poslužitelju iskorištavamo njegovo svojstvo da aplikacija ne mora

poznavati egzaktne URL-ove drugih mikrousluga već se na njih prilikom pisanja

pravila usmjeravanja, referenciramo samo imenom mikrousluge, kao što je prikazano

u sljedećem odsječku:

zuul.routes.auth.token.url=http://localhost:3333

zuul.routes.auth.renew.url=http://localhost:3333

29

Za iste putanje iz prethodnog primjer: /auth/token i /auth/renew zahtjevi će biti

proslijeđeni autentikacijskoj mikrousluzi imena authentication-service.

spring-cloud-netflix-starter-ribbon

Ako se u aplikaciji koristi integracija Zuul pristupnika i Eureka preporučeno je uključiti i

spring-cloud-netflix-starter-ribbon. Ribbon služi za ujednačavanje opterećenja,

odnosno jednoliku raspodjelu dolazećih zahtjeva na replicirane mikrousluge. Ribbon

logiku uključujemo u mikrouslugu postavljajući svojstvo u

<ime-mikrousluge>.properties datoteku kao u primjeru:

Kada je ovo svojstvo postavljeno u mikrousluzi Zuul pristupnika, pristupnik će

automatski koristiti ujednačavanje opterećenja prilikom odabira jedne od repliciranih

mikrousluga.

spring-cloud-netflix-starter-feign i spring-cloud-netflix-starter-hystrix

Feign starter se nadograđuje na do sada navedene Netflix startere te omogućava

mikrousluzi konzumiranje Rest sučelja drugih mikrousluga. Feign starter, osim

dodavanjem u zavisnosti pom.xml datoteke, potrebno je aktivirati anotacijom

@EnableFeignClients. U nastavku je primjer Feign klijenta u Book mikrousluzi kojim

joj se omogućava slanje zahtjeva na Rest sučelja Authentication mikrousluge:

zuul.routes.auth-service-token.path=/auth/token

zuul.routes.auth-service-token.service-id=authentication-service

zuul.routes.auth-service-token-renew.path=/auth/renew

zuul.routes.auth-service-token-renew.service-id=authentication-service

ribbon.eureka.enabled=true

30

Pozivano Rest sučelje u Feign klijentu je deklarirano identično kao i u odgovarajućem

Rest upravljaču. U Book mikrousluzi sada je moguće stvoriti instancu razreda

AuthenticationClient pomoću @Autowired anotacije i IoC kontejnera te standardnim

Java pozivom metode poslati HTTP zahtjev na udaljenu mikrouslugu. Feign klijent

zahvaljujući integraciji sa Eureka klijentom i Zuul pristupnikom uspješno referencira

drugu mikrouslugu samo preko njenog imena kojeg se navodi u value svojstvu

anotacije @FeignClient.

Kada je spring-cloud-netflix-starter-hystrix uključen u mikrouslugu automatski je

integriran sa spring-cloud-netflix-starter-feign starterom te omogućava definiranje

rezervnog (engl. fallback) razreda Feign klijenta. Ako poziv na udaljeno Rest sučelje

nije uspješan, umjesto da dođe do prekida ili iznimke u mikrousluzi, pozvat će se

istoimena metoda fallback razreda. Primjer fallback razreda za Feign klijent iz

prethodnog primjera:

Unutar fallback razreda iznimku možemo tretirati po želji. U prethodnom primjeru, ako

dođe do ispada iz mreže Authentication mikrousluge Book mikrousluzi se vraćaju

prazni podaci o korisniku.

@FeignClient(value = "authentication-service", fallback =

AuthenticationClientFallback.class)

public interface AuthenticationClient{

@RequestMapping(method = RequestMethod.GET, value = "/auth/userinfo")

UserInfoResource getUserInfo(@RequestHeader("Authorization") String token);

}

@Component

public class AuthenticationClientFallback implements AuthenticationClient{

@Override

public UserInfoResource getUserInfo(String token){

return new UserInfoResource(new UserInfo(StringUtils.EMPTY,

StringUtils.EMPTY, StringUtils.EMPTY));

}

}

31

3.3. Restful API

Rest (Representational State Transfer) je arhitekturni stil koji definira dobre prakse i

poželjna svojstva za mrežnu komunikaciju protokolom HTTP. Aplikacijsko

programsko sučelje, skraćeno API (engl. Application Programming interface)

izgrađeno na načelima Rest-a naziva se Restful API. Pojam je predstavio i definirao

Roy Fielding 2000. godine u svojoj doktorskoj disertaciji [31]. Rest je nedugo nakon

toga postao na široko prihvaćen u programerskoj zajednici te postaje najčešći stil

izgradnje API-a, što je i potvrdilo istraživanje na jednom od najvećih neovisnih, javno

dostupnih API repozitorija (ProgrammableWeb) [32]. Grafički prikaz te tvrdnje vidljiv

je na slici 13.

Slika 13. – Raspodjela načina izgradnje API-a u ProgrammableWeb repozitorijima

[32].

Rest doživljava opću upotrebu i popularnost zbog svoje jednostavnosti, pogotovo u

odnosu na alternative: SOAP i RPC. Također, Rest se temelji na protokolu HTTP koji

je standard komunikacije preko interneta zbog čega je moguće definirati i konzumirati

Rest sučelja u gotovo svim programskim jezicima.

32

Rest je arhitekturni stil orijentiran na resurse (engl. Resource-oriented architecture),

odnosno sve što sučelje pruža je manipulacija resursima preko protokola HTTP.

Resurs adresiramo pomoću URI-a (engl. Uniform Resource Identifier) te API-u

šaljemo HTTP zahtjev na putanju određenog resursa. Dobro poznata praksa prilikom

definiranja URI-a u svom API-u je da se sastoji od imenica pomoću kojih je lako

prepoznatljivo o kojem se resursu radi. Primjer je slika 14. gdje su krajnje točke

sučelja definirane URI-jima poput /users/self te /users/user-id.

Ako pošaljemo HTTP zahtjev s metodom GET na URI /users/self kao odgovor

dobivamo informacije o korisniku koji je poslao zahtjev (samome sebi). U drugoj

krajnjoj točki user-id predstavlja varijablu te kada pošaljemo HTTP zahtjev s metodom

GET na URI /users/1000 kao odgovor dobivamo informacije o korisniku s

identifikatorom tisuću.

Slika 14. – Primjer Rest API-a i njegovih krajnjih točaka [33].

Osim dohvaćanja resursa metodom GET, Rest preporučuje korištenje drugih HTTP

metoda za manipulaciju resursom. Metode i njihove upotrebe: [33] [34]

GET – Dohvaćanje reprezentacije resursa.

HEAD – Istovjetni efekt kao i GET metoda, ali u odgovoru se ne šalje tijelo

HTTP odgovora, korisno za provjeru jeli resurs mijenjan od zadnjeg puta kada je

dohvaćan.

33

POST – Metoda za kreiranje novog resursa. Preporučena upotreba je da se

URI-jem adresira resurs koji predstavlja kolekciju u koju će se dodati novi resurs

poslan u tijelu HTTP zahtjeva.

PUT – Metoda za ažuriranje resursa, ako postoji te stvaranje resursa, ako ne

postoji. Preporučena upotreba je da se URI-jem adresira resurs koji ažuriramo ili

stvaramo.

DELETE – Metoda za brisanje resursa.

Vrijedi napomenuti da se POST i PUT metode znaju i mogu koristiti za istu svrhu, ali

preporučeno je držati se konvencije opisane iznad.

Reprezentacija resursa u HTTP zahtjevu i odgovoru može biti u proizvoljnom formatu.

Industrijski standardi su HTML, XML i JSON. API-iji koji komuniciraju u JSON formatu

se pokazuju sve popularniji zbog jednostavnosti čitanja ljudskom oku u odnosu na

alternative kao i na jednostavnost strojnog čitanja i obrade tog formata.

3.4. Bootstrap

Bootstrap je besplatni frontend programski okvir za dizajn web stranica i

web-aplikacija. Sadrži HTML i CSS (engl. Cascade Style Sheet) predloške za

tipografiju, forme, tipke, navigaciju i slične komponente. Zaslužan je za uzvratni (engl.

responsive) dizajn koji se dinamički prilagođava rezoluciji ekrana u ovisnosti na kojem

uređaju se prikazuje. Postao je moderni standard za dizajn web stranica zbog svoje

lakoće i brzine korištenja. Podržavaju ga svi najpoznatiji internet preglednici te

njegovu popularnost najbolje pokazuje činjenica da je drugi „najomiljeniji“ projekt na

GitHub-u [35]. Bootstrap sadrži i nekoliko Javascript komponenti u obliku jQuery

dodataka (engl. plugin).

3.5. Ajax i jQuery

Ajax (Asynchronous JavaScript and XML) je tehnika pristupa udaljenim web

poslužiteljima. Ajax je ostvaren pomoću Javascript skriptnog jezika koji se u ovom

34

kontekstu izvršava u web pregledniku klijenta. Uz Javascript, u imenu tehnike nalazi

se i skraćenica XML koja označava format prijenosa podataka prilikom komunikacije.

Ajax prilikom slanja asinkronog HTTP zahtjeva kreira instancu XMLHttpRequest

objekta i prosljeđuje je web poslužitelju [36]. U trenutku primanja odgovora s

udaljenog web poslužitelja Javascript obrađuje primljeni odgovor te po potrebi

prikazuje rezultate korisniku u pregledniku. Navedeni obrazac uporabe pogodan je

arhitekturi mikrousluga jer se mikrousluge međusobno predstavljaju kao udaljeni web

poslužitelji. Korist Ajax tehnike pogotovo dolazi do izražaja kod User Interface

mikrousluge u aplikaciji Online Book Store. Korisnik je u direktnoj interakciji sa User

Interface mikrouslugom kroz web preglednik i prilikom te interakcije može zatražiti

izmjenu prikazanog sadržaja. User Interface podržava taj funkcionalni zahtjev slanjem

Ajax zahtjeva na druge mikrousluge i dinamičkim osvježavanjem prikazanog sadržaja.

Za slanje Ajax zahtjeva u aplikaciji Online Book Store korištena je Java knjižnica

jQuery.

jQuery je jedna od najpoznatijih i najkorištenijih Javascript knjižnica današnjice.

Knjižnica je kompaktna, jednostavna za uključiti u svaku web-aplikaciju, a pruža veliki

broj korisnih značajki poput manipulacije HTML datotekom u web pregledniku,

rukovanje događajima (engl. event handling) te pojednostavljeni API za slanje Ajax

zahtjeva [37].

3.6. JSON Web Token

JSON Web Token ili kraće JWT je otvoreni standard koji definira kompaktan i

zaštićeni prijenos informacija u JSON formatu, to jest u obliku tokena [38]. JWT

postiže sigurnosne karakteristike šifrirajućim algoritmom proizvoljnog odabira te

digitalnim potpisom. U Online Book Store aplikaciji korišten je algoritam „HS256“ a

prilikom digitalnog potpisa koristi se simetrični ključ. U Online Book Store aplikaciji

JSON tokeni se koriste za dvije funkcionalnosti, autentikaciju korisnika te praćenje

sadržaja košarice za kupnju. Tokeni se nakon generiranja spremaju u kolačiće web

preglednika (engl. cookies). Prilikom slanja zahtjeva na druge mikrousluge token se

šalje u zaglavlju Authorization HTTP zahtjeva kako bi mikrousluge mogle autenticirati

35

korisnika od kojeg potiče zahtjev. Token za autentikaciju sadrži podatke o korisniku, a

primjer šifriranog i nešifriranog tokena prikazan je na slici 15.

Slika 15. – Primjer šifriranog i nešifriranog tokena.

U zaglavlju (engl. header) postavljena je vrijednost algoritma šifriranja. Pod Verify

Signature nalazi se metoda zaključivanja ispravnog potpisa, dok se u Payload dijelu

nalaze korisni podaci koje token sadrži. Na primjeru autentikacijskog tokena Online

Book Store aplikacije vidljivi su podaci koji se prenose, odnosno subjekt (sub)

predstavljen svojom e-mail adresom, vrijeme kreiranja tokena (iat), vrijeme isticanja

tokena (exp), uloga (role), korisničko ime (userName) i identifikator (userId) korisnika.

36

4. Online Book Store web-aplikacija

Online Book Store je aplikacija kojoj se pristupa pomoću web preglednika. Aplikacija

služi za prodaju i kupovinu knjiga u elektroničkom obliku, točnije pdf formatu. Osim

toga korisniku je pružena i opcija naručiti fizičku kopiju knjige. Uz samo trgovanje,

aplikacija pruža dodatne funkcionalnosti koje služe za konzistentno funkcioniranje

sustava poput upravljanja podacima korisnika, objavljenih knjiga i autora. Također

implementirani su razni funkcionalni i nefunkcionalni zahtjevi kako bi se korisniku

omogućio ugodan i jednostavan način korištenja aplikacije.

Korištenje aplikacije kroz web preglednik implementirano je mikrouslugom User

Interface te svi pogledi prikazani u nastavku su dio mikrousluge User Interface.

Sustav razlikuje četiri vrste dionika:

Neregistrirani korisnik – korisnik s najmanjim pravima koji je, uz mogućnost

registracije, ograničen samo na pregledne funkcionalnosti aplikacije.

Registrirani korisnik – korisnik koji se registrirao i prijavio u sustav. Registrirani

korisnik ima pravo pregledavati knjige i autore, pretplaćivati se na obavijesti o njima te

kupovati knjige.

Izdavač – korisnik koji uz standardna prava registriranoga korisnika ima pravo

dodavati knjige, autore i žanrove u aplikaciju. Također ima pravo mijenjati i brisati

navedene entitete koje je sam unio u aplikaciju. Administrator kroz aplikaciju može

registriranog korisnika promovirati u izdavača.

Administrator – korisnik koji uz sve do sada navedene ovlasti može brisati i

promovirati druge korisnike.

4.1. Neregistrirani korisnik

Neregistriranim korisnikom se smatra svaki korisnik koji pristupa web-aplikaciji bez

prijave u sustav. Na slici 16 prikazan je dijagram slučaja uporabe (engl. use case

diagram) neregistriranog korisnika.

37

Slika 16. – Dijagram slučaja uporabe neregistriranog korisnika.

U nastavku je popis pogleda kojima neregistrirani korisnik može pristupiti.

Početna stranica

Nakon što pristupi web adresi na kojoj je aplikacija dostupna neregistriranom

korisniku prikazana je početna stranica (Slika 17). Početna stranica sastoji se od

navigacijske trake na vrhu, pozdrava te grupe odabranih knjiga.

38

Slika 17. – Početna stranica Online Book Store aplikacije.

Na početnoj stranici korisniku je pružena mogućnost da se prijavi u sustav, ako je

postojeći korisnik, odnosno da se registrira u slučaju da nije postojeći korisnik. U

nastavku su prikazane odabrane knjige kako bi korisnika zainteresirale za daljnje

korištenje. Odabrane knjige su prikazane u grupama po tri, a naslovi grupa su:

„Najprodavanije knjige“, „Knjige na rasprodaji“, „Najnovije knjige“ te „Najprodavanije

knjige u elektroničkom formatu“. Grupe su prikazane na slici 18.

Slika 18. – Odabrane grupe knjiga na početnoj stranici.

39

Za svaku knjigu su navedeni osnovni podaci poput naslova, imena autora, žanrova te

slike naslovnice. Uz svaku knjigu nalazi se gumb View Details koji, ako se odabere,

preusmjerava korisnika na pogled „jedna knjiga“.

Odabirom poveznice koja se nalazi u naslovu pojedine grupe aplikacija korisnika

preusmjerava na pogled „katalog knjiga“ s predodređenim postavkama filtriranja i

sortiranja kako bi odgovarale onima u naslovu grupe. Korisnik je još u mogućnosti

pristupiti katalogu knjiga odabirom gumba u navigacijskoj traci ili upisivanjem

vrijednosti za pretragu u polje Search Books u navigacijskoj traci i pritiskom gumba

Enter na tipkovnici. Korisniku je dostupan i pogled „katalog autora“ kojemu također

pristupa pomoću gumba u navigacijskoj traci.

Prijava

Kada se korisnik odluči prijaviti na sustav, pristupa formi za prijavu pomoću poveznice

u navigacijskoj traci. Forma za prijavu je prikazana na slici 19.

Slika 19. – Forma za prijavu u Online Book Store aplikaciju.

U formu je potrebno unijeti e-mail adresu te pripadajuću lozinku s kojom se korisnik

registrirao. Prilikom ispunjavanja polja forme provodi se validacija koja provjerava jeli

e-mail adresa unesena u ispravnom formatu. Ako adresa nije u validnom e-mail

formatu tipka za prijavu je privremeno blokirana.

40

Ako uneseni podaci nisu ispravni korisniku nije omogućena prijava uz upozorenje kao

što je prikazano na slici 20.

Slika 20. – Pogled nakon neuspješne prijave u web-aplikaciju.

Ako je prijava uspješna, korisnik je preusmjeren na stranicu s koje je pristupio formi

za prijavljivanje.

Registracija

Kako bi se korisnik registrirao u Online Book Store aplikaciju prvo pristupa pogledu za

registraciju te zatim ispunjava priloženu formu koja je prikazana na slici 21. Forma se

sastoji od polja za osobne podatke kao i za podatke koji će biti korišteni prilikom

prijave.

41

Slika 21. – Forma za registraciju korisnika.

Prilikom ispunjavanja forme provodi se validacija polja Email, Zip code kao i

Password te Confirm Password. Za polje Email provjerava se ispravan format

unesene adrese elektroničke pošte, za password polja se ispituje jeli unesena

identična vrijednost u oba polja dok polje za poštanski broj dopušta samo unos brojki.

Ako validacija navedenih polja nije uspješna dugme Register je onemogućeno. Nakon

podnošenja forme korisnik će biti preusmjeren na stranicu s koje je pristupio pogledu

za registraciju u slučaju uspjeha ili obaviješten o razlogu neuspjeha te ostati na istom

pogledu. Mogući razlozi neuspjeha podnošenja forme su već registrirani korisnici s

navedenim korisničkim imenom ili e-mail adresom.

42

Katalog knjiga

Pogled katalog knjiga omogućava korisniku pregled svih knjiga objavljenih u Online

Book Store aplikaciji. Pogled se sastoji od dvije glavne komponente: liste knjiga i

kontrolne ploče za filtriranje i sortiranje spomenute liste. Lista knjiga sastoji se od pet

knjiga te navigacijske komponente kojom korisnik može tražiti da se u listu knjiga

učita sljedećih ili prethodnih pet knjiga. Dvije knjige i navigacijska traka za upravljanje

stranama prikazani su na slici 22.

Slika 22. – Dvije knjige s dna komponente liste knjiga te navigacijska traka za

upravljanje stranama.

U katalogu knjiga prikazan je veći broj podataka o knjizi nego na početnoj strani.

Navedeni su svi žanrovi kojima je knjiga označena, svi jezici na kojima je knjiga

dostupna kao i originalni datum objavljivanja knjige. Prikazani naslov i autor knjige

43

služe i kao poveznice koje preusmjeravaju korisnika na pogled „jedna knjiga“ ili

pogled „jedan autor“. Najveći dio komponente za prikaz detalja jedne knjige otpada na

kratki opis knjige dok se na dnu nalaze informacije vezane uz kupovinu. U donjem

desnom kutu nalazi se cijena knjige, a u slučaju da knjiga trenutno ima definirani

popust uz nju se nalazi i prekrižena stara cijena. U donjem lijevom kutu su gumbi za

dodavanje knjige u košaricu za kupnju te pretplatu na obavijesti o knjizi. Knjige koje

imaju samo fizičku kopiju knjige dostupnu imaju Add to Cart gumb dok knjige u

elektroničkom formatu sadrže Add eBook to Cart gumb, knjige koje podržavaju oba

formata sadrže i oba gumba. Neregistrirani korisnik prilikom odabira jednog od

gumbova za pretplatu ili dodavanje knjige u košaricu za kupnju biva preusmjeren na

pogled „prijava“.

Druga komponenta pogleda „kontrolna ploča za filtriranje i sortiranje kataloga knjiga“

nalazi se iznad komponente u kojoj su prikazane knjige. Komponenta je prikazana na

slici 23.

Slika 23. – Kontrolna ploča za filtriranje i sortiranje kataloga knjiga.

Komponenta omogućuje filtriranje knjiga po rasponu cijene, rasponu datuma

objavljivanja, žanru, dostupnom prijevodu kao i tekstualno pretraživanje naslova

knjige ili imena autora. Korisnik ima mogućnost označiti potvrdne okvire koji će filtrirati

knjige na one koje imaju elektroničku verziju, one koje imaju fizičku verziju te knjige

koje trenutno imaju aktivan popust.

44

Ispod Sort oznake korisnik može odabrati metodu sortiranja. Ponuđene vrijednosti su:

„abecedno sortiranje naslova“, „abecedno sortiranje po autorima“, „sortiranje po

datumu objavljivanja“ te „sortiranje po cijeni“.

Jedna knjiga

Kada korisnik pristupi pogledu jedne knjige putem neke od dostupnih poveznica na

uvid će imati iste podatke o knjizi kao i u katalogu knjiga. Primjer pogleda „jedna

knjiga“ dostupan je na slici 24.

Slika 24. – Pogled jedne knjige za knjigu „The Great Gatsby“.

Gumbi ispod slike djeluju jednako kao što je opisano u prethodnom pogledu.

45

Katalog autora

Pogled „katalog autora“ je implementiran analogno pogledu „katalog knjiga“. Sastoji

se od komponente za filtriranje i sortiranje te liste autora. Dio pogleda prikazan je na

slici 25.

Slika 25. – Dio pogleda „katalog autora“.

Katalog autora također sadrži pet komponenti koje prikazuju detalje o autoru te

navigacijsku traku za upravljanje stranicama. U svakoj od tih komponenti prikazana je

slika autora, njegovo ime i prezime, datum rođenja, kratki opis, materinji jezik te broj

objavljenih knjiga na Online Book Store aplikaciji. Prikazano ime i prezime služe kao

poveznica koja korisnika preusmjerava na pogled „jedan autor“. Na dnu komponente

je gumb kojim se korisnik može pretplatiti na obavijesti o izdavanju nove knjige

prikazanog autora, kao i u prijašnjim slučajevima, ako korisnik nije registriran

preusmjeren je na pogled „prijava“.

46

Komponenta za filtriranje omogućava tekstualno pretraživanje po imena i prezimenu

autora kao i po njegovom materinjem jeziku. Korisniku je pružena i opcija da odabere

jednu od metoda sortiranja od kojih su ponuđene: „abecedno po imenu autora“,

„abecedno po prezimenu autora“, „po datumu rođenja“ te „po broju objavljenih knjiga“.

Jedan autor

Otvaranjem pogleda „jedan autor“ korisnik na uvidu ima iste podatke koji su prikazani

kao i u katalogu autora. I dalje je dostupan gumb za pretplatu koji će neregistriranog

korisnika preusmjeriti na pogled „prijava“ dok će registriranog korisnika uspješno

pretplatiti. Primjer pogleda jednog autora nalazi se na slici 26.

Slika 26. – Pogled „jedan autor“ za autora Francis Scott Fitzgerald.

Neovlašten

Pokuša li neprijavljeni korisnik ili prijavljeni korisnik s neadekvatnim pravima

manualno mijenjati putanju URL-a kako bi pristupio pogledima koji su dopušteni samo

47

administratoru ili drugim registriranim korisnicima prikaže mu se pogled „neovlašten“

kao na slici 27.

Slika 27. – Upozorenje na pogledu „neovlašten“.

4.2. Registrirani korisnik

U ovom poglavlju promatramo mogućnosti korištenja aplikacije Online Book Store za

korisnika koji je uspješno izvršio procese registracije i prijave u sustav. Registrirani

korisnik zadržava sva pregledna prava koja ima i neregistrirani korisnik no pružaju mu

se mogućnosti kupovine, odnosno popunjavanja košarice za kupnju. Korisnik će svoju

kupnju finalizirati i platiti u pogledu „naplata“. Kao što je prikazano na prijašnjim

pogledima korisnik ima i mogućnost pretplatiti se na određenu knjigu ili autora. S

obzirom na to da je korisnik unio osobne podatke u aplikaciju pružen mu je i pogled

„moj profil“ gdje ima mogućnost izmjene postojećih podataka, kao i pregled svojih

pretplata te prošlih kupovina. Dijagram slučaja uporabe za registriranog korisnika

prikazan je na slici 28.

48

Slika 28. – Dijagram slučaja uporabe registriranog korisnika.

Navigacijska traka

Prva uočljiva promjena prilikom korištenja aplikacije je nova navigacijska traka.

Navigacijska traka izmijenjena je na dva mjesta. Gumbi Log In i Register zamijenjeni

su padajućim izbornikom koji prikazuje korisničko ime trenutno prijavljenog korisnika.

Odabirom padajućeg izbornika prikazuju se poveznice My Profile i Log Out. Promjene

su vidljive na slici 29. Poveznicom My Profile korisnik pristupa pogledu „moj profil“,

49

dok se s poveznicom Log Out odjavljuje s aplikacije i preusmjerava na početnu

stranicu.

Slika 29. – Desni izmijenjeni dio navigacijske trake za registriranog korisnika.

Druga promjena prikazana je na slici 30. Komponenta prikazana na slici predstavlja

košaricu za kupnju te pri svakom odabiru gumba Add to Cart na prijašnjim pogledima

dodaje odabranu knjigu u košaricu i povećava brojač koji na slici 30 trenutno ima

vrijednost 0. Stanje košarice za kupnju se pamti prilikom korištenja aplikacije i

izmjenjivanja pogleda kako bi korisnik imao što kvalitetnije iskustvo prilikom kupovine.

Komponenta je ujedno i padajući izbornik te korisniku pruža dvije poveznice: Go to

checkout koja korisnika preusmjerava na pogled „naplata“ te Clear koja prazni

košaricu za kupnju.

Slika 30. – Novi padajući izbornik u navigacijskoj traci koji predstavlja košaricu za

kupnju.

50

Naplata

Pogled za naplatu služi kako bi korisnik potvrdio odabir knjiga iz košarice za kupovinu

te naplatu istih. Kako bi korisnik izvršio kupovinu mora unijeti potrebne podatke.

Vrijedi napomenuti da u aplikaciji Online Book Store sustav naplaćivanja nije u

potpunosti implementiran već odglumljen (engl. mocked). Pogled za naplatu prikazan

je na slici 31.

Slika 31. – Pogled „naplata“ s formom na lijevoj strani te sadržajima košarice na

desnoj strani.

51

U pogledu za naplatu korisniku se prikazuju sve knjige koje je dodao u košaricu

tijekom korištenja aplikacije. Ako je košarica prazna, gumb Purchase za zaključivanje

kupovine je onemogućen za odabir. Podaci pod grupom Billing Address se svaki put

automatski ispunjavaju jer ih je korisnik unio tijekom registracije. Dok se podaci pod

Credit Card Information automatski popunjavaju tek nakon prve kupnje pri kojoj je

korisnik odabrao Save this information for next time. Nakon uspješne kupovine

korisnik se preusmjerava na svoj profil gdje uvijek može pristupiti svojim kupljenim

knjigama.

Moj profil

Zahvaljujući pogledu moj profil svaki korisnik ima centralno mjesto u aplikaciji gdje se

nalaze svi njegovi relevantni podaci. Preko pogleda „moj profil“ korisnik može

uređivati i pregledati svoje osobne podatke te podatke o kreditnoj kartici za plaćanje

te svoje kupnje i pretplate. Na pogledu s lijeve strane, kao na slici 32, nalazi se

izbornik kojim korisnik odabire jednu od spomenutih akcija.

Slika 32. – Izbornik unutar pogleda „moj profil“.

Odabirom gumba My Personal Data korisnik na uvid dobiva registracijsku formu kao

što je prikazana na slici 21, gdje ima mogućnost promijeniti svoje podatke. Odabirom

gumba My Billing Data korisnik može unijeti po prvi put ili izmijeniti podatke vezane uz

njegovu kreditnu karticu, ponuđena forma identična je Credit Card Information formi

sa slike 31. Odabirom gumba My Purchases korisniku su na uvid dani svi njegovi

kupljeni proizvodi kao što je prikazuje slika 33.

52

Slika 33. – Tablica kupljenih proizvoda u pogledu „moj profil“.

Odabirom gumba My Subscriptions korisnik može pregledati sve svoje trenutne

pretplate kao što prikazuje slika 34. Korisnik ima mogućnost i ukinuti pretplatu

odabirom gumba Cancel Subscription.

Slika 34. – Sve pretplate korisnika unutar pogleda moj profil.

4.3. Izdavač

Izdavač je registrirani korisnik kojemu je administrator dodijelio dodatna prava.

Prvenstvena uloga izdavača je objavljivanje novih knjiga u web-aplikaciju, no izdavač

ima i dodatne mogućnosti dodavanja novih autora u aplikaciju kao i žanrova.

Dijagram slučaja uporabe izdavača prikazan je na slici 35. Uz slučaje uporabe

prikazane na slici 35 izdavač sadrži i sve ovlasti i akcije koje su dane registriranom

korisniku.

53

Slika 35. – Dijagram slučaja uporabe korisnika izdavača.

Navigacijska traka

Korisnici izdavači u navigacijskoj traci imaju dodatan padajući izbornik (slika 36).

Slika 36. – Padajući izbornik Publisher Actions u navigacijskoj traci izdavača.

54

Odabirom Publish a Book poveznice unutar padajućeg izbornika izdavač je

preusmjeren na pogled „objavljivanje knjige“. Odabirom poveznice Edit Your Authors

na pogled „pregled autora izdavača“, a poveznicom Add a Genre na pogled

„upravljanje žanrovima“.

Pregled autora izdavača

U ovom pogledu izdavač dobiva na uvid sve autore koje je dodao u aplikaciju. Autori

su prikazani u tabličnom formatu kao što je prikazano na slici 37. Tablicu je moguće

pretraživati po svim vrijednostima u tablici pomoću polja Search te je moguće

odabirom ikona strelica u zaglavlju stupca sortirati vrijednosti u odabranom stupcu.

Tablici je moguće definirati koliko autora da prikazuje po stranici te upravljati prikazom

stranica u donjem desnom uglu.

Slika 37. – Prikaz autora koje je izdavač dodao u aplikaciju.

Odabirom gumba Add a new Author izdavač je preusmjeren na pogled „dodaj autora“,

dok gumb View Details preusmjerava izdavača na pogled „jedan autor“ već

prikazanog na slici 26. Prilikom pregleda pogleda „jedan autor“, za autore koje je sam

izdavač dodao u web-aplikaciju, prikazani su dodatni gumbovi Edit Your Author i

Delete Author. Odabirom gumba Edit Your Author na pregled će dobiti formu za

izmjenu podataka. Forma je ekvivalentna formi za dodavanje autora, no s već

55

popunjenim postojećim podacima. Forma za dodavanje autora prikazana je u sklopu

sljedećeg pogleda. Odabirom Delete Author autor će biti izbrisan iz aplikacije.

Dodaj autora

U ovom pogledu korisniku je pružena forma za unos podataka novog autora. Forma

je prikazana na slici 38.

Slika 38. – Forma za unos novog autora u web-aplikaciju.

Pomoću forme izdavač unosi novog autora i njegove podatke. Prilikom odabira

materinjeg jezika autora, izdavač može birati samo među postojećim jezicima u web-

aplikaciji.

Objavljivanje knjige

Trenutni pogled pruža izdavaču mogućnost da doda novu knjigu u aplikaciju Online

Book Store. U središtu pogleda nalazi se forma za dodavanje knjige. Forma je

prikazana na slici 39. Uz standardna polja tekstualnog unosa nalazi se nekoliko

padajućih izbornika. Padajući izbornik za odabir autora korisniku nudi samo one

autore koje je sam dodao u sustav. Padajući izbornici za odabir žanra i jezika

prikazuju žanrove i jezike koji su definirani u aplikaciji Online Book Store. Odabir

56

žanra i jezika za razliku od autora podržava označavanje više vrijednosti. Izdavač je

dužan odabrati barem jedan od potvrdnih okvira Include Electronic Copy i Include

Physical Copy kojima označava da su u prodaji, redom, elektronička i fizička kopija

knjige.

Slika 39. – Forma za objavljivanje nove knjige u Online Book Store aplikaciji.

Kada izdavač pristupi pogledu „jedna knjiga“ (slika 24), gdje su prikazani podaci

knjige koju je on objavio, na pogledu će se nalaziti dodatni gumbi Edit Book Details i

Unpublish Book. Odabirom Edit Book Details gumba korisnik može ponovo pristupiti

formi kao na slici 38. U tom slučaju forma je ispravno popunjena s postojećim

podacima. Gumb Unpublish Book briše knjigu iz baze podataka Book mikrousluge.

57

Upravljanje žanrovima

Izdavač ima pravo definirati nove žanrove u aplikaciji. Upravo to mu je omogućeno

pogledom „upravljanje žanrovima“. Pogled je prikazan na slici 40.

Slika 40. – Sučelje za brisanje i dodavanje žanrova.

Na dnu liste žanrova nalazi se polje za unos novog žanra te pripadajući Add gumb za

potvrdu unosa. Onemogućen je unos već postojećeg žanra. Uz svaki žanr nalazi se

gumb Erase no on je dopušten za odabir samo administratoru. Također, dopuštena je

izmjena vrijednosti postojećim žanrovima, ali kao i u slučaju brisanja, ta akcija je

dopuštena samo administratoru.

4.4. Administrator

Administrator je korisnik s najvećom razinom prava. Može obnašati funkciju

registriranog korisnika i izdavača po potrebi, brisati i izmjenjivati žanrove te brisati

knjige drugih izdavača. Administrator ima dodatne ovlasti upravljanja drugim

korisnicima, odnosno brisanjem istih iz sustava te promoviranje registriranih korisnika

u izdavače. Dijagram slučaja uporabe korisnika administratora prikazan je na slici 41.

58

Slika 41. – Dijagram slučaja uporabe administratora.

Navigacijska traka

Administratorski korisnici u navigacijskoj traci pronalaze dodatnu poveznicu.

Izmijenjena navigacijska traka prikazana je na slici 42.

Slika 42. – Navigacijska traka administratorskih korisnika.

Pritiskom na novi gumb View Users administratoru je prikazan pogled „pregled

korisnika“.

59

Pregled korisnika

Pregled korisnika je pogled kojim administrator ima pregled nad svim korisnicima.

Korisnici su prikazani u tabličnom formatu kao na slici 43.

Slika 43. – Tablica sa drugim korisnicima u pogledu „pregled korisnika“.

U tablici na slici prikazana su sva tri tipa korisnika: administrator, izdavač i registrirani

korisnik. Administrator u svome retku nema nikakve dodatne akcije dok druge

korisnike može izbrisati pomoću Delete User gumba. Uz to, može promovirati

registriranoga korisnika u izdavača, a izdavaču oduzeti dodatna prava što bi ga vratilo

u ulogu standardnog registriranog korisnika. Tablica podržava sortiranje po stupcima

te pretragu po svim vrijednostima pomoću Search polja.

60

5. Pregled mikrousluga web-aplikacije Online Book

Store

Web-aplikacija Online Book Store implementirana je arhitekturnim stilom mikrousluga,

odnosno sastoji se od deset nezavisnih modula. U ovom poglavlju je navedena svaka

od implementiranih mikrousluga kao i njene glavne karakteristike

5.1. Mikrousluga Config

Mikrousluga Config implementirana je pomoću Spring Cloud Config Server projekta

radnog okvira Spring. Za skladište properties datoteka odabran je git repozitorij kao

što je prikazano u poglavlju 3.2.3. Unutar repozitorija nalazi se deset properties

datoteka prikazanih na slici 44.

Slika 44. – Pregled datoteka u Github repozitoriju Config mikrousluge.

Svaka od preostalih mikrousluga web-aplikacije u repozitoriju pronalazi odgovarajuću

properties datoteku preko zajedničkog imena. Jedina iznimka je application.properties

datoteka koja služi za zajednička svojstva svim mikrouslugama. Datoteka sa

zajedničkim svojstvima je jako pogodna za definiranje imena mikrousluga kako bi

61

ostvarili još slabiju povezanost među mikrouslugama. Primjer učitavanja imena drugih

mikrousluga definiranih u Config mikrousluzi prikazan je u nastavku:

5.2. Mikrousluga Eureka Server

Eureka Server, kao što je opisano u poglavlju 3.2.4, drugim mikrouslugama

predstavlja centralnu točku u cijeloj web-aplikaciji. Na Eureka Server se mikrousluge

registriraju prilikom pokretanja te zahvaljujući njoj mogu doznati podatke o drugim

mikrouslugama. Eureka Server pruža sučelje za praćenje prijavljenih mikrousluga te

primjer sa svim mikrouslugama aplikacije Online Book Store je prikazan na slici 45.

Uz pojedine instance svake mikrousluge na slici su prikazane i četiri replicirane

instance Author mikrousluge.

@Component

@RefreshScope

@ConfigurationProperties

public class Properties

{

@Value("${book-service-name}")

private String bookService;

@Value("${authentication-service-name}")

private String authenticationService;

/*

getters and setters

*/

}

62

Slika 45. – Prikaz Eureka Server zadanog sučelja.

Mikrousluge prilikom rada Online Book Store aplikacije ne koriste Eureka Server

direktno već preko Feign klijenata.

5.3. Mikrousluga Gateway

Gateway mikrousluga konkretna je implementacija spring-cloud-netflix-starter-zuul

knjižnice. Namijenjena je kao centralni poslužitelj na koje vanjski korisnik šalje

zahtjeve. Nakon primanja zahtjeva Gateway preusmjerava zahtjev na ispravnu

mikrouslugu, a neposredno prije samog prosljeđivanja dodaje zaglavlje imena

gateway-header u HTTP zahtjev kojega prosljeđuje pojedinoj mikrousluzi. Zaglavlje

služi kako bi se pojedina mikrousluga uvjerila da zahtjev dolazi od strane Gateway

mikrousluge. Na primjer, mikrousluga User Interface odbija sve zahtjeve koji nisu

poslani sa Gateway mikrousluge. Vrijednost zaglavlja je šifrirana vrijednost tajnog

ključa koje poznaju samo Gateway i User Interface mikrousluge. Dodavanje zaglavlja

HTTP zahtjeva implementirano je dodatnim Zuul filterom:

@Bean

public ModifyRequestHeaderFilter preFilter() {

return new ModifyRequestHeaderFilter();

}

63

ModifyRequestHeaderFilter razred nasljeđuje ZuulFilter apstraktni razred te pruža

svoje implementacije potrebnih metode od kojih metoda run sadrži svu logiku

dodavanja zahtjeva i prikazana je u nastavku:

Logika preusmjeravanja zahtjeva u Gateway mikrousluzi nalazi se u gateway-

service.properties datoteci čiji je odsječak prikazan u nastavku:

public Object run() {

RequestContext context = RequestContext.getCurrentContext();

HttpServletResponse servletResponse = context.getResponse();

servletResponse.addHeader("gateway-header", new

BCryptPasswordEncoder().encode(SECRET_KEY));

return null;

}

zuul.sensitive-headers='*'

zuul.strip-prefix=false

zuul.routes.auth.path=/auth/token/**

zuul.routes.auth.service-id=authentication-service

zuul.routes.book.path=/api/book/**

zuul.routes.book.service-id=book-service

zuul.routes.books.path=/api/books/**

zuul.routes.books.service-id=book-service

zuul.routes.genre.path=/api/genre/**

zuul.routes.genre.service-id=book-service

zuul.routes.genres.path=/api/genres/**

zuul.routes.genres.service-id=book-service

zuul.routes.login.path=/login

zuul.routes.ui.service-id=ui-service

zuul.routes.register.path=/register

zuul.routes.ui.service-id=ui-service

64

5.4. Mikrousluga User Interface

Kraćeg naziva mikrousluga UI sadrži sve poglede i HTML datoteke koje se prikazuju

u pregledniku prilikom korištenja Online Book Store aplikacije. Mikrousluga izlaže

sljedeće krajnje točke:

GET /home

- Dohvaća početnu stranicu sa slike 17. Prilikom dohvaćanja početne stranice

mikrousluga šalje četiri zahtjeva mikrousluzi Book kako bi doznala podatke o

odabranim grupama knjiga sa slike 18.

GET /login

- Dohvaća pogled za prijavu sa slike 19.

POST /login

- Krajnja točka na koju se podnosi forma s pogleda za prijavu. Prilikom rada

upravljača za ovaj pogled UI mikrousluga šalje zahtjev na Authentication mikrouslugu

kako bi provjerila ispravnost predanih podataka. U slučaju ispravnih podataka

Authentication mikrousluga odgovara s tokenom kojeg UI mikrousluga postavlja

unutar preglednika kako se korisnik ne bi morao prijaviti svaki put kada je potrebna

autorizacije njegovog identiteta.

POST /signout

- Krajnja točka koju koristi Sign Out gumb sa slike 29. Upravljač briše token postavljen

u web pregledniku i preusmjerava korisnika na početnu stranicu.

GET /register

- Pristupom /register putanji korisniku se pruža forma za registraciju kao na slici 21.

POST /register

- Odgovarajuća krajnja točka za podnošenje forme za registraciju. UI mikrousluga

šalje POST zahtjev na User mikrouslugu kako bi se spremili podaci o korisniku.

65

GET /book-catalog i /book/{bookId}

- Krajnje točke za pristup pogledima kataloga knjiga i jedne knjige. Za nabavu

podataka o knjigama UI mikrousluga komunicira sa Book mikrouslugom. Prilikom

dodavanja knjige u košaricu za kupnju generira se token koji se sprema u web

preglednik, tek pražnjenjem košarice ili kupnjom se token briše iz preglednika. UI

mikrousluga šalje POST zahtjev Subscription mikrousluzi, ako se korisnik pretplati na

knjigu. U slučaju da je korisnik izdavač na putanji /book/{bookId} može pristupiti formi

za izmjenu podataka o knjizi.

POST /book/{bookId}

- Putanja na koju se podnosi forma prilikom dodavanja izmjene podataka o knjizi.

Podneseni podaci će biti proslijeđeni Book mikrousluzi i zapisani u njenoj bazi

podataka.

GET /author-catalog i /author/{authorId}

- Krajnje točke za pristup pogledima kataloga autora i jednog autora. Za prikaz

podataka autora UI mikrousluga mora poslati GET zahtjev Author mikrousluzi i

doznati iste podatke. U slučaju pretplate korisnika na autora UI mikrousluga šalje

POST zahtjev Subscription mikrousluzi. Kada korisnik izdavač otvori pogled na

putanji /author/{authorId} omogućen mu je i pristup formi za izmjenu podataka o

autoru.

POST /author/{authorId}

- Putanja na koju se podnosi forma prilikom izmjene podataka o autoru. Izmijenjeni

podaci prosljeđuju se u POST zahtjevu Author mikrousluzi kako bi se spremili u

Author bazu podataka.

GET /users/{userId}

- Putanja na kojoj korisnik pristupa svome profilu. UI mikrousluga šalje Ajax zahtjeve

mikrouslugama Subscription, User i Commerce u ovisnosti koje podatke korisnik

odabere za prikaz u pogledu profila. Kada korisnik odabere gumb My Personal Data

ili My Billing Data prikazuje mu se odgovarajuća forma za izmjenu podataka.

66

POST /users/{userId}/personalData

- Putanja na koju se podnosi forma prilikom izmjene osobnih podataka. Primljeni

podaci prosljeđuju se User mikrousluzi.

POST /users/{userId}/billingData

- Putanja na koju se podnosi forma prilikom izmjene podataka za naplaćivanje.

Primljeni podaci prosljeđuju se User mikrousluzi.

GET /checkout

- Pristupom navedenoj krajnjoj točki korisniku se prikazuje pogled na naplatu u

ovisnosti o trenutnoj vrijednosti tokena gdje je spremljen trenutni sadržaj košarice za

kupnju. Potrebna je komunikacija UI mikrousluge sa mikrouslugom User za

popunjavanje korisnikovih podataka i mikrouslugom Book za prikazivanje kompletnih

podataka o knjizi.

POST /checkout

- Na /checkout putanju podnosi se potvrda naplate i kupovine knjiga. Kupljene knjige i

podaci o korisniku prosljeđuju se mikrousluzi Commerce koja u bazu podataka

sprema podatke o izvršenim kupovinama.

GET /authors/{userId}

- Na /authors/{userId} putanji prikazani su svi autori trenutnog korisnika kao na slici

36. Za prikaz podataka UI mikrousluga šalje zahtjev na Author mikrouslugu.

GET /authors/add

- Na putanji /authors/add u web pregledniku se prikazuje forma za dodavanje novog

autora. Prilikom generiranja forme UI mikrousluga šalje zahtjev na Book mikrouslugu

kako bi prikazala sve podržane jezike prilikom odabira materinjeg jezika autora.

POST /authors

- Putanja na koju se podnosi forma za dodavanje novog autora. Podaci o autoru se

prosljeđuju Author mikrousluzi.

67

GET /books/add

- Putanja koja izlaže formu za dodavanje nove knjige. Kako bi se uspješno generirala

forma UI mikrousluga šalje zahtjev Author mikrousluzi za prikaz svih autora koje je

prethodno dodao trenutni korisnik, k tomu šalju se još dva zahtjeva na Book

mikrouslugu za ispravan prikaz podržanih jezika i žanrova.

POST /books

- Putanja na koju se podnosi forma za dodavanje nove knjige. Primljeni podaci se

prosljeđuju Book mikrousluzi za perzistenciju podataka.

GET /genres

- Putanja na kojoj je prikaz svih žanrova i forma za dodavanje novog žanra. UI

mikrousluga na ovoj putanji prikazuje žanrove koje je primila od Book mikrousluge.

POST /genres

- Krajnja točka na koju se podnosi forma za dodavanje, brisanje ili izmjenu vrijednosti

žanrova. Podaci o promjeni žanrova prosljeđuju se Book mikrousluzi.

GET /users

- Krajnja točka koja izlaže pogled u kojem administrator može mijenjati prava

korisnika kao i brisati ih. UI mikrousluga za prikaz točnih podataka o korisnicima prvo

šalje zahtjev User mikrousluzi.

POST /users/{userId}

- Putanja na koju se šalju podaci o izmjenama koje je administrator proveo. Dio

putanje sačinjava i ID korisnika koji je izbrisan ili čija je uloga promijenjena. Ključno je

da se isti podaci proslijede User mikrousluzi.

5.5. Mikrousluga Authentication

Određene krajnje točke aplikacije nisu namijenjene da budu dostupne svima. Na

primjer, podaci o korisniku trebaju biti raspoloživi samo tom korisniku te

68

administratoru. Krajnje točke UI mikrousluge za dodavanje novih knjiga i žanrova

trebaju biti dostupne samo korisnicima s izdavačkim pravima. Prilikom slanja zahtjeva

protokolom HTTP nekoj od mikrousluga, ako se radi o zaštićenom resursu, potrebno

je postaviti Authorization zaglavlje zahtjeva s odgovarajućim tokenom. Authentication

Mikrousluga stoga ispunjava svrhu SSO (engl. Single Sign On) poslužitelja, to jest

predstavlja centralno mjesto za generiranje i dodjeljivanje tokena. Druge mikrousluge

kao i korisnici koji direktno konzumiraju Rest sučelja Online Book Store aplikacije prije

pristupa zaštićenom resursu dužni su pribaviti token, opisana procedura prikazana je

sekvencijskim dijagramom na slici 46.

Slika 46. – Sekvencijski dijagram pribavljanja tokena prije pristupa zaštićenim

resursima.

Na slici 46 prvi tok predstavlja korisnika, a drugi tok Authentication mikrouslugu.

Posljednji tok Resource Service predstavlja sve mikrousluge koje korisniku pružaju

zaštićene krajnje točke.

69

Authentication mikrousluga pruža dvije krajnje točke, a obje služe za pribavljanje

tokena.

GET /auth/token

Korisnik ili UI mikrousluga prilikom prijave šalju zahtjev na navedenu putanju za

inicijalno generiranje tokena. Kako bi se izvršila prvotna autorizacija postavlja se

Authorization zaglavlje zahtjeva. Vrijednost zaglavlja sastoji se od ključne riječi Basic,

koja označava tip autorizacije, te šifrirane kombinacije korisničke e-mail adrese i šifre.

Primjer Authorization zaglavlja je prikazan u programskom odsječku:

GET /auth/renew

Uzevši u obzir da svaki token vrijedi sat vremena nakon njegovog generiranja ova

krajnja točka omogućava njegovo produljenje, točnije pribavljanje novog tokena

pomoću već postojećeg tokena. Već postojeći token se šalje u zaglavlju zahtjeva kao

i kod pristupa ostalim zaštićenim resursima. Primjer Authorization zaglavlja nalazi se

u sljedećem odsječku:

5.6. Mikrousluga User

Mikrousluga User zadužena je za izlaganje resursa User, odnosno podataka o

korisnicima. Mikrousluga se sastoji od sljedećih krajnjih točaka:

GET /api/users

Krajnja točka koja odgovara s listom svih korisnika u JSON formatu. U slučaju da

prilikom slanja zahtjeva nije poslan token koji odgovara administratorskom korisniku

šalje se odgovor sa statusnim kodom 403 (Forbidden). Krajnja točka podržava

Basic YnJhbmtvLnNpcm90a292aWNAZWN4LmlvOjE=

Bearer

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJicmFua28uc2lyb3Rrb3ZpY0BlY3guaW8iLCJpYXQiOjE1Nj

I1MzE5NzAsImV4cCI6MTU2MjUzNTU3MCwicm9sZSI6IkFETUlOX1VTRVIiLCJ1c2VyTmFtZSI6IkJyY

W5rb1MiLCJ1c2VySWQiOiI1ZDBlNzg0YTIwNmMzNjE1NmNkZmI2MDIifQ.ozhG4XVwigDfWQJIh78UA

omz_KbZN89LTDQv7RWwkHY

70

varijable putanje size i offset. Pomoću size varijable postavlja se maksimalna veličina

liste koja se šalje kao odgovor dok se sa offset varijablom postavlja početni odmak

liste svih korisnika.

GET /api/user/{userId}

Krajnja točka za pregled podataka korisnika referenciranog pomoću njegovog

identifikatora postavljenog u putanji zahtjeva. Za primanje uspješnog odgovora

potreban je postavljen Authorization token u zaglavlju zahtjeva koji je povezan s

administratorskim korisnikom ili korisnikom navedenog identifikatora.

POST /api/users

Krajnja točka koja služi za dodavanje novog korisnika u sustav. U tijelu zahtjeva

potrebno je predati podatke o korisniku u odgovarajućem JSON formatu za uspješno

izvršenje akcije, ako taj uvjet nije ispunjen mikrousluga odgovara sa statusnim kodom

400 (Bad Request).

PUT /api/user/{userId}

Krajnja točka za izmjenu podataka postojećeg korisnika. U tijelu zahtjeva potrebno je

predati one podatke koje se želi izmijeniti.

DELETE /api/user/{userId}

Krajnja točka za brisanje korisnika u web-aplikaciji.

Mikrousluga User koristi MongoDB bazu podataka za perzistenciju podataka o

korisnicima. Shema baze prikazana je na slici 47. Varijable korisnika, osim e-mail

varijable, su podijeljene u jedan od tri pomoćna razreda koja se koriste pri

perzistenciji u bazu. PersonalInformation sadrži osobne podatke korisnika poput

imena, prezimena, adrese, države, grada i poštanskog broja. AccountDetails sadrži

podatke vezane uz korisnički račun, poput datuma kreiranja i posljednje izmjene te

uloge i korisničkog imena. SecureInformation sadrži sve tajne informacije poput šifre i

71

podataka na kreditnoj kartici korisnika. Sve tajne informacije su šifrirane Java

razredom BCryptPasswordEncoder prije spremanja u bazu.

Slika 47. – Shema baze podataka mikrousluge Users.

5.7. Mikrousluga Book

Book mikrousluga primarno izlaže resurs Book, odnosno podatke o knjigama pomoću

Rest sučelja. Uz knjige izlaže i resurse usko povezane uz knjige: žanrove i podržane

jezike.

Podržani jezici nisu podložni promjenama preko Rest sučelja već su definirani izravno

u kodu, a moguće ih je dobiti na uvid pomoću slanja GET zahtjeva na putanju

/api/supported-languages.

Žanrove je moguće dodati slanjem POST zahtjeva na putanju /api/genres, a u tijelu

zahtjeva potrebno je postaviti identifikator žanra koji ujedno i predstavlja njegovo ime.

Za pregled, izmjenu i brisanje žanra mikrousluga Book pruža GET, PUT i DELETE

metode na putanji /api/genre/{genreId}.

72

Analogno resursu Genre, Book mikrousluga omogućava korisniku i drugim

mikrouslugama slanje GET, PUT i DELETE metoda na /api/book/{bookId} za pregled i

izmjenu podataka o knjizi ili brisanje same knjige. Uz Rest sučelja koja referenciraju

pojedinu knjigu preko njenog identifikatora, mikrousluga izlaže i krajnju točku na

putanji /api/books za rad nad skupom knjiga. Slanjem POST zahtjeva na /api/books i

odgovarajućim tijelom zahtjeva u kojem su ispravno uneseni podaci knjige u JSON

formatu moguće je dodati novu knjigu u web-aplikaciju. Slanjem GET zahtjeva na istu

putanju pošiljatelj zahtjeva kao odgovor dobiva kolekciju svih knjiga u sustavu.

Inicijalna veličina kolekcije koja se šalje u odgovoru je 100, a pomoću varijable

putanje size korisnik može definirati proizvoljnu količinu knjiga koju će mikrousluga

vratiti u odgovoru. Krajnja točka GET /api/books podržava veliki broj varijabli putanje

među kojima je i offset kojom se postavlja početni odmak prilikom dobavljanja

kolekcije knjige. Ostale varijable putanje su usko povezane uz kontrolnu ploču za

filtriranje i sortiranje prikazanu na slici 23. Varijabla putanje sort služi za postavljanje

jedne od metoda sortiranja. btmPrice i tpPrice omogućavaju filtriranje po donjoj i

gornjoj cjenovnoj granici, btmDate i tpDate po uvjetima na datum objave, title po

naslovu knjige, author po imenu autora knjige te genre i language po žanru i prijevodu

knjige. Vrijednosti varijabli putanje physical, electronic i sale se mogu samo postaviti

na true te u tom slučaju filtriraju kolekciju knjiga samo na one koje sadrže fizičku

kopiju knjige, elektroničku kopiju knjige te one knjige koje su na rasprodaji. Pomoću

varijabli putanje athrId i pblshrId mogu se zatražiti samo knjige određenog autora,

odnosno izdavača. Shema baze podataka Book mikrousluge prikazana je na slici 48.

Slika 48. – Shema baze podataka Book mikrousluge.

73

5.8. Mikrousluga Author

Mikrousluga Author vezana je uz entitet Author, to jest, autore knjiga. Sagrađena je

od Rest sučelja na dvije putanje: /api/authors i /api/author/{authorId}.

Krajnjim točkama na putanji /api/author/{authorId} omogućeno je pregledavanje i

izmjena podataka o postojećim autorima kao i brisanje autora. Za navedene

funkcionalnosti potrebno je poslati HTTP zahtjev s jednom od odgovarajućih metoda:

GET, PUT ili DELETE.

Slanjem POST zahtjeva na putanju /api/authors pružena je mogućnost dodavanja

novog autora u sustav, naravno, ako je u zahtjevu priložen token s adekvatnim

pravima. Na istoj putanji je podržana i GET metoda kojom se pribavlja kolekcija

autora kreiranih u web-aplikaciji Online Book Store. Kao i druge GET krajnje točke u

aplikaciji podržane su varijable putanje za specificiranje uvjeta filtriranja i sortiranja.

sort varijabla omogućava odabir jedne od metoda sortiranja, firstName i lastName

filtriraju uzevši u obzir ime, odnosno prezime autora. Pomoću language varijable

putanje moguće je filtrirati autore po njihovom materinjem jeziku, dok se s varijablom

pblshrId mogu zatražiti autori konkretnog izdavača.

Author mikrousluga sve podatke sprema u MongoDB bazu podataka, preciznije u

kolekciju Authors. Shema kolekcije prikazana je na slici 49.

Slika 49. – Shema baze podataka Author mikrousluge.

74

5.9. Mikrousluga Subscription

Subscription mikrousluga služi za upravljanje Subscription resursima. Navedeni

resursi predstavljaju pretplate korisnika na određenu knjigu ili autora. Mikrousluga

sprema podatke o pretplatama u MongoDB bazu podataka, točnije u kolekciju

Subscriptions. Shema kolekcije prikazana je na slici 50.

Slika 50. – Shema baze podataka Subscriptions mikrousluge.

Postoje dvije vrste pretplata te se obje spremaju u istu kolekciju. Radi li se o pretplati

na knjigu varijabla type postavljena je na vrijednost book_subscription, dok je u

drugom slučaju, kada se radi o pretplati na autora, vrijednost varijable postavljena na

author_subscription. Varijabla userId je uvijek prisutna, predstavlja identifikator

korisnika koji je pretplaćen i funkcionira kao strani ključ na bazu podataka iz

mikrousluge User. bookId i authorId su identifikatori odgovarajuće knjige ili autora na

kojeg se korisnik pretplatio, također funkcioniraju kao strani ključevi baza podataka u

mikrouslugama Book i Author, redom. Nikada nisu prisutne obje vrijednosti bookId i

authorId već samo jedna od njih, ovisno o tipu pretplate.

Mikrousluga pruža krajnju točku POST /api/subscriptions kojom se dodaje pretplata u

kolekciju. Podaci pretplate se predaju u tijelu zahtjeva.

Moguće je otkazati pretplatu slanjem zahtjeva metode DELETE na putanju

/api/subscriptions/{subscriptionId} gdje je subscriptionId identifikator pretplate.

Mikrousluga omogućava više načina dohvaćanja pretplata i to sljedećim krajnjim

točkama:

75

GET /api/subscriptions/user/{userId}

userId predstavlja identifikator korisnika, a krajnja točka vraća sve pretplate jednog

korisnika.

GET /api/subscriptions/book/{bookId}

bookId predstavlja identifikator knjige, a krajnja točka vraća sve pretplate na

referenciranu knjigu.

GET /api/subscriptions/author/{authorId}

authorId predstavlja identifikator autora, a krajnja točka vraća sve pretplate na

referenciranog autora.

5.10. Mikrousluga Commerce

Commerce mikrousluga orijentirana je oko Purchase resursa. Purchase resursi

predstavljaju procesirane kupnje korisnika, sastoje se od identifikatora korisnika,

datuma kupnje i ukupne cijene. Resurs sačinjava i lista kupljenih knjiga u toj

transakciji, a svaka referenca na knjigu ostvarena je pomoćnim razredom Book kojeg

sačinjavaju identifikator knjige te radi li se o fizičkoj ili elektroničkoj verziji. Shema

MongoDB baze podataka u kojoj se spremaju Purchase resursi prikazana je na slici

51.

Slika 51. – Shema baze podataka mikrousluge Commerce.

76

Nijedan korisnik nema prava direktno Rest sučeljima izmjenjivati sadržaje baze

podataka mikrousluge Commerce. Svi postojeći Purchase resursi ostaju zapisani do

daljnjega, a dodavanje novih moguće je samo kroz User Interface mikrouslugu i

pogled checkout. Prilikom potvrđivanja kupovine u checkout pogledu šalje se POST

zahtjev Commerce mikrousluzi na putanju /api/purchases čime se kupovina perzistira

u bazu.

Pregled prošlih kupnji je moguć registriranim korisnicima kroz pogled „moj profil“ ili

direktno Rest sučeljem na krajnjoj točki GET /api/purchases/{userId} gdje userId

predstavlja identifikator korisnika čije će kupnje mikrousluga poslati kao odgovor na

zahtjev. Administrator ima pristup dodatnoj krajnjoj točki GET /api/purchases koja kao

odgovor vraća kupovine svih korisnika.

77

6. Vrednovanje performanci web-aplikacije Online

Book Store

Vrednovanje performanci web-aplikacije ključan je korak prilikom razvoja i održavanja

raspodijeljenog sustava. Aplikaciju osim njenih funkcijskih obilježja, odnosno

mogućnosti koje pruža korisnicima, uvelike definiraju i nefunkcijska obilježja.

Nefunkcijska obilježja stavljaju naglasak na kako, a ne što, aplikacija radi. Rad

sustava obuhvaćen je pojmom kvalitete usluge (engl. Quality of Service) [39]. Jedna

od osnovnih kategorija nefunkcijskih obilježja su performance sustava. U ovom

poglavlju opisano je vrednovanje performanci Online Book Store aplikacije pomoću

teorije repova. Modeliranjem aplikacije teorijom repova stvorit će se mjerljiva preslika

stvarne web-aplikacije. Iako model neće biti u potpunosti egzaktan pružit će korisnu

podlogu za mjerenje i određivanje opterećenja kao i otkriti u kojim dijelovima sustava

je potrebno primijeniti horizontalnu replikaciju komponenti za optimalno balansiranje

opterećenja.

6.1 Osnovni pojmovi teorije repova

Kao što je definirano u radu [39] teorija repova podrazumijeva modeliranje

raspodijeljenog sustava pomoću generatora zahtjeva (vanjskog korisnika sustava),

repa za čekanje u koji se smještaju zahtjevi te poslužitelja koji odgovaraju na zahtjeve

iz repa. Ovim modelom stavlja se naglasak na trenutak dolaska zahtjeva do

poslužitelja.

Svaki model teorije repova opisuje se Kendallovom notacijom D/P/N/Y/E/F.

Jednostavan model teorijom repova prikazan je na slici 52.

Objašnjenje notacije: [39]

D – raspodjela dolazaka zahtjeva – U ovom modelu uzima se eksponencijalna

raspodjela.

Y – maksimalni broj zahtjeva – U ovom modelu pretpostavlja se da je maksimalni broj

zahtjeva neograničen, odnosno da se radi o otvorenom sustavu.

78

E – maksimalni kapacitet repa – U ovom modelu pretpostavlja se da je kapacitet repa

neograničen.

F – disciplina posluživanja – U ovom modelu odabire se FIFO (engl. first in, first out)

disciplina.

P – raspodjela posluživanja zahtjeva – U ovom modelu uzima se eksponencijalna

razdioba.

N – broj poslužitelja – Model inicijalno ostvarujemo sa osam poslužitelja. Svaki od

poslužitelja je jedinstven, a kasnije ćemo razmatrati model uz replikacije pojedinih

poslužitelja.

Slika 52. – Primjer jednostavnog modela teorije repova uz oznake Kendallove

notacije [39].

6.2 Model aplikacije Online Book Store

Model izgrađen teorijom repova kojim prikazujemo aplikaciju Online Book Store

prikazan je na slici 53.

79

Slika 53. – Model aplikacije Online Book Store izgrađen teorijom repova.

Gateway mikrousluga je prikazana na dvije lokacije u modelu zbog lakše preglednosti

no predstavlja jedan poslužitelj koji je u direktnoj komunikaciji s vanjskim korisnicima.

Vanjski korisnici šalju svoje zahtjeve na Gateway mikrouslugu te preko nje primaju

odgovore na dane zahtjeve. U modelu se ne nalaze mikrousluge Eureka i Config jer

se komunikacija između njih i ostalih mikrousluga odvija rijetko, to jest zanemarivo u

odnosu na količinu ostale komunikacije. Pristup bazama podataka pojedinačnih

mikrousluga nije modeliran već je vrijeme potrebno za čitanje i pisanje u bazu

pridodano srednjem vremenu posluživanja zahtjeva mikrousluge.

Kako bi započeli vrednovanje potrebno je procijeniti određene varijable sustava. U

tablici 1 nalaze se procijenjene vrijednosti srednjeg vremena posluživanja zahtjeva za

svaku od mikrousluga.

80

Tablica 1. – U tablici je prikazano srednje vrijeme posluživanja svake komponente.

Vrijeme je izraženo u sekundama koje su potrebne za obradu jednog zahtjevu. U

posljednjem stupcu oznaka mikrousluge nalazi se skraćenica po kojoj će se u

nastavku poglavlja referencirati svaka mikrousluga.

KOMPONENTA SREDNJE VRIJEME POSLUŽIVANJA (sekunda po zahtjevu)

OZNAKA MIKROUSLUGE

Gateway Mikrousluga 0.005 GMS

Authentication Mikrousluga 0.015 AUMS

Users Mikrousluga 0.02 USMS

Books Mikrousluga 0.04 BMS

User Interface (UI) Mikrousluga 0.01 UIMS

Commerce Mikrousluga 0.015 COMS

Subscription Mikrousluga 0.015 SUMS

Author Mikrousluga 0.025 ATMS

Za valjano vrednovanje modela u slučajevima kada se zahtjevi sa jedne mikrousluge

prosljeđuju na više potencijalnih odredišta potrebna je procjena vjerojatnosti za odabir

odredišne mikrousluge. Procijenjene vrijednosti prikazane su u tablici 2.

Tablica 2. – Procijenjene vjerojatnosti prosljeđivanja zahtjeva od polazišne prema

odredišnoj mikrousluzi.

OZNAKA POLAZIŠNE MIKROUSLUGE

OZNAKA ODREDIŠNE MIKROUSLUGE

VJEROJATNOST

GMS AUMS 0.05

GMS USMS 0.03

GMS UIMS 0.3

GMS BMS 0.1

GMS COMS 0.02

GMS SUMS 0.02

GMS ATMS 0.08

81

GMS Odgovor korisniku 0.5

AUMS USMS 0.4

AUMS

AUMS

UIMS

GMS

0.4

0.2

USMS AUMS 0.35

USMS UIMS 0.6

USMS GMS 0.05

ATMS BMS 0.3

ATMS SUMS 0.2

ATMS UIMS 0.3

ATMS GMS 0.2

UIMS

UIMS

USMS

AUMS

0.01

0.07

UIMS BMS 0.2

UIMS ATMS 0.16

UIMS COMS 0.03

UIMS SUMS 0.03

UIMS GMS 0.5

BMS ATMS 0.3

BMS SUMS 0.05

BMS COMS 0.05

BMS UIMS 0.4

BMS GMS 0.2

COMS BMS 0.2

COMS UIMS 0.7

COMS GMS 0.1

SUMS ATMS 0.2

SUMS BMS 0.2

SUMS UIMS 0.5

SUMS GMS 0.1

82

Pomoću tablice 2 moguće je odrediti intenzitet dolazaka zahtjeva na svaku od

mikrousluga gdje L označava intenzitet dolazaka zahtjeva koje vanjski korisnici šalju u

sustav, odnosno na GMS.

𝐿𝐺𝑀𝑆 = 2 ∗ 𝐿

𝐿𝐴𝑈𝑀𝑆 = 0.05 ∗ 𝐿𝐺𝑀𝑆 + 0.35 ∗ 𝐿𝑈𝑆𝑀𝑆 + 0.07 ∗ 𝐿𝑈𝐼𝑀𝑆

𝐿𝑈𝑆𝑀𝑆 = 0.03 ∗ 𝐿𝐺𝑀𝑆 + 0.4 ∗ 𝐿𝐴𝑈𝑀𝑆 + 0.01 ∗ 𝐿𝑈𝐼𝑀𝑆

𝐿𝑈𝐼𝑀𝑆 = 0.3 ∗ 𝐿𝐺𝑀𝑆 + 0.4 ∗ 𝐿𝐴𝑈𝑀𝑆 + 0.6 ∗ 𝐿𝑈𝑆𝑀𝑆 + 0.3 ∗ 𝐿𝐴𝑇𝑀𝑆 + 0.4 ∗ 𝐿𝐵𝑀𝑆 +

+ 0.7 ∗ 𝐿𝐶𝑂𝑀𝑆 + 0.5 ∗ 𝐿𝑆𝑈𝑀𝑆

𝐿𝐵𝑀𝑆 = 0.1 ∗ 𝐿𝐺𝑀𝑆 + 0.3 ∗ 𝐿𝐴𝑇𝑀𝑆 + 0.2 ∗ 𝐿𝑈𝐼𝑀𝑆 + 0.2 ∗ 𝐿𝐶𝑂𝑀𝑆 + 0.2 ∗ 𝐿𝑆𝑈𝑀𝑆

𝐿𝐶𝑂𝑀𝑆 = 0.02 ∗ 𝐿𝐺𝑀𝑆 + 0.05 ∗ 𝐿𝐵𝑀𝑆 + 0.03 ∗ 𝐿𝑈𝐼𝑀𝑆

𝐿𝑆𝑈𝑀𝑆 = 0.02 ∗ 𝐿𝐺𝑀𝑆 + 0.2 ∗ 𝐿𝐴𝑇𝑀𝑆 + 0.03 ∗ 𝐿𝑈𝐼𝑀𝑆 + 0.05 ∗ 𝐿𝐵𝑀𝑆

𝐿𝐴𝑇𝑀𝑆 = 0.08 ∗ 𝐿𝐺𝑀𝑆 + 0.3 ∗ 𝐿𝐵𝑀𝑆 + 0.16 ∗ 𝐿𝑈𝐼𝑀𝑆 + 0.2 ∗ 𝐿𝑆𝑈𝑀𝑆

Pomoću Gaussove metode eliminacije prethodnih jednadžbi uspijevamo izraziti

intenzitet dolaska zahtjeva na svakom poslužitelju preko varijable L:

𝐿𝐺𝑀𝑆 = 2 ∗ 𝐿

𝐿𝐴𝑈𝑀𝑆 = 0.2760 ∗ 𝐿

𝐿𝑈𝑆𝑀𝑆 = 0.1862 ∗ 𝐿

𝐿𝑈𝐼𝑀𝑆 = 1.5835 ∗ 𝐿

𝐿𝐵𝑀𝑆 = 0.8094 ∗ 𝐿

𝐿𝐶𝑂𝑀𝑆 = 0.1280 ∗ 𝐿

𝐿𝑆𝑈𝑀𝑆 = 0.2700 ∗ 𝐿

𝐿𝐴𝑇𝑀𝑆 = 0.7102 ∗ 𝐿

83

Pomoću Java knjižnice PDQ (Pretty Damn Quick) i definiranog modela možemo

programski izračunati nefunkcijska obilježja mikrousluga poput prosječne

iskoristivosti, propusnosti, veličine repa i srednjeg vremena odziva. Rezultati

vrednovanja pomoću alata PDQ prikazani su u tablici 3.

Tablica 3. – Vrijednosti nefunkcijskih obilježja mikrousluga Online Book Store

aplikacije za intenzitet dolaznih zahtjeva L=10 zahtjeva po sekundi.

OZNAKA MIKROUSLUGE

SREDNJE VRIJEME ODZIVA SUSTAVA (vrijeme u sekundama)

PROSJEČNA ISKORISTIVOST SUSTAVA

PROSJEČNA PROPUSNOST SUSTAVA (broj zahtjeva po sekundi)

SREDNJI BROJ ZAHTJEVA U SUSTAVU (broj zahtjeva)

GMS 0.0056s 10% 20 0.11

AUMS 0.0156s 4.1% 2.76 0.04

USMS 0.0208s 3.7% 1.86 0.03

UIMS 0.0119s 15.8% 15.84 0.19

BMS 0.0592s 32% 8.09 0.47

COMS 0.0153s 1.9% 1.28 0.01

SUMS 0.0156s 4% 2.7 0.01

ATMS 0.0304s 17.8% 7.1 0.03

Već prilikom prvog mjerenja i rezultata u tablici 3 primjetno je koje su mikrousluge pod

najvećim opterećenjem. Najopterećenija je mikrousluga Book koja obavlja koristan

posao 32% vremena. Odlučimo li se na replikaciju neke od mikrousluga, njena

prosječna iskoristivost te srednje vrijeme posluživanja opadaju u omjeru s količinom

replika koje dodajemo u sustav. Iz podataka prosječne iskoristivosti sustava moguće

je iščitati potreban broj replikacija za svaku mikrouslugu kako bi svaka mikrousluga

imala približno jednaku prosječnu iskoristivost.

Commerce mikrousluga se neće replicirati, mikrousluge Authentication, User i

Subscription će imati po dvije replike, Gateway zahtijeva pet replika, User Interface

osam, Author devet te će se na kraju Book mikrousluga sastojati od šesnaest replika.

Repliciranje će se u alatu PDQ modelirati smanjenim vremenom posluživanja tako da

84

će Book mikrousluga imati šesnaest puta brže vrijeme posluživanja u odnosu na prvo

vrednovanje. Rezultati vrednovanja nakon replikacije prikazani su u tablici 4.

Tablica 4. - Vrijednosti nefunkcijskih obilježja mikrousluga Online Book Store

aplikacije za intenzitet dolaznih zahtjeva L=10 zahtjeva po sekundi nakon provođenja

horizontalne replikacije.

OZNAKA MIKROUSLUGE

SREDNJE VRIJEME ODZIVA SUSTAVA (vrijeme u sekundama)

PROSJEČNA ISKORISTIVOST SUSTAVA

PROSJEČNA PROPUSNOST SUSTAVA (broj zahtjeva po sekundi)

SREDNJI BROJ ZAHTJEVA U SUSTAVU (broj zahtjeva)

GMS 0.001s 2% 20 0.02

AUMS 0.0077s 2% 2.76 0.02

USMS 0.0102s 1.9% 1.86 0.02

UIMS 0.0013s 2% 15.84 0.02

BMS 0.0026s 2% 8.09 0.02

COMS 0.0153s 1.9% 1.28 0.02

SUMS 0.0077s 2% 2.7 0.02

ATMS 0.0028s 2% 7.1 0.02

Ovako definiranim omjerima replikacije sveli smo svaki grozd mikrousluga na jednaku

iskoristivost te je lakše predvidjeti maksimalno opterećenje koje Online Book Store

aplikacije može podnijeti kao i kako se prilagoditi potrebama za većim opterećenjem

aplikacije. S prosječnom iskoristivošću 2% i intenzitetom dolaznih zahtjeva 10

zahtjeva po sekundi zaključuje se da Online Book Store aplikacija može uspješno

funkcionirati pod teretom od 500 dolaznih zahtjeva po sekundi. Za intenzitet veći od

500 aplikacija neće moći obnašati svoju funkciju i naći će se u nestabilnom stanju.

Ako postoji zahtjev podržati intenzitet do 1000 zahtjeva, potrebno je samo udvostručiti

broj replika svake mikrousluge.

85

7. Zaključak

Arhitekturni stil mikrousluga je nastao kao prirodni odgovor na mnoge probleme koje

je sa sobom donijela monolitna arhitektura. Uvelike olakšava ostvarenje dizajna

raspodjele zabrinutosti (engl. separation of concerns) što sa sobom povlači

jednostavnije refaktoriranje koda i prilagodbu novim poslovnim zahtjevima. U

trenutnom desetljeću u IT industriji se javlja velika pomama za implementacijom novih

i postojećih rješenja arhitekturom mikrousluga. Takva pomama za sobom povlači

razvijanje velikog broja knjižnica i tehnologija otvorenog koda koje potpomažu razvoj

aplikacija u arhitekturnom stilu mikrousluga što je zasigurno korak naprijed u svijetu

programskog inženjerstva. No ista ta pomama, po mišljenju sve većeg broja izvora na

internetu, dovodi do forsirane upotrebe arhitekturnog stila. Arhitekturni stil

mikrousluga nije pametno koristiti kao univerzalno rješenje (engl. Silver Bullet

Theorem) [10]. Monolitna arhitektura će i dalje imati svoje mjesto u svijetu

programiranja jer često nije potrebno podizati razinu kompleksnosti samo kako bi se

ispoštovao moderniji arhitekturni stil.

Monolitna arhitektura će uvijek biti pogodnije rješenje za programske podrške malog

dosega i kompleksnosti, kao što je prikazano na slici 54. Za programske podrške

male do srednje kompleksnosti sami teret raspodijeljenih sustava donosi dodatne

troškove vremena te će produktivnost tima, a samim time i rezultat, biti bolji ako se

implementira monolitna arhitektura (zelena linija na slici). U slučaju da se radi o

kompleksnijim aplikacijama, arhitektura mikrousluga će dugoročno doprinijeti većoj

produktivnosti tima, čišćem kodu i put k boljem rješenju.

86

Slika 54. – Prikaz produktivnosti (Y-os) u odnosu na kompleksnost funkcionalnih

zahtjeva programske podrške (X-os) [40].

87

8. Literatura

[1] Koskinen, J., Software Maintenance Costs, 30.04.2015.,

https://ocw.unican.es/pluginfile.php/1408/course/section/1805/SMCOSTS.pdf, Datum

pristupa: 15.06.2019.

[2] Mullen, S., Legacy isn't a Bad Word, 2019.,

https://samuelmullen.com/articles/legacy_isnt_a_bad_word/, Datum pristupa:

15.06.2019.

[3] Rodgers, P., Service-Oriented Development on NetKernel- Patterns,

Processes & Products to Reduce System Complexity, konferencija: Web Services

Edge 2005, 15.02.2005.

[4] Saavedra, C., The State of Microservices Survey 2017 – Eight trends you need

to know, 05.12.2017., https://middlewareblog.redhat.com/2017/12/05/the-state-of-

microservices-survey-2017-eight-trends-you-need-to-know/, Datum pristupa:

15.06.2019.

[5] Google Trends, https://trends.google.com/trends/explore?date=2005-10-

01%202019-01-05&q=microservices, Datum pristupa: 05.01.2019.

[6] Arsov, K., What Are Microservices, Actually?, 17.05.2017.,

https://dzone.com/articles/what-are-microservices-actually, Datum pristupa:

15.06.2019.

[7] Tuli, S., Microservices vs SOA: What's the Difference?, 16.05.2018.,

https://dzone.com/articles/microservices-vs-soa-whats-the-difference, Datum pristupa:

15.06.2019.

[8] Amazon Web Services, Inc. or its affiliates, Microservices on AWS, 09.2017.,

https://d1.awsstatic.com/whitepapers/microservices-on-aws.pdf, Datum pristupa:

15.06.2019.

[9] Peck, N., Microservice Principles: Decentralized Data Management,

14.09.2017., https://medium.com/@nathankpeck/microservice-principles-

decentralized-data-management-4adaceea173f, Datum pristupa: 15.06.2019.

https://ocw.unican.es/pluginfile.php/1408/course/section/1805/SMCOSTS.pdf

https://samuelmullen.com/articles/legacy_isnt_a_bad_word/

https://middlewareblog.redhat.com/2017/12/05/the-state-of-microservices-survey-2017-eight-trends-you-need-to-know/

https://middlewareblog.redhat.com/2017/12/05/the-state-of-microservices-survey-2017-eight-trends-you-need-to-know/

https://trends.google.com/trends/explore?date=2005-10-01%202019-01-05&q=microservices

https://trends.google.com/trends/explore?date=2005-10-01%202019-01-05&q=microservices

https://dzone.com/articles/what-are-microservices-actually

https://dzone.com/articles/microservices-vs-soa-whats-the-difference

https://d1.awsstatic.com/whitepapers/microservices-on-aws.pdf

https://medium.com/@nathankpeck/microservice-principles-decentralized-data-management-4adaceea173f

https://medium.com/@nathankpeck/microservice-principles-decentralized-data-management-4adaceea173f

88

[10] Brooks Jr., F. P., No Silver Bullet – Essence and Accident in Software

Engineering, 1986.,

http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf,

Datum pristupa: 15.06.2019.

[11] Fowler, M., Lewis, J., Microservices A definition of this new architectural term,

25.03.2014., https://martinfowler.com/articles/microservices.html, Datum pristupa:

15.06.2019.

[12] Choi, J., The Science Behind Why Small Teams Work More Productively: Jeff

Bezos' 2 Pizza Rule, 22.03.2016., https://buffer.com/resources/small-teams-why-

startups-often-win-against-google-and-facebook-the-science-behind-why-smaller-

teams-get-more-done, Datum pristupa: 15.06.2019.

[13] Conway, M. E., How do committees invent?, 04.1968., Datum pristupa:

15.06.2019.

[14] Tryfanava, D., What is Microservices Architecture?, 07.12.2017.,

https://vironit.com/what-is-microservices-architecture/, Datum pristupa: 15.06.2019.

[15] The Apache Software Foundation, Welcome to Apache Maven, 12.06.2019.,

https://maven.apache.org/, Datum pristupa: 15.06.2019.

[16] Pivotal Softvare, Inc., 2019., https://spring.io/projects/spring-framework, Datum

pristupa: 15.06.2019.

[17] Pivotal Softvare, Inc., Spring Framework Overview, 13.06.2019.,

https://docs.spring.io/spring-framework/docs/current/spring-framework-

reference/overview.html#overview, Datum pristupa: 15.06.2019.

[18] Shelajev, O., 16.02.2017., Java Web Frameworks index, February 2017,

https://jrebel.com/rebellabs/java-web-frameworks-index-by-rebellabs/, Datum pristupa:

15.06.2019.

[19] Chauhaan, N., Introduction to Spring MVC and Spring IOC, 04.12.2012.,

https://www.oodlestechnologies.com/blogs/Introduction-to-Spring-MVC-and-Spring-

IOC/, Datum pristupa: 15.06.2019.

http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf

https://martinfowler.com/articles/microservices.html

https://buffer.com/resources/small-teams-why-startups-often-win-against-google-and-facebook-the-science-behind-why-smaller-teams-get-more-done



https://vironit.com/what-is-microservices-architecture/

https://maven.apache.org/

https://spring.io/projects/spring-framework

https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/overview.html#overview

https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/overview.html#overview

https://jrebel.com/rebellabs/java-web-frameworks-index-by-rebellabs/

https://www.oodlestechnologies.com/blogs/Introduction-to-Spring-MVC-and-Spring-IOC/

https://www.oodlestechnologies.com/blogs/Introduction-to-Spring-MVC-and-Spring-IOC/

89

[20] Pivotal Softvare, Inc., Spring Boot, 2019., https://spring.io/projects/spring-boot,


[21] Pivotal Softvare, Inc., Spring Cloud, 2019., https://spring.io/projects/spring-

cloud, Datum pristupa: 15.06.2019.

[22] Pivotal Softvare, Inc., Spring Cloud Config, 2019.,

https://spring.io/projects/spring-cloud-config, Datum pristupa: 15.06.2019.

[23] Terek, H., Spring Cloud Config Server, 13.06.2018.,

https://www.programmergate.com/spring-cloud-config-server/, Datum pristupa:

15.06.2019. , Datum pristupa: 15.06.2019.

[24] GitHub, https://github.com/spring-cloud/spring-cloud-config/issues/4, Datum

pristupa: 15.06.2019.

[25] GitHub, https://github.com/spring-cloud/spring-cloud-config/issues/87, Datum

pristupa: 15.06.2019.

[26] Pivotal Softvare, Inc., Spring Cloud, 2019., https://spring.io/projects/spring-

cloud-netflix, Datum pristupa: 15.06.2019.

[27] Sarkar, A., Spring Cloud Netflix Eureka – The Hidden Manual, 18.01.2017.,

https://blog.asarkar.org/technical/netflix-eureka/, Datum pristupa: 15.06.2019.

[28] Pivotal Softvare, Inc., Router and Filter: Zuul, 2019.,

https://cloud.spring.io/spring-cloud-netflix/multi/multi__router_and_filter_zuul.html,


[29] Hawthorne, M., How it Works, 04.06.2013.,

https://github.com/Netflix/zuul/wiki/How-it-Works, Datum pristupa: 15.06.2019.

[30] Chakraborty, S., Netflix zuul example – zuul api gateway pattern – spring cloud

tutorial, https://howtodoinjava.com/spring-cloud/spring-cloud-api-gateway-zuul/,


[31] Fielding, R. T., Architectural Styles and the Design of Network-based Software

Architectures, Disertacija, University Of California, 2000.

https://spring.io/projects/spring-boot

https://spring.io/projects/spring-cloud

https://spring.io/projects/spring-cloud

https://spring.io/projects/spring-cloud-config

https://www.programmergate.com/spring-cloud-config-server/

https://github.com/spring-cloud/spring-cloud-config/issues/4

https://github.com/spring-cloud/spring-cloud-config/issues/87

https://spring.io/projects/spring-cloud-netflix

https://spring.io/projects/spring-cloud-netflix

https://blog.asarkar.org/technical/netflix-eureka/

https://cloud.spring.io/spring-cloud-netflix/multi/multi__router_and_filter_zuul.html

https://github.com/Netflix/zuul/wiki/How-it-Works

https://howtodoinjava.com/spring-cloud/spring-cloud-api-gateway-zuul/

90

[32] Levin, G., The Rise od REST API, 20.10.2015., https://blog.restcase.com/the-

rise-of-rest-api/, Datum pristupa: 15.06.2019.

[33] Mozilla, HTTP request methods, 23.03.2019., https://developer.mozilla.org/en-

US/docs/Web/HTTP/Methods, Datum pristupa: 15.06.2019.

[34] RESTfulAPI.net, REST API Tutorial, https://restfulapi.net/http-methods/, Datum

pristupa: 15.06.2019.

[35] Bootstrap Authors and Twitter, Inc., 15.06.2019,

https://github.com/twbs/bootstrap, Datum pristupa: 15.06.2019.

[36] Morris, S., AJAX—What It Is, How It Works, and What It’s Used For,

25.04.2018., https://skillcrush.com/2018/04/26/what-is-ajax/, Datum pristupa:

15.06.2019.

[37] The jQuery Foundation, 2019., https://jquery.com/, Datum pristupa:

15.06.2019.

[38] Auth0, 2019., https://jwt.io/, Datum pristupa: 15.06.2019.

[39] Podnar Žarko, I., Pripužić, K., Lovrek, I., Kušek, M., Raspodijeljeni sustavi,

radna inačica udžbenika v.1.3, 2016.

[40] Fowler, M., MicroservicePremium, 13.05.2015.,

https://martinfowler.com/bliki/MicroservicePremium.html, Datum pristupa: 15.06.2019.

https://blog.restcase.com/the-rise-of-rest-api/

https://blog.restcase.com/the-rise-of-rest-api/

https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

https://restfulapi.net/http-methods/

https://github.com/twbs/bootstrap

https://skillcrush.com/2018/04/26/what-is-ajax/

https://jquery.com/

https://jwt.io/

https://martinfowler.com/bliki/MicroservicePremium.html

91

Sažetak

VREDNOVANJE PERFORMANCI WEB-APLIKACIJE TEMELJENE NA

ARHITEKTURI MIKROUSLUGA

Mikrousluge su arhitekturni stil razvoja programske podrške. Arhitekturni stil se

zasniva na programskim modulima koji se razvijaju i raspodjeljuju neovisno jedan o

drugome, dok svoju punu funkcionalnost postižu međusobnom kolaboracijom i

komunikacijom preko računalne mreže. Mikrousluge nastaju kao odgovor na

dosadašnje arhitekturne stilove i donose razne prednosti uz određenu razinu

kompleksnosti. U sklopu rada implementirana je web-aplikacija Online Book Store

koja omogućava korisnicima kupovinu knjiga preko interneta. Aplikacija je

implementirana pomoću radnog okvira Spring s naglaskom na Spring Cloud i Spring

Cloud Netflix projekte otvorenog koda koji pružaju korisne alate za razvoj

mikrousluga. Implementiranoj aplikaciji se vrednuju nefunkcionalni zahtjevi

dostupnosti i vrijeme posluživanja teorijom repova.

Ključne riječi: mikrousluge, API, protokol HTTP, radni okvir Spring, REST, replikacija.

92

Summary

PERFORMANCE EVALUATION OF WEB APPLICATION BASED ON MICROSERVICES ARCHITECTURE

Microservices are an architectural style of software development. It is based on

software modules that are developed and deployed independently, but also achieve

their full functionality by communication and collaboration over a computer network.

Microservices were engineered as a response to already existing architectural styles

and they provide a wide range of benefits while inserting a reasonable amount of

complexity into the project. A web application Online Book Store was developed in the

microservices architectural style as a part of this thesis. The application provides

users with the ability of online book purchasing. Online Book Store was developed

using the Spring framework with emphasis on Spring Cloud and Spring Cloud Netflix

open source projects that provide tools for development of microservices. The web

application is then evaluated on performance and availability using the queueing

model.

Key words: microservices, API, protocol HTTP, Spring framework, REST, replication.

diplomski rad br. 1982 vrednovanje performanci web … · 2019. 8. 12. · temelju arhitekture...

Documents