PROGRAMSKI ALAT ZA ADMINISTRIRANJE MREŽNIH USLUGA OGLAŠAVANJA U OBLAČNOM RAČUNARSTVU

SVEUČILIŠTE JOSIPA JURJA STROSSMAYERA U OSIJEKU
ELEKTROTEHNIČKI FAKULTET

Krešimir Popović

PROGRAMSKI ALAT ZA ADMINISTRIRANJE MREŽNIH
USLUGA OGLAŠAVANJA U OBLAČNOM
RAČUNARSTVU

Magistarski rad

Osijek, 2012

PODACI O MAGISTARSKOM RADU

I. Autor
Ime i prezime Krešimir Popović

Datum i mjesto rođenja 29. rujna 1980., Osijek

Fakultet elektrotehnike i računarstva u Osijeku,
Naziv fakulteta i datum diplomiranja
27. travnja 2005

Sadašnje zaposlenje Stariji inženjer programske podrške.

II. Magistarski rad
Naslov Programski alat za administriranje mrežnih
usluga oglašavanja u oblačnom računarstvu

Broj stranica, slika, tablica, izvorni kod, Prvih 11 nenumeriranih stranica, 103
bibliografski podaci numerirane stranice, 35 slika, 27 tablica, 13
isječaka izvornog koda, 59 bibliografskih
referenci

Znanstveno područje, smjer i disciplina Tehničke znanosti, Procesno računarstvo,
iz koje je postignut akademski stupanj Računarstvo

Mentor ili voditelj rada prof.dr.sc. Željko Hocenski

Fakultet na kojem je rad obranjen Fakultet elektrotehnike i računarstva, Osijek

Oznaka i redni broj rada

III. Ocjena i obrana
Datum prihvaćanja teme od Znanstveno- 06.10.2010
nastavnog vijeća
Datum predaje rada

Datum sjednice ZNV-a na kojoj je
prihvaćena pozitivna ocjena rada

Sastav Povjerenstva koje je rad ocijenilo

Datum obrane rada

Sastav Povjerenstva pred kojim je rad obranjen

Datum promocije

SADRŽAJ
1. UVOD ...................................................................................................................................... 1
1.1. MOTIVACIJA .................................................................................................................. 1
1.2. DOSADAŠNJA ISTRAŽIVANJA ................................................................................... 2
1.3. CILJEVI RADA ............................................................................................................... 3
1.4. PLAN ISTRAŽIVANJA................................................................................................... 5
2. PREGLED SUSTAVA ZA RAZMJENU PORUKA .......................................................... 6
2.1. POJAM SPREMNIK PORUKA ....................................................................................... 6
2.2. SPREMNIK PORUKA KAO STRUKTURA PODATAKA ............................................ 6
2.3. SPREMNIK PORUKA KAO REPOZITORIJ .................................................................. 7
2.4. ARHITEKTURA STANDARDNOG JAVA PROGRAMSKOG SUČELJA ZA
RAZMJENU PORUKA ............................................................................................................... 9
2.5. PODRUČJE DJELOVANJA SUSTAVA PORUKA ..................................................... 10
2.5.1. PODRUČJE DJELOVANJA “OD TOČKE DO TOČKE”..................................... 10
2.5.2. PODRUČJE DJELOVANJA „OBJAVI-PRETPLATI“ ......................................... 11
2.5.3. PRIKUPLJANJE PORUKA ................................................................................... 12
2.6. JBOSSMQ – PRIMJER DAVATELJA STANDARDNE USLUGE JMS ..................... 16
2.7. SPREMNICI PORUKA SA VISOKOM DOSTUPNOŠĆU .......................................... 17
2.8. USLUGA AMAZON SQS ZA RAZMJENU PORUKA ................................................ 17
2.8.1. SVOJSTVA USLUGE AMAZON SQS ................................................................. 18
2.8.2. OSNOVNI PREGLED ARHITEKTURE USLUGE AMAZON SQS ................... 19
2.8.3. KAKO RADI USLUGA AMAZON SQS ? ............................................................ 20
2.8.4. HTTP(S) ZAHTJEVI I ODGOVORI ..................................................................... 24
2.8.5. IZRADA I SIGURNOST JEDNOSTAVNOG HTTP(S) ZAHTJEVA UPITA ..... 26
3. IZRADA UKUPNOG TROŠKA KORIŠTENJA USLUGE AMAZON SQS I
USPOREDBA SA UKUPNIM TROŠKOM ODRŽAVANJA POSLUŽITELJA ORACLE
WEBLOGIC – IBM WEBSPHERE .......................................................................................... 32
3.1. UKUPAN TROŠAK ODRŽAVANJA POSLUŽITELJA ORACLE WEBLOGIC - IBM
WEBSPHERE ........................................................................................................................... 32
3.2. UKUPAN TROŠAK KORIŠTENJA USLUGE AMAZON SQS ................................... 36
3.3. USPOREDBA TROŠKOVA POSLUŽITELJA ORACLE WEBLOGIC I USLUGE
AMAZON SQS.......................................................................................................................... 41
4. IZRADA ALATA ZA MJERENJE RADNIH SVOJSTAVA USLUGE AMAZON SQS
I REZULTATI MJERENJA ...................................................................................................... 45
4.1. POSTAVKE PARAMETARA ALATA ZA MJERENJE RADNIH SVOJSTAVA
USLUGE AMAZON SQS ......................................................................................................... 46
4.2. REZULTATI MJERENJA ............................................................................................. 49
5. IZRADA I NAČIN KORIŠTENJA MREŽNOG PROGRAMSKOG SUČELJA
USLUGE AMAZON SQS ZA TANKE KLIJENTE ................................................................ 54
5.1. ARHITEKTURA PROGRAMSKOG SUČELJA TANKOG KLIJENTA ..................... 60

5.2. IZRADA IMENIKA PORUKA ...................................................................................... 62
5.3. BRISANJE IMENIKA PORUKA .................................................................................. 65
5.4. LISTA SVIH DOSTUPNIH IMENIKA PORUKA ........................................................ 67
5.5. PREGLED POSTAVKI IMENIKA PORUKA .............................................................. 69
5.6. IZMJENA POSTAVKI IMENIKA PORUKA ............................................................... 72
5.7. DAVANJE PRISTUPA VANJSKIM KORISNICIMA .................................................. 75
5.8. ODUZIMANJE PRAVA VANJSKIM KORISNICIMA ................................................ 78
5.9. SLANJE PORUKE ......................................................................................................... 80
5.10. PRIKUPLJANJE PORUKA ........................................................................................... 83
5.11. BRISANJE PORUKE ..................................................................................................... 87
5.12. IZMJENA VIDLJIVOSTI PORUKE ............................................................................. 89
5.13. USPOREDBA UKUPNOG BROJA LINIJA KODA IZMEĐU SLUŽBENIH
PROGRAMSKIH ZBIRKI TVRTKE AMAZON I AS3AWSSDK.SWC ZBIRKE ................. 91
6. ZAKLJUČAK ...................................................................................................................... 93
7. LITERATURA ..................................................................................................................... 95
SAŽETAK .................................................................................................................................. 100
ABSTRACT ............................................................................................................................... 101
ŽIVOTOPIS ............................................................................................................................... 102
BIOGRAPHY ............................................................................................................................ 103

POPIS SLIKA
Slika 2.1: FIFO spremnik poruka .................................................................................................... 6
Slika 2.2: Spremnik poruka sa dva kraja ......................................................................................... 7
Slika 2.3: Izmjena poruka pomoću proizvođača – potrošača .......................................................... 8
Slika 2.4: Arhitektura standardnog Java programskog sučelja za razmjenu poruka (JMS API) .. 10
Slika 2.5: Područje djelovanja „Od točke do točke“ ..................................................................... 11
Slika 2.6: Područje djelovanja "Objavi-pretplati" (P1 – poruka; C1,C2,C3 – potvrda primitka
poruke) .......................................................................................................................................... 12
Slika 2.7: Pregled arhitekture usluge Amazon SQS ...................................................................... 20
Slika 2.8: Slanje poruke u spremnik poruka (akcija SendMessage) ............................................. 21
Slika 2.9: Prikupljanje poruka iz spremnika poruka (akcija ReceiveMessage)............................. 22
Slika 2.10: Prikupljanje poruka A, B, C; D iz spremnika poruka (akcija ReceiveMessage) ........ 22
Slika 2.11: Vremensko ograničenje nevidljivosti poruke (akcija ChangeMessageVisibility) ...... 23
Slika 2.12: Brisanje poruke 'A' iz spremnika poruka unutar vremenskog ograničenja nevidljivosti
poruke (akcija DeleteMessage) ..................................................................................................... 23
Slika 2.13: Niz koji treba biti potpisan .......................................................................................... 26
Slika 2.14: Primjer niza koji je potrebno potpisati ........................................................................ 27
Slika 2.15: Primjer potpisanog HTTP(s) zahtjeva ........................................................................ 27
Slika 2.16: Odobrenje (autorizacija) i provjera valjanosti (autentifikacija) klijenata pomoću
usluge Amazon IAM ..................................................................................................................... 29
Slika 2.17: Primjer postavki dozvole usluge Amazon SQS za spremnik poruka „Test“ .............. 30
Slika 3.1: Ukupni troškovi posjedovanja poslužitelja WebLogic i WebSphere [41].................... 33
Slika 3.2: Usporedba cjenika Oracle WebLogic-IBM WebSphere-Amazon SQS sustava za
razmjenu poruka ............................................................................................................................ 41
Slika 3.3: Grafički alat AWSAdminTool 1.0.1 za promjenu postavki usluge Amazon SQS ....... 44
Slika 4.1: Primjer međusobno povezanih heterogenih SOA sustava ............................................ 45
Slika 4.2: Simulacija proizvođača (izvršena sa parametrom -p) ................................................... 49
Slika 4.3: Simulacija potrošača (izvršena sa parametrom -c) ....................................................... 49
Slika 4.4: Prikaz prikupljanja poruka u deset mjernih intervala ................................................... 52
Slika 4.5: Prikaz slanja poruka u deset mjernih intervala ............................................................. 52
Slika 5.1: Grafičko i programsko sučelje za upravljanje uslugom Amazon SQS ......................... 55
Slika 5.2: Sigurnost Adobe Flash Playera (2007 / 2008 godina) [51]........................................... 56
Slika 5.3: Globalna rasprostranjenost Adobe Flash Player na kućnim računalima [52] ............... 57
Slika 5.4: Globalna rasprostranjenost Flash Playera na pametnim telefonima [53] ..................... 58
Slika 5.5: Skup modela programskog sučelja Amazon SQS ........................................................ 60
Slika 5.6: Primjer ListQueues parametara odgovora .................................................................... 68
Slika 5.7: Primjer GetQueueAttributes parametara odgovora ...................................................... 72
Slika 5.8: Akcija AddPermission daje ograničeni pristup vanjskim korisnicima (trećoj strani) .. 75
Slika 5.9: Primjer GetQueueAttributes parametara odgovora ...................................................... 81
Slika 5.10: Primjer ReceiveMessage parametara odgovora .......................................................... 85

POPIS TABLICA
Tablica 2.1: Imenski prostor usluge Amazon SQS ....................................................................... 20
Tablica 2.2: Lista obaveznih parametara za Amazon SQS HTTP(s) zahtjeve.............................. 24
Tablica 2.3: Tijelo HTTP zahtjeva nadgledano od Wireshark alata za nadgledanje IP prometa .. 28
Tablica 2.4: Tijelo HTTP odgovora nadgledano od Wireshark alata za nadgledanje IP prometa 28
Tablica 3.1: Usporedba svojstava poslužitelja Oracle WebLogic i usluge Amazon SQS ............ 34
Tablica 3.2: Cjenik izlaznog Internet prometa usluge Amazon SQS od 01.07.2011 [43] ............ 37
Tablica 4.1: Popis računalnih komponenti korištenih za testiranje radnih svojstava usluge
Amazon SQS ................................................................................................................................. 46
Tablica 4.2: Postavke parametara alata za mjerenje radnih svostava usluge Amazon SQS ......... 47
Tablica 4.3: Rezultati mjerenja radnih svojstava usluge Amazon SQS ........................................ 50
Tablica 5.1: CreateQueue parametri zahtjeva ............................................................................... 62
Tablica 5.2: CreateQueue parametri odgovora ............................................................................. 62
Tablica 5.3: Primjer CreateQueue zahtjeva i odgovora koristeći sučelje Wireshark za praćenje
mrežnog prometa ........................................................................................................................... 64
Tablica 5.4: DeleteQueue parametri zahtjeva ............................................................................... 65
Tablica 5.5: ListQueues parametri zahtjeva .................................................................................. 67
Tablica 5.6: ListQueues parametri odgovora ................................................................................ 67
Tablica 5.7: GetQueueAttributes parametri zahtjeva .................................................................... 69
Tablica 5.8: GetQueueAttributes parametri odgovora .................................................................. 70
Tablica 5.9: SetQueueAttributes parametri zahtjeva..................................................................... 73
Tablica 5.10: AddPermission parametri zahtjeva ......................................................................... 75
Tablica 5.11: RemovePermission parametri zahtjeva ................................................................... 78
Tablica 5.12: SendMessage parametri zahtjeva ............................................................................ 80
Tablica 5.13: SendMessage parametri odgovora .......................................................................... 80
Tablica 5.14: ReceiveMessage parametri zahtjeva ....................................................................... 83
Tablica 5.15: ReceiveMessage parametri odgovora ..................................................................... 84
Tablica 5.16: DeleteMessage parametri zahtjeva .......................................................................... 87
Tablica 5.17: ChangeMessageVisibility parametri zahtjeva ......................................................... 89
Tablica 5.18: Rezultat usporedbe SLOC metrike između programskih sučelja Amazon SDK i
as3awsSDK. Usporedba se odnosi na izvorni kod prisutan u „com.amazonaws.services.sqs.*“
paketu. Za mjerenje korišten je Apache CLOC 1.53. ................................................................... 91

POPIS IZVORNOG KODA TANKOG KLIJENTA
Izvorni kod tankog klijenta 5.1: Primjer korištenja akcije CreateQueue ...................................... 63
Izvorni kod tankog klijenta 5.2: Primjer korištenja akcije DeleteQueue ...................................... 66
Izvorni kod tankog klijenta 5.3: Primjer korištenja akcije ListQueues ......................................... 68
Izvorni kod tankog klijenta 5.4: Primjer korištenja akcije GetQueueAttributes ........................... 71
Izvorni kod tankog klijenta 5.5: Primjer korištenja akcije SetQueueAttributes ........................... 74
Izvorni kod tankog klijenta 5.6: Primjer korištenja akcije AddPermission .................................. 77
Izvorni kod tankog klijenta 5.7: Primjer korištenja akcije RemovePermission ............................ 79
Izvorni kod tankog klijenta 5.8: Primjer korištenja akcije SendMessage ..................................... 82
Izvorni kod tankog klijenta 5.9: Primjer korištenja akcije ReceiveMessage ................................ 86
Izvorni kod tankog klijenta 5.10: Primjer korištenja akcije DeleteMessage................................. 88
Izvorni kod tankog klijenta 5.11: Primjer korištenja akcije ChangeMessageVisibility ................ 90

POPIS IZVORNOG JAVA KODA
Izvorni Java kod 2.1: Sinkroni način rada primatelja poruka opisan izvornim Java kodom JMS
sučelja ............................................................................................................................................ 13
Izvorni Java kod 2.2: Asinkroni način rada primatelja poruka opisan izvornim Java kodom JMS
sučelja ............................................................................................................................................ 15

PRILOZI

Svi prilozi su računalni programi koji su pod stalnim promjenama vlasnika licence.

Prilog 3.1: Izvorni kod AWSAdminTool 1.0.1 grafičkog alata,
https://bitbucket.org/Kresimir/awsadmintool/overview

Prilog 4.1: Izvorni kod Java alata za mjerenje radnih svojstava Amazon SQS usluge,
https://bitbucket.org/Kresimir/awsproducerconsumertool

Prilog 5.1: Izvorni kod mrežnog programskog sučelja izrađenog u Actionscript 3.0 jeziku,
https://bitbucket.org/Kresimir/as3awssdk/overview

POPIS KRATICA
Popis sadrži samo one kratice koje se općenito koriste u računarstvu, dok su specifične kratice,
kao dio komercijalnih naziva za različite tehnologije i proizvode objašnjene u tekstu rada.

Amazon IAM AWS Identity and Access Management

Amazon SQS Amazon Simple Queue Service

API Application Programming Interface

AWS Amazon Web Services

CIO Chief Information Officer

ENISA European Network and Information Security Agency

EU European Union

FIFO First in First Out

HA High Availability

HMAC Hash-based Message Authentication Code

HTML HyperText Markup Language

HTTP Hypertext Transfer Protocol

HTTPS Hypetext Transfer Protocol Secure

IIOP Internet Intert-ORB Protocol

ISO International Organization for Standardization

IT Information Technology

JavaEE Java Enterprise Edition

JMS Java Message Service

JNDI Java Naming and Directory Interface

JSR Java Specification Requests

JVM Java Virtual Machine

MD5 Message Digest Algorithm

MOM Message Oriented Middleware

PaaS Platform as a Service

QoS Quality of Service

RAM Random Access Memory

RESTful Representational state transfer

RIA Rich Inaternet Application

RMI Remote Method Invocation

SAML Security Assertion Markup Language

SHA Secure Hash Algorithm

SLOC Source lines of code

SMS Short Message Service

SOA Service oriented architecture

SSO Singe Sign-on

TCO Total Cost of Ownership

URL Uniform Resource Locator

UTC Coordinated Universal Time

UTF-8 Unicide Transformation Format

1. UVOD

U ovom poglavlju bit će razmotreni čimbenici i motivacija koji su utjecali na nastanak ovoga
rada te korisnost znanstvenicima koji se bave ovom domenom, poslovnim stručnjacima i
organizacijama (malim i srednjim tvrtkama, javnim institucijama). Sadržaj poglavlja poslužiti će
kao uvod u uslugu oblačnog računarstva (Amazon SQS) – primarnu temu ovog rada – te će se
okvirno opisati postavljeni ciljevi istraživanja. Važno je unaprijed naglasiti tri značajke ovoga
rada:

1. Tema rada je komercijani računalni oblak tvrtke Amazon, a ne privatni niti akademski
računalni oblaci izvedeni na sveučilištima (samostalno ili u suradnji s privatnim
sektorom). To znači da zaključci izvedeni u ovom radu, posebice oni vezani za
ekonomiku i programsko sučelje sustava za razmjenu poruka vrijede prije svega za
uslugu Amazon SQS.
2. Uglavnom će se uspoređivati način korištenja, složenost i ekonomičnost uporabe usluge
oblačnog računarstva (Amazon SQS) u odnosu na postojeća rješenja unutar kuće (on-
premise).
3. Izrađena je klijentska zbirka Amazon SQS u objektno-orijentiranom programskom jeziku
Actionscript 3.0 zasnovanom na standardu ECMAScript ECMA-262. Zbirka se može
iskoristiti kao univerzalno prenosivo programsko sučelje za više različitih vrsta
klijentskih računalnih sustava.

1.1. Motivacija

Smatra se da su računalni oblaci i SOA tehnološki komplementarni pojmovi u smislu da
računalni oblaci predstavljaju povoljnu platformu za pokretanje i izvođenje SOA usluga [1].
SOA oblačni sustav za razmjenu poruka Amazon SQS [2] je relativno nova komponenta PaaS
koja je prvi puta predstavljena 2006 godine od strane tvrtke Amazon. Još uvijek je u fazi
inkrementalnog razvoja i poboljšanja. Omogućuje razvojnim inženjerima da povezuju (loose
coupling of services) različite SOA usluge koje mogu međusobno nezavisno rasti bez obzira na
veličinu i postavke spremnika poruka. Budući da su istraživanja u ovome polju prilično skromna
(a ovdje su opisana u potpoglavlju 1.2) ovim radom se želi dati odgovarajući doprinos na polju
povezivanja tankih klijenata [3] s konceptom računalnih oblaka.

1

Također, u današnje doba širenja SOA usluga računalnih oblaka postavlja se nekoliko
zanimljivih pitanja vezano za oblačnu uslugu razmjene poruka:

1. Može li uporaba oblačnog sustava za razmjenu poruka smanjiti troškove i vrijeme (Time
to Market) izrade sustava sa visokom dostupnošću (high availabily systems)?
2. Kakva su radna svojstava oblačnog sustava za razmjenu poruka po pitanju latencije i
količini poruka obrađenih u jedinici vremena?
3. Za sada je praksa da se za svaki računalni sustav (stacionarni ili mobilni) razvija posebni
sustav koji funkcionira samo u svom (native) okolišu ili alternativno pomoću
hipertekstualnog označnog jezika HTML5 [4]. U današnje doba širenja usluga računalnih
oblaka na mobilne računalne sustave (pametni telefoni – „smarthphones“, dlanovnici –
„tablets“) postoji potreba za univerzalno prenosivim klijentskim programskim sučeljem
koje može pristupati programskom sučelju računalnog oblaka. Postoji li tehnologija koja
omogućava izradu univerzalno prenosivog klijentskog programskog sučelja?

1.2. Dosadašnja istraživanja

Rijetko koje dosadašnje istraživanje je razmatralo uslužno orijentiranu arhitekturu u okviru
računalnih oblaka. Najznačajniji takav rad objavili su de Leusse i suradnici [5]. U tome radu
raspravlja se o tehničkim gledištima smještaja (deployment) cjelokupnog rješenja uslužno
orijentirane programske podrške u oblaku. Međutim, autori se ne bave ekonomskom isplativošću
takvog poduhvata niti problematikom hibridnih arhitektura u kojima se neke usluge pokreću iz
oblaka, a neke na klasičan način, sa privatnih poslužitelja poslovnog sustava ili tankih klijenata.

Općeniti pristup objedinjavanju SOA načela sa suvremenim informacijskim tehnologijama
istraživali su David S. Linthicum [6], K. Kontogiannis i suradnici [7] te Vitharana [8]. Nove
paradigme razvoja i korištenja programske podrške kao usluge istraživali su A. Dan, R. Johnson
i A. Arsanjani u radu [9], gdje autori spominju kako su takva rješenja iznimno primjenjiva u
okruženju računalnih oblaka. Općenitu problematiku prijelaza iz postojećih, naslijeđenih
(legacy) sustava na SOA sustav razmatrali su L. O'Brien, P. Breber i J. Gray [10], izloživši
glavnu ideju da je prijelaz na uslužno orijentiranu arhitekturu evolucijski proces koji ne
obezvređuje postojeća rješenja, nego ih potvrđuje i dopunjuje. Pregled nedostataka, pogodnosti i
ekonomiku računalnih oblaka izraživali su M. Armbrust, A. Fox, R. Griffith i suradnici [11]. U
svome istraživanju naveli su deset prepreka koje je potrebno imati u vidu za vrijeme izrade i
povezivanja oblačnih SOA usluga. Pitanje vezana uz sigurnost postavlja europska agencija za

2

informacijsku sigurnost ENISA [12], [13]; T. Mather, S. Kumaraswamy i S. Latif [14]; J. W.
Rittinghouse i James F. Ransome [15]. Izrada i primjena univerzalnog prenosivog klijentskog
programskog sučelja za razmjenu poruka do sada nije istraživana osim u ovome radu.

SOA usluga za razmjenu poruka u oblaku nije dovoljno istražena, ali generalno ima za cilj
ukloniti potrebu da se razvojni inženjeri bave osmišljavanjem i izgradnjom tradicionalnih sustava
za razmjenu poruka:

 Olakšati i ubrzati povezivanje heterogenih sustava uz što manje troškove i prepravke
postojećih rješenja.
 Ukloniti troškove održavanja (troškove održavanja sustava za razmjenu poruka istraživali
su M. R. Selim, Y. Goto, and J. Cheng [16]) kupcima oblačnih resursa.
 Omogućiti promjene postavki sustava pomoću grafičkog sučelja a da za to nije potrebno
plaćati obuku razvojnim inženjerima i trošiti vrijeme na postavljanje i testiranje postavki.

Na takav novi način promjene paradigme izbjegle bi se tradicionalne prepreke povezane sa
radom unutar vlastite infrastrukture sustava poruka [17].

1.3. Ciljevi rada

Rad ima četiri glavna cilja:

1. Proučiti način korištenja oblačnog SOA sustava za razmjenu poruka (Amazon SQS) u
svrhu povezivanja heterogenih SOA usluga radi povećanja raspoloživosti i sposobnosti
rasta cjelokupnog sustava.
2. Napraviti izračun troškova sustava za razmjenu poruka Amazon SQS i usporediti ga sa
tradicionalnim JMS sustavom; matematički opisati cjenik usluge Amazon SQS koji se
može koristiti za provjeru trenutnog stanja potrošnje sustava poruka; izraditi grafički alat
za provjeru i izmjenu postavki usluge Amazon SQS da se vidi koliko sati mjesečno je
potrebno prosječnom korisniku za osnovnu uporabu. Na temelju mjesečnog rada može se
izračunati mjesečna cijena rada jednog administratora.
3. Izraditi testni alat za mjerenje radnih svojstava usluge Amazon SQS. Svrha testa je da
odgovori na pitanje mogućnosti uporabe na tisuće tankih Internet klijenata (npr. mobilni
uređaji, dlanovnici) sa oblačnim sustavom za razmjenu poruka preko javne mreže
Internet.

3

4. Izraditi klijentsku zbirku as3awsSDK.swc u Actionscript 3.0 objektno-orijentiranom
programskom jeziku zasnovanom na standardu ECMAScript ECMA-262. Svrha zbirke je
da se iskoristi kao programsko sučelje za više različitih klijentskih računalnih sustava
različitih operativnih sustava (Windows, Mac OS, Linux, Windows, Android OS, Apple
iOS i BlackBerry OS).

Smatra se da će od ostvarenja prvoga cilja posebnu korist imati arhitekti programske podrške i
razvojni inženjeri jer će dobiti smjernice za upravljanje oblačnim SOA sustavom za razmjenu
poruka.

Ostvarenje drugoga i trećeg cilja od posebnog je interesa voditeljima informatike stoga što će,
koristeći spomenute rezultate testa, moći donositi potkrijepljene odluke o angažmanu računalnih
oblaka i načinu korištenja svih dostupnih resursa, privatnih ili oblačnih, za izvođenje usluga u
složenom informacijskom sustavu, posebice onog izloženog vremenski promjenljivim
zahtjevima za računalnom snagom.

Ostvarenje četvrtog cilja je od posebnog značaja računalnim programerima jer im izrađena
klijentska zbirka Amazon SQS (as3awsSDK.swc, Prilog 5.1) kao alat omogućuje komunikaciju
sa oblačnim sustavom za razmjenu poruka na jednostavan i univerzalno prenosiv način. To znači
da je računalni kod Actionscript 3.0 dovoljno napisati jednom, prevesti ga pomoću Adobe Flex
SDK prevodioca i pokrenuti ga na više operativnih sustava (Write once, run anywhere).

Ovim radom će se razjasniti ekonomski troškovni održavanja i tehnička svojstva između nove i
tradicionalne paradigme povezivanja heterogenih SOA usluga.

U drugom poglavlju napravljen je pregled tradicionalnog sustava za razmjenu poruka JMS i
usluge Amazon SQS. U trećem poglavlju napravljena je usporedba ukupnog troška održavanja
tradicionalnog sustava za razmjenu poruka sa troškovima korištenja usluge Amazon SQS. U
četvrtom poglavlju predstavljen je izrađeni alat za mjerenje radnih svojstava (ukupan broj HTTP
zahtjeva/odgovora u jedinici vremena) usluge Amazon SQS. U petom poglavlju predstavljena je
izrađena klijentska zbirka Amazon SQS (as3awsSDK.swc, Prilog 5.1) koju krasi jednostavnost
uporabe i univerzalna prenosivost na više računalnih sustava sa različitim operativnim sustava.

4

1.4. Plan istraživanja

Plan istraživanja obuhvaća četiri radnje provedene u razdoblju od jedne godine:

 Temeljen na spoznajama koje su proizašle iz eksperimentalnog istraživanja
provedenog mjerenjem radnih svojstava usluge Amazon SQS pomoću posebnog alata
izrađenog u Java programskog jeziku.
 Također biti će predstavljena posebno izrađena klijentska zbirka Amazon SQS
(as3awsSDK.swc, Prilog 5.1) koja omogućuje komunikaciju sa oblačnim sustavom za
razmjenu poruka. Svaka akcija koja je podržana od klijentske zbirke biti će prikazana uz
primjer tako da čitaoc ovoga rada dobije osjećaj koliko zapravo malo posla ima pri
uspostavi komunikacije između tankog klijenta i usluge Amazon SQS.
 Višemjesečnom usporedbom tradicionalnog komercijalnog proizvoda za razmjenu
poruka sa uslugom Amazon SQS izrađen je jednostavan tablični prikaz razlika između
standardnog sustava razmjena poruka i oblačnog sustava za razmjenu poruka. Tablični
prikaz služi kao pokazatelj usporedbe koji može pomoći razvojnim inženjerima da na
temelju tehničkih mogućnosti jednog i drugog sustava mogu donjeti odluku koji od
sustava koristiti.
 Ispitivanje i izračun strukture cijene usluge Amazon SQS radi objektivne procjene
troškova uporabe korištenja sustava za razmjenu poruka u oblaku u odnosu na vlastite
računalne, podatkovne resurse i vrijeme uloženo u promjene postavki.

Cilj istraživanja je potvrditi da je korištenje oblačnog sustava za razmjenu poruka (Amazon
SQS) ekonomski isplativije u odnosu na tradicionalni sustav u vlastitom vlasništvu i tehnički
jednostavnije koristiti pri povezivanju heterogenih SOA usluga.

5

2. PREGLED SUSTAVA ZA RAZMJENU PORUKA

2.1. Pojam spremnik poruka

Spremnikom poruka se smatra skup poruka koje čekaju u redu sve dok ih neki vanjski izvor ne
pokupi radi obrade podataka. Razvojni inženjeri su kroz vrijeme proširili osnovnu ideju
spremnika poruka tako što su nadodali nova svojstva u svrhu rješavanja problema u izgradnji
programskog sustava. U idućim potpoglavljima raspravlja se o uporabi spremnika poruka u
računalnoj znanosti.

2.2. Spremnik poruka kao struktura podataka

U računalnoj znanosti spremnikom poruka se smatra FIFO struktura koja čuva slijed poruka za
komunikacijske kanale. Poruke se nadodaju na kraj spremnika, a uzimaju se sa početka
spremnika. Spremnik poruka prikazan je na Slika 2.1.

Slika 2.1: FIFO spremnik poruka

U FIFO načinu rada [18] prva poruka koja se nadoda u spremnik poruka biti će prva i uklonjena.
To je jednako zahtjevu da kada je poruka nadodana, sve poruke koje su bile nadodane prije
moraju se ukloniti prije nego što se nadoda nova poruka. Spremnik poruka je pravi primjer
linearne strukture podataka. U stvarnom životu može se usporediti sa plaćanjem računa na
šalteru. Prvi platiša koji uđe u red će biti prvi poslužen, dok idući platiša ide na kraj reda i čeka
da sve platiše ispred njega budu poslužene. Kod računalnih programa najbolje primjer se može
predočiti tipkanjem po tipkovnici gdje se svaki znak odabran preko tipki pohranjuje prema
slijedu tipkanja u memoriju računala. Računalna znanost je s vremenom zbog zahtjevnijih
potreba računalnih programa proširila tipove spremnika poruka koji imaju poboljšan način rada:

a) Poboljšani način rada jamči da se u jednom vremenskom intervalu može nadodati-
ukloniti samo jedna poruka iz spremnika bez obzira na broj potrošača ili proizvođača
poruka kada više proizvođača-potrošača (producer-consumer) pokuša istovremeno

6

pristupiti spremniku poruka. Znači, ne smije se dogoditi da neka računalna
komponenta nadoda dvije poruke, a odmah nakon nje druga komponenta ukloni
jednu.
b) Spremnik sa dva kraja (deque) – omogućava nadodavanje i uklanjanje poruka sa obje
strane spremnika.

Slika 2.2: Spremnik poruka sa dva kraja

c) Spremnik sa rasporedom prioriteta – poruka s višim prioritetom će biti prije pročitana
nego poruka sa nižim prioritetom.

d) Spremnik sa privremeno nevidljivim porukama – sprema poruke koje su nevidljive za
potrošače spremnika određeni vremenski interval.

2.3. Spremnik poruka kao repozitorij

Spremnik poruka kao struktura podataka se najčešće koristi kao unutarnji pomoćni sustav za
samostalne programske komponente. Mrežni programi i mrežne usluge zahtjevaju drugačiji
pristup jer se sastoje od više komponenti koje obitavaju fizički na više različitih sustava i
poslužuju na tisuće korisnika istovremeno. Mehanizmi koje posjeduje spremnik poruka mogu
poslužiti pri rješavanju problema sa kojima se mrežni programi susreću:

a) Program ponekad nije u stanju obraditi sve zahtjeve koje prima u isto vrijeme. Jedno od
rješenja bi bilo da se prvo poruke stave u spremnik poruka te nakon toga da se omogući
njihova obrada.
b) Programi ponekad moraju izvršiti zadatke u određeno vrijeme. Za to vrijeme zadaci se
pohranjuju u spremnik za stalno i čekaju na izvršenje. Primjer takve uporabe može biti
npr. slanje podsjetnika korisniku o nekoj pretplati putem SMS poruke u određeno doba
dana.
c) Najčešći primjer iz prakse koristi pristup proizvođač-potrošač. Radi na takav način da
više proizvođača stavlja poruke u spremnik dok potrošači prikupljaju poruke. Pristup

7

proizvođač-potrošač omogućava da proizvođači i potrošači izvršavaju svoje zadatke
neovisno jedni o drugome.

Slika 2.3: Izmjena poruka pomoću proizvođača – potrošača

Spremnik poruka prikazan na Slika 2.3 može se smatrati kao privremeni repozitorij poruka koje
čekaju da ih netko pokupi. Privremeni repozitorij se koristi kao nezavisna programska
komponenta koju može koristiti više proizvođača i potrošača poruka istovremeno bez obzira gdje
se fizički repozitorij nalazi. Repozitorij se može nalaziti na računalu na kojemu se isto tako
nalaze proizvođači i potrošači poruka ili na nekom udaljenom računalu. Može se reći da
spremnik poruka točka razdvajanja između proizvođača i potrošača poruka. Spremnik poruka
može biti neizdržljiv (poruke se čuvaju u memoriji) ili izdržljiv (poruke se čuvaju u bazi
podataka ili direktno na tvrdom disku bez posredovanja baze podataka).

a) Neizdržljiv način rada – poruke su spremljene na poslužitelju sve dok ima dovoljno
računalnih resursa (dovoljna količina RAM memorije) da zadrži poruke. Spremnik poruka
se može vrlo brzo napuniti ako potrošač nedovoljno brzo kupi poruke iz spremnika,
odnosno da proizvođač poruka brže puni spremnik porukama nego što ih potrošač
prikuplja i obrađuje. U tom slučaju može doći do pada sustava zbog nedostatka
memorije, a sve poruke koje su se nalazile u spremniku će biti zauvijek izgubljene.
b) Izdržljiv način rada – zahtjeva da se poruke iz spremnika pohranjuju direktno na tvrdi
disk ili u bazu podataka. U slučaju pada sustava ili redovitog održavanja poruke unutar
spremnika će uvijek biti očuvane. Ovakav način rada je više pouzdan i omogućava da se
pohrani više poruka u spremnik nego kod neizdržljivog načina rada. Nedostatak ovog
načina rada je da zahtjeva više računalne snage te vrijeme izvođena izmjene poruka
između potrošača i proizvođača je veće.

Spremnik poruka se može nalaziti na istom računalu gdje se nalaze proizvođači i potrošači
poruka. Ako se sustav na računalu sruši tada računalne komponente koje se služe uslugama
spremnika neće biti dostupne ili će imati otežan način obavljanja zadataka. Zato je potrebno

8

osmisliti i izraditi sustav sa visokom raspoloživošću koji može istovremeno poslužiti više
potrošača i proizvođača poruka pod bilo kojim okolnostima.

2.4. Arhitektura standardnog Java programskog sučelja za razmjenu
poruka

Prije više od deset godina uz pomoć Java platforme izgrađena je sabirnica za razmjenu poruka
MOM između dva ili više programskih komponenti. Za razmjenu poruka između programskih
komponenti koristi se programsko sučelje JMS API 1.1 koje je registrirano pod organizacijom
Java Community Process JSR 914 [19]. Smatra se standardom za razmjenu poruka između
programskih JavaEE komponenti koje se nalaze na udaljenim računalnim sustavima u svrhu
pružanja pouzdane, asinkrone i međusobno nezavisne razmjene poruka.

Standardna JMS komponenta je građena od nekoliko osnovnih dijelova:

1. Davatelj JMS usluge – predstavlja izradu JMS sučelja i omogućava promjenu postavki
sustava za razmjenu poruka. Najpoznatije izrade takvog sučelja su: JBoss Messaging
[20], HornetQ [21], Apache ActiveMQ [22], IBM WebSphereMQ [23], Oracle
WebLogic [24], Tibco EMS [25], RabbitMQ [26].
2. JMS klijenti – proizvođači i potrošači poruka čiji je računalni kod napisan u Java
programskom jeziku.
3. Poruke – predstavljaju objekte koji prenose informacije između klijenata.
4. Postavke JMS objekata – postavke odredišta JMS poruka koje će koristiti potrošači i
proizvođači poruka.
5. Izvorni klijenti – programi koji koriste izvorno (native) klijentsko programsko sučelje
umjesto JMS API-ja.

Slika 2.4 prikazuje međudjelovanja između pojedinih dijelova JMS API arhitekture. Alat za
promjenu postavki sustava poruka omogućava korisnicima da povezuju odredišta i veze u JNDI
[27] okoliš. JMS klijent tada može pogledati objekt s promjenjivim postavkama u JNDI okolišu i
pokušati uspostaviti logičku vezu s njime preko davatelja JMS usluge.

9

Slika 2.4: Arhitektura standardnog Java programskog sučelja za razmjenu poruka (JMS API)

2.5. Područje djelovanja sustava poruka

Postoje dva pristupa koji se primjenjuju kod razmjene poruka između programskih komponenti
proizvođač-potrošač. Prvi pristup se zove „Od točke do točke“, a drugi „Objavi-pretplati“. JMS
propisuje odvojeno područje djelovanja sustava poruka za svaki od navedenih pristupa i pravila
za svako područje djelovanja (opisano u potpoglavljima 2.5.1 i 2.5.2). Dužnost razvojnog
inženjera (ili razvojne programske zajednice) je da tokom razvoja „Davatelja usluge JMS“
razviju oba pristupa djelovanja i da omoguće klijentima po potrebi združivanje pristupa.

2.5.1. Područje djelovanja “Od točke do točke”

Slika 2.5 prikazuje način na koji područje djelovanja “Od točke do točke” djeluje. Adresa
spremnika poruka se postavlja pomoću „Alata za promjenu postavki“ koji je sastavni dio
„Davatelja usluge JMS“. Adresa spremnika poruka je poznata proizvođaču (Klijent 1) i
potrošaču (Klijent 2). Proizvođač poruka šalje poruke u spremnik, poruke u spremniku čekaju
sve dok ih potrošač ne pokupi ili dok ne istekne rok trajanja poruke u spremniku. Nakon što
potrošač pokupi poruku šalje potvrdu „Davatelju usluge JMS“ da je poruka uspješno primljena.

10

Slika 2.5: Područje djelovanja „Od točke do točke“

Svojstva područja djelovanja „Od točke do točke“:

a) Svaka poruka ima samo jednog potrošača.
b) Proizvođač i potrošač poruka međusobno su vremenski nezavisni.
c) Potrošač poruka uvijek može pokušati dohvaćati poruke bez obira da li proizvođač
poruka proizvodi poruke ili ne.
d) Potrošač uvijek šalje potvrdu „Davatelju usluge JMS“ da je poruka uspješno primljena,
ali zato „Davatelj usluge JMS“ ne zna da li je poruka uspješno obrađena.

2.5.2. Područje djelovanja „Objavi-pretplati“

Područje djelovanja “Objavi-pretplati” radi prema načinu pretplate korisnika (potrošača) tako da
se pretplatnici pretplate na određenu temu (topic). Kada proizvođač poruka pošalje poruku na
temu, tada „Davatelj usluge JMS“ šalje tu istu poruku (P1) prema svim pretplatnicima.
Najjednostavniji primjer usluge koja radi na takav način je elektronička pošta. U zahtjevu za
dostavu elektroničke pošte moguće je postaviti više odredišta (imena osoba kojima se želi poslati
elektronička pošta). Slika 2.6 prikazuje način na koji područje djelovanja „Objavi-pretplati”
djeluje. Može se primjetiti da bez obzira na promjenjen broj potrošača (Klijent 1, Klijent 2, ...
Klijent n) „Davatelj usluge JMS“ će uvijek slati poruke svim potrošačima transparentno preko
teme. To znači da proizvođač ne mora znati (niti biti obavješten) o promjeni liste pretplatnika.

11

Slika 2.6: Područje djelovanja "Objavi-pretplati" (P1 – poruka; C1,C2,C3 – potvrda primitka poruke)

Svojstva područja djelovanja “Objavi-pretplati”:

a) Tema je središnje mjesto područja djelovanja „Objavi-pretplati“.
b) Više proizvođača poruku može staviti na temu.
c) Dovoljno je jednom poslati poruku na temu, a „Davatelj usluge JMS“ će poslati tu istu
poruku svim pretplatnicima unutar teme („one-to-many“ način slanja poruka).
d) Proizvođač i potrošač poruka međusobno su vremenski zavisni (potrošač koji se
pretplatio na temu može pokupiti poruke nakon što ih je proizvođač poslao. Potrošač
mora biti aktivan da bi uspješno nastavio primati poruke).

Vremenska zavisnost može predstavljati problem jer se može dogoditi da neki potrošači ne
dobiju poruke zbog kvara ili redovitog održavanja sustava. U tome slučaju može se reći da
proizvođači poruka šalju poruke u prazno gdje se na takav način gube poruke. Da bi se riješio taj
problem uveden je pojam „Trajna lista pretplatnika“ za koje će tema (topic) trajno (ili
privremeno određeno vremensko razdoblje) čuvati poruke u slučaju da pretplatnici (klijenti) nisu
dostupni. Kada se pretplatnici (klijenti) ponovo osposobe za primanje poruka, „Davatelj usluge
JMS“ će im početi ponovo slati poruke, ali i one poruke koje su se skupile u razdoblju dok su
pretplatnici (klijenti) bili nedostupni.

2.5.3. Prikupljanje poruka

Prikupljanje (potrošnja) poruka je uobičajen postupak za računalne programske proizvode koji se
bave dostavom poruka između računalnih sustava. JMS poslužitelj propisuje dva načina
prikupljanja poruka: asinkroni i sinkroni.

12

a) Sinkroni način – sinkronim načinom prikupljanja poruka se smatra kada potrošač sam
izričito zatraži poruku od „Davatelja usluge JMS“. Za to vrijeme blokiran je poziv prema
„Davatelju usluge JMS“ sve dok potrošač ne dobije odgovor ili ne istekne vrijeme
čekanja. Izvorni kod sinkronog načina prikupljanja poruka prikazan je na Izvorni Java
kod 2.1.
public class Receiver
{
public static void main(String[] args) throws Exception
{
// sadržaj Java okoliša
InitialContext ctx = new InitialContext();

// povezivanje vrijednosti
Queue queue = (Queue) ctx.lookup("queue/queue0");

// izrada objekta preko kojega će se veza sa "Davateljem usluge JMS" ostvariti
QueueConnectionFactory connFactory = (QueueConnectionFactory) ctx.
lookup("queue/connectionFactory");

// ostvarivanje veze sa "Davateljem usluge JMS"
QueueConnection queueConn = connFactory.createQueueConnection();

// stvaranje sesije
QueueSession queueSession = queueConn.createQueueSession(false,
Session.AUTO_ACKNOWLEDGE);

// stvaranje potrošača
QueueReceiver queueReceiver = queueSession.createReceiver(queue);

// pokretanje veze prema spremniku
queueConn.start();

// izričito traženje poruke iz spremnika
TextMessage message = (TextMessage) queueReceiver.receive();

// ispis poruke
System.out.println("received: " + message.getText());

// zatvaranje veze prema spremniku
queueConn.close();
}
}
Izvorni Java kod 2.1: Sinkroni način rada primatelja poruka opisan izvornim Java kodom JMS sučelja

13

b) Asinkroni način – „Davatelj usluge JMS“ šalje poruku registriranom osluškivaču poruka.
Primitkom poruke pokreće se metoda „onMessage“ iz koje se može pročitati sadržaj
poruke. Izvorni kod asinkronog načina prikupljanja poruka prikazan je na Izvorni Java
kod 2.2.

14

public class AsyncReceiver implements MessageListener, ExceptionListener
{
public static void main(String[] args) throws Exception
{
// sadržaj Java okoliša
InitialContext ctx = new InitialContext();
// povezivanje vrijednosti
Queue queue = (Queue) ctx.lookup("queue/queue0");
// izrada objekta preko kojega će se veza sa "Davateljem usluge JMS" ostvariti
QueueConnectionFactory connFactory = (QueueConnectionFactory) ctx.
lookup("queue/connectionFactory");
// ostvarivanje veze sa "Davateljem usluge JMS"
QueueConnection queueConn = connFactory.createQueueConnection();
// stvaranje sesije
QueueSession queueSession = queueConn.createQueueSession(false,
Session.AUTO_ACKNOWLEDGE);
// stvaranje potrošača
QueueReceiver queueReceiver = queueSession.createReceiver(queue);
// postavljanje prislušne komponente na potrošača poruka
AsyncReceiver asyncReceiver = new AsyncReceiver();
queueReceiver.setMessageListener(asyncReceiver);
// postavljanje prislušne komponente za hvatanje grešaka
queueConn.setExceptionListener(asyncReceiver);
// pokretanje veze prema spremniku poruka
queueConn.start();
// čekanje primitka poruke...
System.out.print("waiting for messages");
for (int i = 0; i < 10; i++) {
Thread.sleep(1000);
System.out.print(".");
}
System.out.println();

// zatvaranje veze prema spremniku poruka
queueConn.close();
}

/**
Ova metoda je pozvana asinkrono od strane "Davatelja JMS usluge" svaki puta kada je
poruka poslana u Spremnik.
@param message objekt JMS poruke.
*/
public void onMessage(Message message)
{
TextMessage msg = (TextMessage) message;
try {
System.out.println("received: " + msg.getText());
} catch (JMSException ex) { ex.printStackTrace(); }
}

Izvorni Java kod 2.2: Asinkroni način rada primatelja poruka opisan izvornim Java kodom JMS sučelja

15

2.6. JBossMQ – primjer davatelja standardne usluge JMS

U ovom podpoglavlju ukratko će biti predstavljen ne-komercijalni (pripadnik otvorenog koda)
„Davatelj usluge JMS“ koji se naziva JBossMQ. JBossMQ je programska komponenta unutar
JavaEE poslužitelja JBoss koji ima mogućnost pružanja usluge razmjene poruka između više
programskih komponenti. JBossMQ je temeljen na programskom sučelju JMS API 1.1 i
podržava oba područja djelovanja: „Od točke do točke“ i „Objavi-pretplati“.

Svojstva JBossMQ kao davatelja usluge JMS:

a) „Od točke do točke“ – proizvođač poruka dostavlja poruke u spremnik, a jedan potrošač
kupi poruke.
b) „Objavi-pretplati“ – ovaj model se još naziva i „Jedan prema više“. Kada pošalje poruku
na Temu, tada „Davatelj usluge JMS“ pošalje tu istu poruku svim pretplatnicima teme.
Pretplatnici koji nisu aktivni neće primiti poruku.
c) „Trajne poruke“ – može se reći da je riječ o miješanom svojstvu „Od točke do točke“ i
„Objavi-pretplati“. Ako pretplatnik nije bio aktivan za vrijeme kada su se poruke slale
prema njemu tada ih može pročitati kasnije kada se uključi jer su se poruke spremale za
vrijeme njegove neaktivnosti.
d) Spremnici i teme u grozd okružju – nalaze se na svim računalima unutar grozda. JMS
klijent koristi visokodostupni HA JNDI koji ima informacije o svim adresama spremnika
i tema na računalima. Pri tome važno je napomenuti da algoritmi ravnoteže
(weighted round-robin, round-robin-affinity, weight-based-affinity, random-affinity)
[28] održavaju pravilan raspored veza između spremnika i tema tako da ne dođe do
zagušenja prometa poruka.

Svi „Davatelji usluge JMS“ (komercijalni i nekomercijalni) zahtjevaju predefiniranje postavki
tako da programske komponente mogu ispravno komunicirati sa „Davateljem JMS usluge“. To
uključuje instalaciju programskih komponenti, postavljanje sigurnosnih ograničenja, izrada JMS
sučelja, postavke spremnika i teme u grozd okružju. Rad sa raspodjeljenim spremnicima i
temama je danas među najvećim problema u raspodjeljenom računarstvu. Pravi izazov je izraditi
i koristiti takav sustav, ali u pojednostavljenom obliku tako da osobe koje su dužne mijenjati
postavke takvih sustava čine to jednostavnije, brže i bez posebne tehničke obuke.

16

2.7. Spremnici poruka sa visokom dostupnošću

Imati nedostupan spremnik poruka zbog pada sustava je najveći mogući problem s kojim se
susreću mrežne usluge. Spremnik poruka sa visokom dostupnošću je sustav razmjene poruka koji
se nudi kao jedino logično rješenje za sigurnu i pouzdanu razmjenu poruka između programskih
komponenti. Problem koji se javlja je: kako postaviti postavke takvog sustava? - jer postavke
svih „Davatelja usluga JMS“ nisu jednake. Razlikuju se po broju parametara, vrsti parametara,
grafičkom sučelju alata za promjenu postavki. Amazon AWS je zato ponudio vrlo interesantno
rješenje kojim sakriva složenost sustava za razmjenu poruka, a da pri tome nudi visoku
dostupnost usluge, sigurnost, podesivost, jednostavno programsko i grafičko sučelje. Takav
sustav nije potrebno održavati sa gledišta kupca – kupnja računalnih komponenti za nadogradnju
postojećeg sustava, potrošnju električne energije, sustav hlađenja, plaćanje licenci, certifikati,
plaćanje obuke vlastitog osoblja kako se služiti grafičkim sučeljem. Iduće poglavlje raspravlja o
uslugi Amazon SQS da bi se bolje razumio način na koji djeluje.

2.8. Usluga Amazon SQS za razmjenu poruka

Tvrtka Amazon je izradila SOA oblačnu uslugu Amazon SQS za razmjenu poruka sa visokom
dostupnosti, sigurnosti, pouzdanosti i podesivosti. Svrha usluge je da omogući jednostavno
asinkrono povezivanje ostalih geografski udaljenih heterogenih SOA usluga i uklanjanje
njihovih međuzavisnosti. Geografski udaljene heterogene SOA usluge ne moraju čak biti u
vlasništvu istog kupca. Osnovni cilj je da bilo koja SOA usluga treće strane može pohraniti bilo
koji tip podatka u sigurni i uvijek dostupni spremnik poruka uz pomoć posebnog programskog
sučelja Amazon SQS API [29].

Ovakav način obavljanja razmjene poruka između programskih komponenti rješava problem
vremenske zavisnosti između proizvođača i potrošača poruka. Postaje nebitno kojom brzinom
proizvođač puni spremnik poruka, ili kojom brzinom i kada potrošač prikuplja poruke.

Usluga Amazon SQS se obvezuje dostaviti poruku barem jednom u sklopu svoje kvalitete
usluge, podržava više istovremenih proizvođača i potrošača poruka koji unose i čitaju poruke iz
spremnika poruka. Građena je na takav način da uvijek bude dostupna za dostavljanje poruka, ali
zato ne jamči FIFO načina dostavljanja poruke. U slučaju da je potrebno pratiti redoslijed poruka
tada je na razvojnom inženjeru da unutar svake poruke stavi informaciju o rednom broju poruke.
Kada se poruka primi potrebno je samo provjeriti informaciju o rednom broju.

17

Usluga Amazon SQS omogućava da bilo koje računalo, pametni telefon, dlanovnik, spojeno na
javnu mrežu Internet uz pravilnu provjeru valjanosti (authentication) i odobrenja (authorization)
korisnika može nadodavati ili čitati poruke bez posebno instaliranog programa treće strane ili
postavki vatrozida.

Velika prednost je što programske komponente koje koriste uslugu Amazon SQS rade
neovisno jedna o drugoj, ne moraju biti na istoj mreži, ne moraju biti razvijene istim
programskim jezikom te raditi u isto vrijeme.

2.8.1. Svojstva usluge Amazon SQS

Usluga Amazon SQS sadrži nekoliko korisnih svojstava koja olakšavaju rad razvojnim
inženjerima:

a) Višestruka zalihost omogućava visoku dostupnost spremnika za primanje i slanje poruka.
b) Obavezuje se dostaviti poruku barem jednom u sastavu svoje kvalitete usluge (QoS),
istovremeno podržavati više proizvođača i potrošača poruka koji unose i čitaju poruke iz
spremnika poruka.
c) Građena je na takav način da uvijek bude dostupna za dostavljanje poruka, ali zato ne
jamči FIFO načina dostavljanja poruke. U slučaju da je potrebno pratiti redoslijed poruka
tada je na razvojnom inženjeru da unutar svake poruke stavi informaciju o rednom broju
poruke. Kada se poruka primi na strani potrošača potrebno je samo provjeriti informaciju
o rednom broju.
d) Moguće je da više proizvođača i potrošača poruka istovremeno koriste isti spremnik
poruka.
e) Zaključavanje poruka unutar spremnika – poruka će biti zaključana (nevidljiva) određeno
vrijeme od strane spremnika kada potrošač (klijent) pročita poruku. Npr. Kada Potrošač 1
pročita poruku P1 tada je ta poruka nevidljiva Potrošaču 2, Potrošaču 3, Potrošaču (n)
određeno vremensko razdoblje. To je napravljeno da se spriječi višestruko čitanje poruke
od strane više potrošača u istom vremenskom rezdoblju.
f) Svakom spremniku poruka mogu se vrlo jednostavno promijeniti postavke, ali i provjeriti
trenutne postavke. Npr. spremniku poruka se mogu postaviti postavke na takav način da
uspori očitavanje poruka potrošačima tako da se poveća vrijeme nevidljivosti poruka.
g) Najveća dopuštena veličina poruke je 64 kB. Naravno, to se može i povećati jer sadržaj
poruke se može sažimati. Najjednostavnije i sukladno sa drugim programskim jezicima je

18

koristiti deflate/inflate postupak za sažimanje podataka koji se navodi u RFC 1951 [30].
Podržan je u Javi, C#, Actionscriptu 3.0 i ostalim programskim jezicima.
h) Broj spremnika i količina poruka unutar spremnika je NEOGRANIČENA.
i) Najdulje vrijeme života poruke unutar spremnika je 14 dana. Ako za to vrijeme potrošač
ne pokupi poruku onda će poruka biti obrisana od strane usluge Amazon SQS.
j) U slučaju da se spremnik poruka ne koristi (prikupljanje poruka, slanje poruka, brisanje
poruka, dodavanje prava, oduzimanje prava, provjera stanja) dulje od 30 dana usluga
Amazon SQS će ga zauvijek obrisati.
k) Uslugi Amazon SQS moguće je pristupiti korištenjem programskog sučelje SOAP ili
obični HTTP(s) zahtjev. U slučaju korištenja javne mreže Internet najpoželjnije je
koristiti HTTPS koji koristi SSL/TLS protokol koji omogućava zaštićenu komunikaciju
između klijenta i poslužitelja. Takav način komunikacije primjenjuje i bankarski sektor
pri novčanim Internet transakcijama.
l) Spremnici poruka mogu dijeliti svoje poruke između više različitih potrošača koji
pripadaju različitim korisnicima AWS računa (npr. klijenti koji pripadaju različitim
tvrtkama koji se spajaju na spremnik poruka). Da ne bi došlo do nedozvoljenih radnji
mogu se ograničiti pristupna prava tako da se dodatno provjerava Internet adresa
potrošača, zaglavlje HTTP(s) zahtjeva UserAgent i vrijeme pristupa uslugi.

2.8.2. Osnovni pregled arhitekture usluge Amazon SQS

Usluga Amazon SQS se sastoji od tri glavne komponente (Slika 2.7):

a) Komponente udaljenih sustava – sustavi međusobno koriste uslugu Amazon SQS za
primanje i slanje poruka.
b) Spremnici poruka – svaki spremnik je kopiran na više poslužitelja radi pružanja veće
dostupnosti poruka klijentima.
c) Poruke – poruke se kopiraju više puta za svaku instancu spremnika.

19

Slika 2.7: Pregled arhitekture usluge Amazon SQS

2.8.3. Kako radi usluga Amazon SQS ?

Korisnici usluge Amazon SQS moraju izraditi Amazon AWS račun za koji im je potrebna
valjana kreditna kartica (American Express, Visa, Diners). Svaki Amazon AWS račun je
prepoznat prema jedinstvenom broju od dvanaest znamenki koji se pridodjeli korisniku računa za
vrijeme izrade računa. Nakon završene prijave korisnika usluga Amazon SQS je potpuno
dostupna. Spremnik poruka se izrađuje pokretanjem SQS akcije CreateQueue kojoj mora biti
predano jedinstveno ime spremnika. Nakon uspješne izrade spremnika, usluga Amazon SQS
izrađuje URL imenski prostor. Primjer oblika jednoga takvog imenskog prostora može se
predočiti ovako: http://<adresa usluge Amazon SQS>/<jedinstveni broj računa>/<ime
spremnika>. Error! Reference source not found.Tablica 2.1 prikazuje imenski prostor usluge
Amazon SQS u ovisnosti o geografskom položaju računalnog centra. Korisnik time dobiva
mogućnost da sam odluči u kojem računalnom centru želi imati spremnik poruka. Najlogičnije je
odabrati onaj računalni centar koji je najbliži klijentu u svrhu smanjenja vremena kašnjenja
(latency issue) izmjene poruka između proizvođača i potrošača.

Tablica 2.1: Imenski prostor usluge Amazon SQS

Odredišta ovisno o Jedinstveni broj
Imenski prostor
geografskom položaju računa
The US East (Northern
Virginia) http://sqs.us-east-
012345678912
(http://sqs.us-east- 1.amazonaws.com/012345678912/Test
1.amazonaws.com)
The US West
(Northern California) http://sqs.us-west-
012345678912
(http://sqs.us-west- 1.amazonaws.com/012345678912/Test
1.amazonaws.com)
US West (Oregon) http://sqs.us-west-2.amazonaws.com
012345678912
(http://sqs.us-west- /012345678912/Test

20

2.amazonaws.com)

The EU(Ireland)
http://sqs.eu-west-
(http://sqs.eu-west- 012345678912
1.amazonaws.com/012345678912/Test
1.amazonaws.com)
The Asia Pacific
(Singapore)
http://sqs.ap-southeast-
(http://sqs.ap- 012345678912
1.amazonaws.com/012345678912/Test
southeast-
1.amazonaws.com)
The Asia Pacific
(Tokyo) (http://sqs.ap- http://sqs.ap-northeast-
012345678912
northeast- 1.amazonaws.com/012345678912/Test
1.amazonaws.com)
The South America
(Sao Paulo) (sqs.sa- http://sqs.sa-east-1.amazonaws.com
012345678912
east- /012345678912/Test
1.amazonaws.com)

Nakon što je spremnik poruka izrađen usluga Amazon SQS je odmah spremna primati poruke i
zadržati ih dok ih potrošač ne pokupi i obriše. Proizvođač poruke šalje pomoću SQS akcije
SendMessage kao što je prikazano na Slika 2.8. Poruke se kopiraju na više poslužitelja radi
pružanja visoke dostupnosti tako što se čuvaju redundantne kopije.

Slika 2.8: Slanje poruke u spremnik poruka (akcija SendMessage)

Slika 2.9 prikazuje zahtjev akcije ReceiveMessage koji prikuplja poruke iz spremnika poruka i
sat koji mjeri vrijeme vidljivosti poruke unutar spremnika.

21

Slika 2.9: Prikupljanje poruka iz spremnika poruka (akcija ReceiveMessage)

Za vrijeme prikupljanja poruke iz spremnika poruka zahtjev će biti usmjeren prema težinskoj
funkciji raspodjele nekom od poslužitelja usluge Amazon SQS. To znači da se može dogoditi da
pojedini SQS zahtjev neće vratiti nikakvu poruku iako poruke postoje na poslužiteljima ili ako ih
je jako malo (npr. postoji manje od 1000 poruka unutar spremnika poruka). Zato je ponekad
potrebno (za male spremnike poruka) izvršiti više uzastopnih SQS zahtjeva da bi se poruke
prikupile. Slika 2.10 prikazuje poruke A, B, C, D i E čije se kopije nalaze na više poslužitelja
usluge Amazon SQS. Može se primjetiti da poruka E nije dohvaćena jer SQS zahtjev nije
obuhvatio poslužitelj na kojemu se poruka E nalazi.

Slika 2.10: Prikupljanje poruka A, B, C; D iz spremnika poruka (akcija ReceiveMessage)

Nakon što komponenta n primi poruku, poruka se i dalje nalazi u spremniku poruka. Ona nije
obrisana nego je sakrivana od ostalih komponenti određeno vrijeme. To znači da usluga Amazon
SQS blokira druge komponente da prime istu poruku da bi se spriječila istovremena obrada jedne
te iste poruke od više komponenti. Slika 2.11 grafički prikazuje vremensko ograničenje
nevidljivosti poruke.

22

Slika 2.11: Vremensko ograničenje nevidljivosti poruke (akcija ChangeMessageVisibility)

Kada komponeta n (potrošač) uspješno pročita i obradi poruku tada mora pozvati akciju
DeleteMessage koja uklanja poruku iz spremnika poruka tako da je druge programske
komponente ne mogu više koristiti. DeleteMessage je potrebno pozvati unutar vremenskog
ograničenja nevidljivosti poruke kao što je prikazano na Slika 2.12. Ako komponenta ne uspije
obraditi i obrisati poruku tada će poruka ponovo biti pročitana od neke druge programske
komponente akcijom ReceiveMessage nakon što istekne vrijeme nevidljivosti poruke.

Slika 2.12: Brisanje poruke 'A' iz spremnika poruka unutar vremenskog ograničenja nevidljivosti poruke (akcija
DeleteMessage)

Usluga Amazon SQS pokušava održati redoslijed poruka unutar spremnika poruka, ali zbog
raspodjeljene prirode spremnika nemoguće je jamčiti da će strana koja prikuplja poruke dobiti
poruke po redoslijedu slanja. Ako sustav zahtjeva da prima poruke po nekom zadanom
redoslijedu tada je potrebno umetnuti informaciju o rednom broju poruke. Redni broj se
postavlja u tijelo poruke, a ne u zaglavlje. Poruke se kopiraju na više poslužitelja radi očuvanja
zalihosti i visoke dostupnosti. U rijetkim slučajevima, jedan od poslužitelja koji čuva kopije

23

poruka može biti nedostupan nakon što potrošač (klijent) primi ili obriše poruku. Ako se to
dogodi, kopija poruke neće biti obrisana na tom nedostupnom poslužitelju i moguće je da će isti
potrošač ponovo primiti tu istu poruku kasnije kada poslužitelj postane dostupan. Zbog toga
potrebno je osmisliti i povezati heterogene SOA usluge da budu otporne na obradu jedne te iste
poruke više puta - idempotentnost.

2.8.4. HTTP(s) zahtjevi i odgovori

Usluga Amazon SQS propisuje posebna pravila kako napraviti ispravni SQS zahtjev i kakav
oblik odgovora očekivati. U ovom podpoglavlju biti će objašnjeni različiti tipovi HTTP(s)
zahtjeva i odgovora sa kojima će se razvojni inženjeri susretati. Postoji lista parametara (Tablica
2.2) koju je potrebno primjenjivati da bi zahtjev za pokretanjem SQS akcije bio ispravan.

Napomena: Programsko sučelje SOAP nije podržano od 31.12.2011. Razlog tome je što
~0.3% razvojnih inženjera koristi programsko sučelje SOAP što ga čini nezanimljivim za daljne
održavanje pa zato i neće biti rasprave o njemu u ovom radu [31].

Tablica 2.2: Lista obaveznih parametara za Amazon SQS HTTP(s) zahtjeve

Tko koristi parametar
Jednostavni
Naziv parametra Opis parametra
zahtjev SOAP
upita
Naziv akcije koja se treba izvršiti DA NE
Action unutar SQS usluge. Npr.
CreateQueue.
Korisnikov Amazon AWS javni ključ. DA DA
AWSAccessKeyId Sastoji se od 20 alfanumeričkih
znakova.
Datum i vrijeme trajanja zahtjeva u DA DA
formatu YYYY-MM-
DDThh:mm:ssZ. Format je podržan
Expires
prema standardu ISO 8601 [32].
Preporučljivo je slati datum i vrijeme
prema GMT vremenskoj zoni.

24

Napomena #1: SOAP zahtjevi koji
ne koriste WS-Security ne smiju
koristiti Expires, nego Timestamp.
Napomena #2: Jednostavni upit
zahtjeva ne smije koristiti Timestamp
ako koristi Expires parametar.
Potpis zahtjeva napravljen koristeći DA DA
SHA1 ili SHA256 algoritam [33]
pomoću tajnog AWS ključa (40
Signature alfanumeričkih znakova) koji je
dodjeljen korisniku (prema standardu
RFC 2104 [34]). Tajni ključ se
NIKADA NE ŠALJE u zahtjevu.
Način izrade potpisa zahtjeva. DA NE
SignatureMethod=HmacSHA256
SignatureMethod (preporučeno)
SignatureMethod= HmacSHA1
(zastarjelo)
SignatureVersion=1 (zastarjelo) DA NE
SignatureVersion
SignatureVersion=2 (preporučeno)
Datum i vrijeme kada je zahtjev upita DA DA
nastao u formatu YYYY-MM-
DDThh:mm:ssZ. Format je podržan
prema standardu ISO 8601.
Preporučljivo je slati datum i vrijeme
prema GMT vremenskoj zoni.
Timestamp
Napomena #1: SOAP zahtjevi koji
ne koriste WS-Security ne smiju
koristiti Expires, nego Timestamp.
Napomena #2: Jednostavni upit
zahtjeva ne smije koristiti Timestamp
ako koristi Expires parametar.
Verzija programskog sučelja. DA NE
Version
Trenutna verzija: 2009-02-01.

25

2.8.5. Izrada i sigurnost jednostavnog HTTP(s) zahtjeva upita

Usluga Amazon SQS podržava jednostavne RESTful zahtjeve upita [35] pozivajući SQS akcije.
Zahtjevi upita su jednostavni HTTP(s) zahtjevi koji koriste GET i POST metode poziva. Zahtjevi
upita obavezno moraju sadržavati parametre: Action, AWSAccessKeyId, Expires ili Timestamp,
Signature, SignatureMethod i SignatureVersion. Mogu imati i dodatne parametre, ali njihovi
nazivi ovise o tipu akcije koje izvršavaju. U šest koraka objašnjeno je kako napraviti ispravan
zahtjev upita [36]:

1. Izrada kanoničkog upita
a) Poredati UTF-8 komponente upita po imenu parametra sa prirodnim byte
redoslijedom. Parametri mogu doći od GET URI ili POST tijela poruke (kada je
parametar HTTP(s) zaglavlja Content-Type=application/x-www-form-
urlencoded).
b) URL enkodirati imena i vrijednosti parametara prema slijedećim pravilima:
 Ne smiju se enkodirati nerezervirani znakovi koje propisuje RFC 3986
[37]. Nerezervirani znakovi: A-Z, a-z, 0-9, crtica ( - ), donja crtica ( _ ),
točka ( . ), and tilda ( ~ ).
 Enkodirati sve ostale druge znakove sa %XY. X i Y predstavljaju
heksadecimalne znakove: 0 - 9 i A – F.
 Proširene znakove formata UTF-8 [38] enkodirati u formatu %XY%ZA....
 Jedan razmak (ASCII kod 32) enkodirati kao %20.
c) Odvojiti enkodirana imena parametara od njihovih enkodiranih vrijednosti sa
znakom jednako ( = ) (ASCII kod 61) bez obzira da li je vrijednost parametra
prazna ili ne.
d) Odvojiti sve parove ime-vrijednost sa znakom & (ASCII kod 38).
2. Izrada niza koji treba biti potpisan prema slijedećoj pseudo gramatici („n“ predstavlja
novi red – ASCII kod 13).

Niz = HTTP(s) metoda + „n“ +
odredište SQS usluge +
identifikator + „n“ +
kanonički upit iz prethodnog koraka

Slika 2.13: Niz koji treba biti potpisan

a) HTTP(s) metoda - POST (za izmjenu podataka) ili GET (za dohvaćanje
podataka).

26

b) Odredište usluge Amazon SQS – lista odredišta se može vidjeti u Tablica 2.1.
c) Identifikator - <broj korisnikovog Amazon AWS računa>/<ime spremnika> (ako
ime spremnika nije potrebno slati u zahtjevu onda je kao identifikator potrebno
postaviti znak „ / “)
3. Izračunati RFC 2104 HMAC potpis [34] (SHA1 ili SHA-256) za niz koji smo odredili, a
kao ključ koristiti tajni ključ koji je korisnik dobio pri izradi Amazon AWS računa.
4. Prevesti HMAC potpis u Base 64 format [39].
5. Potpis u formatu Base 64 spremiti u parametar Signature koji je dio HTTP(s) zahtjeva.

POSTn
sqs.us-east-1.amazonaws.comn
207121356507/Testn
AWSAccessKeyId=< Korisnikov AWS Access Key ID>
&Action=SetQueueAttributes
&Attribute.Name=VisibilityTimeout
&Attribute.Value=90
&Expires=2008-02-10T12%3A00%3A00Z
&SignatureMethod=HmacSHA256
&SignatureVersion=2
&Version=2009-02-01

Slika 2.14: Primjer niza koji je potrebno potpisati

POSTn
sqs.us-east-1.amazonaws.comn
207121356507/Testn
AWSAccessKeyId=<Korisnikov AWS Access Key ID>
&Action=SetQueueAttributes
&Attribute.Name=VisibilityTimeout
&Attribute.Value=90
&Expires=2008-02-10T12%3A00%3A00Z
&SignatureMethod=HmacSHA256
&SignatureVersion=2
&Version=2009-02-01
& Signature=jVJSWV50VWlN1CGU9wE1vS4UEikgz0E9W1BuEScyGOI%3D

Slika 2.15: Primjer potpisanog HTTP(s) zahtjeva

Napomena: Zaglavlje HTTP(s) zahtjeva mora obavezno sadržavati Content-Type:
application/x-www-form-urlencoded; charset=utf-8. Charset=utf-8 je neobavezan parametar, ali
trebalo bi ga uvijek postaviti radi višejezične podrške.

27

Tablica 2.3 i Tablica 2.4 prikazuju primjer zahtjeva/odgovora Amazon SQS poruke izvršene od
strane klijenta. Svaki HTTP(s) zahtjev sastoji se od zaglavlja i tijela. U zaglavlju su uvijek
prisutni parametri POST (ili GET), Content-Type i User-Agent dok su ostali parametri zaglavlja
automatski nadodani od strane klijenta. POST predstavlja tip metode koja se izvršava, Content-
Type predstavlja tip sadržaja (ako želimo imati podršku za dijakritičke znakove tada je potrebno
imati postavku charset=utf-8 u zaglavlju HTTP(s) zahtjeva), Host predstavlja odrediše regije u
kojoj se usluga Amazon SQS nalazi dok ostali parametri zaglavlja nisu uzeti u obzir.

Tablica 2.3: Tijelo HTTP zahtjeva nadgledano od Wireshark alata za nadgledanje IP prometa

Zaglavlje HTTP zahtjeva
POST http://sqs.us-east-1.amazonaws.com/207121356507/Test HTTP/1.1
Content-Type: application/x-www-form-urlencoded; charset=utf-8
User-Agent: aws-sdk-java/1.1.9 Windows_7/6.1 Java_HotSpot(TM)_Client_VM/14.2-b01
Host: sqs.us-east-1.amazonaws.com
Proxy-Connection: Keep-Alive
Content-Length: 291

Tablica 2.4: Tijelo HTTP odgovora nadgledano od Wireshark alata za nadgledanje IP prometa

Tijelo HTTP odgovora

MessageBody=%C5%BD%C5%BE%C4%90%C4%91%C5%A0%C5%A1%C4%8C%C
4%8D%C4%86%C4%87%21&Action=SendMessage&SignatureMethod=HmacSHA256
&AWSAccessKeyId=AKIAJ4E7FUK2P44ECKMA&SignatureVersion=2&Version=200
9-02-
01&Signature=jVJSWV50VWlN1CGU9wE1vS4UEikgz0E9W1BuEScyGOI%3D&Time
stamp=2011-04-12T23%3A00%3A54.224ZHTTP/1.1 200 OK
Content-Type: text/xml
Server: AWS Simple Queue Service
<?xml version="1.0"?>
<SendMessageResponse xmlns="http://queue.amazonaws.com/doc/2009-02-
01/"><SendMessageResult>
<MD5OfMessageBody>3d099411fec3af188f51efb884653c1c</MD5OfMessageBody>
<MessageId>f599352c-ed31-4893-b2c2-163bdf2da5db</MessageId>
</SendMessageResult>

28

<ResponseMetadata><RequestId>ee88379d-6f8d-45e5-a6ee-
e9fc7abea128</RequestId></ResponseMetadata>
</SendMessageResponse>

Da bi se slanje poruka mrežom Internet odvijalo na siguran način potrebno je učiniti dva koraka:

 Zahtjev je potrebno uputiti kao HTTPS zahtjev čiji se sadržaj (zaglavlje i tijelo)
automatski enkriptira temeljem dogovora između klijenta i poslužitelja. Na taj način
neovlaštena treća strana nema mogućnosti čitati sadržaj poruka osim IP adrese izvora i
odredišta koje su ionako javno poznate. Takav način komunikacije koristi se i u
bankarskom sektoru prilikom novčanih transakcija (npr. plaćanje i uplate na tekući
račun).
 Da bi se povećala sigurnost provjere valjanosti klijenata potrebno je izraditi javni i
privatni ključ sa ograničenom odgovornošću. To se radi pomoću usluge Amazon IAM
[40] što znači da se nekim klijentima može (a i ne mora) omogućiti izvršavanje određenih
akcija usluge Amazon SQS.

Slika 2.16: Odobrenje (autorizacija) i provjera valjanosti (autentifikacija) klijenata pomoću usluge Amazon IAM

29

Opis slike Slika 2.16:

 Korak 1 – 2: Klijent 1
a) Korak 1 - zahtjev klijenta 1 je ispravan jer HTTP(s) zahtjev sadrži ispravan
parametar AWSAccessKeyId i potpis koji je izrađen uz pomoć tajnog
AWSSecretKey ključa.
b) Korak 2 - Nakon provjere ispravnosti zahtjeva klijenata, usluga Amazon SQS
provjerava akcije (Slika 2.17 - parametar Action: DeleteMessage,
GetQueueAttributes, ReceiveMessage, SendMessage) koju su dozvoljene klijentu
1 izvršavati.

Slika 2.17: Primjer postavki dozvole usluge Amazon SQS za spremnik poruka „Test“

 Korak 3 – 4: Klijent 3
a) Korak 3 - zahtjev klijenta 1 za brisanjem spremnika poruka „Test“ je ispravan jer
HTTP(s) zahtjev sadrži ispravan parametar AWSAccessKeyId i potpis koji je
izrađen uz pomoć tajnog AWSSecretKey ključa.
b) Korak 4 - Nakon provjere ispravnosti zahtjeva klijenta, usluga Amazon SQS
provjerava akcije koje su dozvoljene klijentu 3 izvršavati. Unutar liste akcija
(Slika 2.17) ne postoji akcija DeleteQueue što znači da je klijentu 3 zahtjev
odbijen.

30

 Klijent 2 – nema ispravan parametar AWSAccessKeyId ili izrađen potpis uz pomoć tajnog
AWSSecretKey ključa. Daljnje provjere neće biti izvršavane.

31

3. IZRADA UKUPNOG TROŠKA KORIŠTENJA USLUGE AMAZON SQS
I USPOREDBA SA UKUPNIM TROŠKOM ODRŽAVANJA
POSLUŽITELJA ORACLE WEBLOGIC – IBM WEBSPHERE

U današnje doba velikih tehnoloških i ekonomskih promjena, jedna stvar ostaje nepromjenjena
za organizaciju bilo koje veličine: poslovni pritisak za smanjenjem IT troškova i iskorištavanje
najvećih poslovnih vrijednosti iz postojećih i budućih investicija. Aplikacijski poslužitelji su
ključni u ovoj nakani, nudeći bolju uporabu i raspodjelu IT mogućnosti, povećanu agilnost i
proširene vrijednosti za postojeća IT ulaganja. Mogu igrati i ključnu ulogu u rasterećenju
oblačnog modela usluga. Ali pod koju cijenu? U idućim podpoglavljima prikazani su troškovi
ulaganja u vlastiti sustav razmjena poruka i tehničke razlike između poslužitelja Oracle
WebLogic i usluge Amazon SQS u svrhu donošenja konačne odluke o isplativosti ulaganja u
vlastiti sustav za razmjenu poruka naspram oblačnog modela.

3.1. Ukupan trošak održavanja poslužitelja Oracle WebLogic - IBM
WebSphere

U ovome podpoglavlju prikazani su rezultati istraživanja Crimson Consulting Group tvrtke koji
su objavljeni u svibnju 2011 godine [41]. Istraživanje se bavilo izračunom ukupnih troškova
poslovanja (TCO) komercijanih poslužitelja Oracle WebLogic i IBM WebSphere. U izračun
cijene uključeni su troškovi stjecanja (acquisition), razvoja aplikacija, testiranja, podrške i
promjene postavki. Cilj istraživanja je bio dokazati bolju ekonomsku isplativost korištenja
poslužitelja Oracle WebLogic u odnosu na poslužitelj IBM WebSphere. Naravno, treba imati na
umu da je istraživanje naručeno zbog velikih tvrtki koje imaju dovoljno novca priuštiti si ovakve
sustave.

Osnovni model sustava koji se koristio u istraživanju sastojao se od pet poslužitelja (svaki
poslužitelj ima dva procesora, a svaki procesor dvije jezgre). Na svakom poslužitelju radile su
četiri instance poslužitelja Oracle WebLogic ili poslužitelja IBM WebSphere. Svaki poslužitelj
pokretao je četiri jedinstvene aplikacije.

Istraživanje Crimson Consulting Group tvrtke je obuhvatilo trenutno važeće cjenike tvrtki Oracle
i IBM, (cjenici od ožujka 2011 godine), politiku prodaje licenci, detaljne razgovore sa osobljem
šesnaest organizacija koje koriste poslužitelje Oracle WebLogic i IBM WebSphere. Razgovarano
je i sa admnistratorima koji održavaju ovakav tip sustava. Na temelju vlastitog iskustva

32

odgovarali su na pitanja u vezi instalacije, općih promjeni postavki, grozd postavki, nadogradnje,
izrade instanci, razmjene podataka, nadgledanja, održavanja baze podataka, alarma i prilagodbe.
Dobiveni odgovori pomogli su u izradi modela troška za voditelje informatičkih odjeljenja u
stvarnom okolišu.

Slika 3.1 prikazuje ukupne troškove poslovanja koje kupac poslužitelja Oracle WebLogic ili
poslužitelja IBM WebSphere mora imati na raspolaganju u razdoblju od pet godina. Iz dobivenih
rezultata može se zaključiti da je poslužitelj Oracle WebLogic za razdoblje od pet godina jefiniji
za 46% u odnosu na poslužitelj IBM WebSphere, dok početni troškovi za prvu godinu su jeftiniji
88%.

Napomena: Cijene su izražene u američkim $ USD dolarima.

Slika 3.1: Ukupni troškovi posjedovanja poslužitelja WebLogic i WebSphere [41]

Što to znači za male i srednje velike tvrtke (ili čak početnike na IT tržištu) koji žele pokušati
ponuditi visoko pouzdani i podesiv sustav koji koristi sustav za razmjenu poruka za povezivanje
heterogenih SOA usluga? Iz rezultata istraživanja za tradicionalne sustave može se zaključiti da

33

si najbolje komercijalne sustave male i srednje tvrtke ne mogu priuštiti. Jedino što im preostaje
riskirati sa rješenjima otvorenog koda (open source solution) koja tehnički ne moraju biti loša
(npr. HornetQ, Apache MQ, Rabbit MQ, JBossMQ), ali cijena i uloženo vrijeme petogodišnjeg
održavanja poslužitelja je nepoznata. Za pretpostaviti je da bi cijena rješenja otvorenog koda za
razmjenu poruka bila niža od komercijanog zbog besplatne licence, ali ostali troškovi održavanja
mogu čak biti i isti. Kao drugo rješenje postoji mogućnost povezivanja heterogenih SOA usluga
korištenjem oblačnog sustava za razmjenu poruka Amazon SQS. Da bi usluga Amazon SQS bila
isplativa za korištenje mora imati gotovo podjednaka tehnička svojstva kao standardna usluga
JMS i biti financijski priuštiv. Kao rezultat višemjesečne faze istraživanja (uspoređivanja
svojstava poslužitelja Oracle WebLogic i usluge Amazon SQS) nastala je Tablica 3.1 koja
prikazuje najvažnija svojstva jedne i druge usluge.

Tablica 3.1: Usporedba svojstava poslužitelja Oracle WebLogic i usluge Amazon SQS

Usluga Poslužitelj Oracle WebLogic kao davatelj JMS
Svojstvo
Amazon SQS usluge

Najveća Neograničen Ovisi o veličini JVM memorije, o količini i veličini
dozvoljena broj poruka tvrdih diskova na kojima će se poruke pohranjivati
veličina imenika unutar imenika
poruka poruka

Kvaliteta usluge Moguće je da Jamči da će poruka iz imenika biti dostavljena samo
potrošač iz jednom na zahtjev potrošača
(QoS) imenika
poruka dohvati
jednu te istu
poruku više
puta

Podesiv broj NE DA
dohvaćanja
poruka

Sigurnost X509 potvrda X509 potvrda, SSO, SAML

Odobrenja i DA DA
provjera
valjanosti
vanjskih
korisnika

(Authorization

34

and
authentification
of third-party
users)

Protokoli HTTP, HTTPS HTTP, HTTPS, RMI, IIOP, t3, t3s

Trajnost poruka Uvijek Neobavezno
prisutno

Podesivost Uvijek Samo u grozd-u
prisutno

Raspoloživost Uvijek Da bi se postigla visoka raspoloživost potrebno je
prisutno predvidjeti preseljenje postavki i podataka JMS
poslužitelja

Redoslijed Nije Može se podesiti da bude zajamčeno, ali nije obavezno
poruka zajamčeno

Slanje više DA NE
poruka u jednom
zahtjevu

Brisanje više DA NE
poruka u jednom
zahtjevu

Podesiva kontrola NE DA
toka

Potvrda primitka NE DA
poruke

Najdulje 1 sat – 14 dana 1 ms ~ 2 milijuna godina
dopušteno
vrijeme života
poruke unutar
spremnika

Najveća 65,536 byte; Neograničeno
dopuštena početna
veličina jedne vrijednost je
poruke 8192 byte

Sažimanje NE DA
sadržaja poruke

35

Grafičko DA DA
korisničko
sučelje za
izmjenu postavki

Komercijalna DA (pogledati DA (10 000$ - 25 000$ po procesoru) [42]
licenca Tablica 3.2 za
detalje)

Temeljem usporedbe svojstava može se zaključiti da je usluga Amazon SQS potpuno tehnički
uporabljiva za povezivanje sa heterogenim SOA uslugama. Jedini nedostaci usluge Amazon SQS
su: ograničena veličina poruke, najdulje dopušteno vrijeme života poruke unutar spremnika te
mogućnost primanja jedne te iste poruke više puta. Navedeni nedostaci se mogu nadomjestiti
kvalitetnijom i podesivom izradom svojstava potrošača-proizvođača poruka te višestruke
provjere stanja spremnika poruka u pravilnim vremenskim radobljima (npr. provjeriti svakih 30
minuta da li ima poruka u spremniku). Višestruke provjere stanja spremnika (kao i samo slanje i
primanje poruka) ima svoju ekonomsku cijenu jer se svaki zahtjev i vraćena količina podataka u
odgovoru se naplaćuje pa je izračun troškova usluge Amazon SQS opisan u idućem
podpoglavlju.

3.2. Ukupan trošak korištenja usluge Amazon SQS

U ovome podpoglavlju cilj je napraviti usporedbu i dokazati bolju ekonomsku isplativost
korištenja usluge Amazon SQS (namjerno je odabrana riječ korištenje a ne riječ održavanje jer
korisnik ne mora održavati infrastrukturu usluge Amazon SQS) u odnosu na ulaganje u vlastiti
sustav za razmjenu poruka. Prednost ne ulaganja u vlastitu infrastrukturu je u kraćem vremenu
promjene postavki korištenjem grafičkog sučelja za upravljanje uslugom Amazon SQS, brži
izlazak proizvoda na tržište i manje razvojnih inženjera za održavanje sustava poruka.

Osnovna vodilja poslovanja sa uslugom Amazon SQS je „Plati samo ono što si potrošio“. Ne
postoje nikakve dodatne naplate ili pretplate za održavanje sustava razmjene poruka. Cjenik je
transparentan te se stanje novčanog duga može provjeriti svaki trenutak koristeći sustav za
praćanje stanja računa (Account Activity) tvrtke Amazon.

36

Napomena: Cijene su izražene u američkim $ USD dolarima ovisno o regiji.

Ukupna cijena korištenja usluge Amazon SQS sastoji se od dvije stavke:

 O broju HTTP(s) zahtjeva upućenih uslugi Amazon SQS (0.000001 $ po jednom
zahtjevu. To znači da je cijena 1 milijun zahtjeva 1.00 $).
 Izlazni promet - količina prometa usluge Amazon SQS prema potrošačima i
proizvođačima poruka. Naplaćuje se samo ako se promet odvija preko javne mreže
Internet, a ako se odvija unutar mreže tvrtke Amazon (lokalni promet) onda se ne
naplaćuje.

Tablica 3.2: Cjenik izlaznog Internet prometa usluge Amazon SQS od 01.07.2011 [43]

Izlazni promet

Regija Promet Cijena

Prvi GB/mjesečno je
0.000 $/GB
EU (Irska)/US East (Virginia)/US West

besplatan

Do 10 TB/mjesečno 0.120 $/GB
(North Carolina, Oregon)

Idućih 40 TB/mjesečno 0.090 $/GB



Idućih 524 TB/mjesečno Kontaktirati Amazon AWS.

Idućih 4 PB/mjesečno Kontaktirati Amazon AWS.

Više od 5 PB/mjesečno Kontaktirati Amazon AWS.

Prvi GB/mjesečno je
0.000 $/GB
besplatan
Asia Pacific (Singapure)






37


Više od 5 PB/mjesečno
Kontaktirati Amazon AWS.

Prvi GB/mjesečno je 0.000 $/GB
besplatan

Asia Pacific (Tokyo)







Prvi GB/mjesečno je 0.000 $/GB
besplatan

South America (Sao Paulo)







Uvjeti naplate usluge Amazon SQS su vrlo jednostavni i transparentni za korisnika što znači da
je troškove usluge vrlo jednostavno izračunati. Najrazumljiviji prikaz troškova je najbolje
prikazati kroz primjer. Kao primjer odabran je projekt Livemocha [44] koji je pokrenut unutar
infrastrukture Amazon AWS-a sa upogonjenim Amazon EC2 [45] virtualnim instancama.
Livemocha je mrežna stranica sa besplatnim tečajevima učenja stranih jezika i broji više od tri
milijuna korisnika (1.5 milijuna posjeta dnevno) u svijetu. Osmišljena je kao interaktivna

38

zajednica koja okuplja ljude iz cijeloga svijeta koji međusobno uvježbavaju govor nekog stranog
jezika sa školovanim profesionalcima. Da bi se pratila aktivnost svakog pojedinog korisnika
Livemocha bilježi svaku akciju koju korisnik izvrši. Temeljem ukupnog broja dnevnih posjeta
mrežnoj stranici može se pretpostaviti da Livemocha sustav pohranjuje 1.5 milijuna poruka
dnevno u spremnik poruka usluge Amazon SQS i isto tako prikuplja najmanje 1.5 milijuna
poruka. To znači da sustav najmanje obrađuje više od tri milijuna poruka dnevno. Postoje dva
načina izračuna cijene: Sa uključenom cijenom izlaznog prometa i bez cijene izlaznog prometa.
Izlazni promet se naplaćuje samo ako se uslugi Amazon SQS pristupa preko javne mreže
Internet. Ako se uslugi pristupa iz Amazon EC2 virtualne instance unutar mreže tvrtke Amazon
tada se izlazni promet smatra lokanim prometom i ne naplaćuje se.

Napomena: Izračun cjenika temeljen je na cjeniku od 01.07.2011 godine za EU regiju. 1$
USD dolar = 1 000 000 HTTP(s) zahtjeva [43].

1. Bez cijene izlaznog prometa (lokalni promet)

a) Ukupna mjesečna cijena = 3 000 000 HTTP(s) zahtjeva dnevno x 30 dana = 90
000 000 HTTP(s) zahtjeva mjesečno = 90 $ mjesečno.

b) Ukupna godišnja cijena = 90 $ mjesečno * 12 mjeseci = 1080 $ godišnje.

c) Ukupna petogodišnja cijena = 1080 $ godišnje * 5 godina = 5400 $ u pet godina.

2. Sa cijenom izlaznog Internet prometa (prosječna veličina jedne poruke 10 kb).
a) Ukupna mjesečna cijena (192.99 $)
 Cijena ovisna o broju zahtjeva = 3 000 000 HTTP(s) zahtjeva dnevno x 30
dana = 90 000 000 HTTP(s) zahtjeva mjesečno = 90 $ mjesečno.
 Cijena ovisna o izlaznom prometu = 3 000 000 HTTP(s) zahtjeva dnevno
* 30 dana* 0,0000095367431640625 Gb = 858.306 Gb mjesečno * 0.120
$ / Gb = 102.99 $ mjesečno.
b) Ukupna godišnja cijena = 192.99 $ * 12 mjeseci = 2315,88 $ godišnje.
c) Ukupna petogodišnja cijena = 2315,88 $ godišnje * 5 godina = 11579,4 $ u pet
godina.

Usporedba cijena pokazuje da je korištenje usluge Amazon SQS preko javne mreže Internet
53.37% skuplje u odnosu na korištenje usluge Amazon SQS unutar mreže tvrtke Amazon.
Temeljem tog saznanja može se zaključiti da je ekonomski dugoročno isplativije postavljati

39

PROGRAMSKI ALAT ZA ADMINISTRIRANJE MREŽNIH USLUGA OGLAŠAVANJA U OBLAČNOM RAČUNARSTVU

PROGRAMSKI ALAT ZA ADMINISTRIRANJE MREŽNIH USLUGA OGLAŠAVANJA U OBLAČNOM RAČUNARSTVU

Recommended

Recommended

More Related Content

Similar to PROGRAMSKI ALAT ZA ADMINISTRIRANJE MREŽNIH USLUGA OGLAŠAVANJA U OBLAČNOM RAČUNARSTVU

Similar to PROGRAMSKI ALAT ZA ADMINISTRIRANJE MREŽNIH USLUGA OGLAŠAVANJA U OBLAČNOM RAČUNARSTVU (17)

More from Kresimir Popovic

More from Kresimir Popovic (20)

PROGRAMSKI ALAT ZA ADMINISTRIRANJE MREŽNIH USLUGA OGLAŠAVANJA U OBLAČNOM RAČUNARSTVU