Post on 25-Apr-2022
Smetanovaulica17
2000Maribor,Slovenija
Ino Murko
INTEROPERABILNOST V PRODUKTU EMIT CLOUD
Magistrsko delo
London, januar 2016
Magistrsko delo univerzitetnega študijskega programa
II
INTEROPERABILNOST V PRODUKTU EMIT CLOUD
Študent: Ino Murko, dipl. inž. rač. in inf. tehnol. (UN)
Študijski program: Računalništvo in informacijske tehnologije (MAG)
Mentor: doc. dr. Tomaž Kosar, univ. dipl. inž. rač. in inf.
Jezikovni pregled: Marjana Jus, prof.
London, januar 2016
III
IV
ZAHVALA
Zahvaljujem se mentorju doc. dr. Tomažu
Kosarju za pomoč in vodenje pri opravljanju
magistrskega dela.
V
INTEROPERABILNOST V PRODUKTU EMIT CLOUD
Ključne besede: REST, SOAP, Erlang, Robot Framework, interoperabilnost, oblak,
hramba podatkov
UDK: 004.2:004.451.5(043.2)
Povzetek
V magistrski nalogi je predstavljen produkt Emit Cloud, ki temelji na protokolu
arhitekture REST. Omenjeni spletni servis je v uporabi podjetja Biokoda, d. o. o., ki ga
bo uporabilo kot gonilno komunikacijsko orodje med napravami ter namiznimi
aplikacijami in samo spletno aplikacijo Emit Cloud, ki omogoča varno hrambo
podatkov v privatnem oblaku. Za rešitev problema bomo uporabili funkcijski
programski jezik Erlang in Robot Framework, s katerim bomo pisali teste
sprejemljivosti in tako zagotovili konsistentnost z zahtevami podjetja. Servis bo med
drugim omogočal brskanje, iskanje, prenašanje in nalaganje datotek, brisanje,
omogočanje različnih pogledov s filtri itd.
VI
INTEROPERABILITY IN EMIT CLOUD PRODUCT
Key words: REST, SOAP, Erlang, Robot Framework, interoperability, cloud, data
storage
UDK: 004.2:004.451.5(043.2)
Abstract
In this master thesis we describe a product called Emit Cloud which uses REST
architecture. The referred web service is in use by Biokoda Ltd., which will be used as
a driving force in connecting devices and desktop applications with web application.
Emit Cloud is a secure in-house file sync and share solution. To solve the problem, we
will use functional programming language Erlang and Robot Framework with which
we will write acceptance tests and ensure consistency with the requirements of the
Company. Service will among other enable browsing, searching, uploading,
downloading files, deleting, enabling different views with filters, etc.
VII
VSEBINA
1 UVOD ....................................................................................................................... 1
2 OBSTOJEČE REŠITVE ........................................................................................ 3
2.1 OWNCLOUD ...................................................................................................... 3
3 UPORABLJENE TEHNOLOGIJE ...................................................................... 5
3.1 ACTORDB ......................................................................................................... 5
3.1.1 Sintaksa in uporaba ................................................................................. 6
3.2 ROBOT FRAMEWORK ....................................................................................... 7
3.2.1 Ključne besede .......................................................................................... 8
3.2.2 Sprejemljivostni testi ................................................................................ 9
4 PROGRAMSKI JEZIK ERLANG ..................................................................... 11
4.1.1 Sintaksa .................................................................................................. 12
4.1.2 Enkratno dodeljevanje ........................................................................... 12
4.1.3 Tipizacija ................................................................................................ 13
4.1.4 Gradnja aplikacij z OTP ........................................................................ 14
5 ARHITEKTURNI STIL REST ........................................................................... 18
5.1 ARHITEKTURNE OMEJITVE ............................................................................ 18
5.1.1 Poimenovanje virov ................................................................................ 18
5.1.2 Enotni vmesnik ....................................................................................... 19
5.1.3 Samoopisujoča sporočila ....................................................................... 20
5.1.4 Hipermedija kot pogon stanj aplikacije................................................. 21
5.1.5 Interakcije brez stanja ............................................................................ 21
6 IMPLEMENTACIJA PRODUKTA EMIT CLOUD ........................................ 22
6.1 ARHITEKTURA APLIKACIJE EMIT CLOUD ..................................................... 22
6.1.1 Arhitekturna načela ............................................................................... 22
6.1.2 Tehnološki pristopi ................................................................................. 24
6.2 IMPLEMENTACIJA MODULOV ......................................................................... 25
VIII
6.2.1 Zahteve strežnika .................................................................................... 25
6.2.2 Implementacija ....................................................................................... 27
6.2.3 Primer implementacije REST zahtevka za pripravo nalaganja datotek
31
6.2.4 Primer implementacije REST zahtevkov za upravljanje uporabnikov 34
6.3 TESTIRANJE APLIKACIJE EMIT CLOUD Z ROBOT FRAMEWORK .................. 38
6.3.1 Primer implementacije testa za filtriranje glasbenih datotek z REST
zahtevkom ............................................................................................................... 40
6.3.2 Izvedba sprejemljivostnih testov s tehnologijo Robot Framework ....... 42
7 REZULTATI ......................................................................................................... 44
8 DISKUSIJA ........................................................................................................... 47
9 VIRI ........................................................................................................................ 50
10 PRILOGE .............................................................................................................. 52
10.1 NASLOV ŠTUDENTA ......................................................................................... 52
10.2 KRATEK ŽIVLJENJEPIS ................................................................................... 52
IX
KAZALO SLIK
Slika 1: OwnCloud arhitektura [1] .................................................................................... 3
Slika 2: Organizacija in distribuiranje podatkovne baze ActorDB [4] ............................. 6
Slika 3: Modularna arhitektura orodja Robot Framework [5] .......................................... 8
Slika 4: Gradnja testnih primerov s ključnimi besedami [6] ............................................ 8
Slika 5: Implementacija višjenivojskih ključnih besed s pomočjo nižjenivojskih [6] ...... 9
Slika 6: Primer dveh supervison dreves [7] .................................................................... 15
Slika 7: Potek poslanega zahtevka .................................................................................. 29
Slika 8: Testi, izvedeni z orodjem Robot Framework .................................................... 43
Slika 9: Aplikacija Emit Cloud za naprave Android s pogledom na datotečni sistem ... 44
Slika 10: Aplikacija Emit Cloud za naprave iOS s pogledom na predvajanje glasbe .... 45
Slika 11: Pogled na prijavo v aplikacijo Emit Cloud s spletnega brskalnika ................. 46
Slika 12: Pogled na vse slike v aplikaciji Emit Cloud s spletnega brskalnika ................ 46
X
SEZNAM PREGLEDNIC
Tabela 1: Dodatne WebDAV metode ............................................................................... 4
Tabela 2: Nekateri tipi HTTP zahtevkov ........................................................................ 19
Tabela 3: HTTP statusne kode ........................................................................................ 20
Tabela 4: Kategorije statusnih kod ................................................................................. 20
Tabela 5: Vir za sklop uporabniki ................................................................................... 36
Tabela 6: Argumenti zahtevka za filtriranje glasbenih datotek ...................................... 41
Tabela 7: Primerjava funkcionalnosti ............................................................................. 48
XI
SEZNAM PROGRAMSKE KODE
Programska koda 1: Primer ActorDB sintakse ................................................................. 6
Programska koda 2: Primer ActorDB sintakse ................................................................. 7
Programska koda 3: Primer ActorDB sintakse ................................................................. 7
Programska koda 4: Primer sintakse Erlang ................................................................... 12
Programska koda 5: Primer sintakse Erlang ................................................................... 12
Programska koda 6: Anonimne funkcije v Erlangu ........................................................ 13
Programska koda 7: Strategija zagona delavskih procesov ............................................ 15
Programska koda 8: Zagon delavskega procesa ............................................................. 16
Programska koda 9: Usmerjanje zahtevka ...................................................................... 30
Programska koda 10: Preusmerjanje zahtevka ............................................................... 30
Programska koda 11: Vstopna funkcija v modulu .......................................................... 31
Programska koda 12: Pričakovan JSON v zahtevku ....................................................... 32
Programska koda 13: Validacija nalaganja datotek ........................................................ 32
Programska koda 14: Ustvarjanje sporočila ................................................................... 33
Programska koda 15: Pridobivanje uporabniškega procesa ............................................ 33
Programska koda 16: JSON odgovor zahtevka .............................................................. 34
Programska koda 17: Obravnavanje odgovorov ............................................................. 34
Programska koda 18: Vstopna funkcija v modul ............................................................ 35
Programska koda 19: Lokalizirano sporočilo ................................................................. 36
Programska koda 20: Ustvarjanje uporabnika ................................................................ 37
Programska koda 21: Telo sporočila ............................................................................... 37
Programska koda 22: Robot Framework zagonska skripta ............................................. 38
XII
Programska koda 23: Prijava z administracijskim računom v orodju Robot Framework
................................................................................................................................. 39
Programska koda 24: Funkcija Post Response ............................................................... 40
Programska koda 25: Implementacija testa za filtriranje glasbenih datotek ................... 41
Programska koda 26: Lastna višjenivojska ključna beseda ............................................ 42
Programska koda 27: Seznam obveznih polj za datoteko ............................................... 42
XIII
UPORABLJENE KRATICE
API programski aplikacijski vmesnik (ang. Application programming
interface)
ATDD testno usmerjeni razvoj (angl. Acceptance test-driven
development)
CORBA arhitektura posrednikov zahtev skupnih objektov (angl. Common
object request broker architecture)
DNS sistem domenskih imen (angl. Domain name system)
DCOM tehnologija distribuiranega povezovanja objektov (angl.
Distributed component object model)
HTML označevalni jezik za oblikovanje večpredstavnostnih dokumentov
(angl. Hypertext markup language)
HTTP protokol za izmenjavo hiperteksta (angl. Hypertext transfer
protocol)
IETF razvojni center za podporo standardizaciji (angl. Internet
engineering task force)
JMS javanska storitev za asinhrono izmenjavo podatkov (angl. Java
messaging service)
JSON format zapisa za izmenjavo podatkov (angl. JavaScript object
notation)
LDAP internetni protokol za dostop do imenikov na osnovi arhitekture
odjemalec-strežnik (angl. Lightweight directory access protocol)
MQ komunikacijsko-sporočilni sistem s čakalno vrsto (angl. Message
queue)
OTP odprta telekom platforma (angl. Open telecom platform)
XIV
PHP PHP: Hypertext Preprocessor
RDBMS relacijski sistem za upravljanje podatkovnih baz (angl. Relational
database management system)
REST predstavitveni prenos stanj (ang. Representational state transfer)
RPC klic za oddaljeni postopek (angl. Remote procedure call)
SOAP protokol za spletne storitve (angl. Simple object access protocol)
SMTP protokol za prenos elektronske pošte (angl. Simple mail transport
protocol)
SSH varna lupina (angl. Secure shell)
TSV v obliki tabel ločene vrednosti (ang. Tab-separated values)
WebDAV protokol za izmenjavo in sinhronizacijo podatkov (angl. Web
distributed authoring and versioning)
WS-* spletne povezovalne tehnologije (angl. Web services)
XML razširljivi označevalni jezik (angl. Extensible markup language)
Interoperabilnost v produktu Emit Cloud
1
1 UVOD
Če primerjamo število naprav, ki morajo delovati s tipično spletno aplikacijo z
evolucijo spleta oz. računalništva, ugotovimo, da se je zelo povečalo. Na začetku je
bilo informacije na internetu mogoče doseči samo s spletnim brskalnikom. Količina
teh je bila majhna. Uporabniki danes želijo dostopati do informacij z vsako napravo,
kar je spodbudilo razvoj interoperabilnosti svetovnega spleta, posledično pa tudi
začetek vzpona spletnih storitev, ki so temeljila na arhitekturah DCOM, CORBA,
SOAP itd. V zadnjem času pa je veliko popularnost pridobila arhitektura REST.
V podjetju Biokoda, d. o. o., izdelujemo spletno aplikacijo, ki bo s pomočjo
natančno definiranega protokola komunicirala z različnimi napravami in s spletnimi
brskalniki. Strežniška aplikacija Emit Cloud omogoča varno sinhronizacijo in
hrambo podatkov v privatnem oblaku. Ti podatki pa se lahko stekajo iz različnih
virov, katerim moramo poenotiti uporabniško izkušnjo. Potrebovali smo spletni
protokol, ki ga podpirajo mobilne naprave iOS, Android in Windows Phone, ter
spletne in namizne aplikacije. Hkrati pa zaradi narave strežniške aplikacije
potrebujemo izredno skalabilnost, razširljivost in zanesljivost. REST in SOAP sta
kot trenutno aktualni arhitekturi prišli v ožji izbor. Odločitev, ki jo bomo pozneje
tudi utemeljili, se je nagibala v smeri REST-a, predvsem zaradi pomanjkanja
avtonomnosti posameznih zahtev SOAP arhitekture ter posledično izgube na
skalabilnosti in okornosti.
REST je izredno sklopljen s protokolom HTTP. Če smo natančni, REST zgolj
predpisuje način uporabe že definiranega protokola HTTP. Z dobrimi praksami nam
zagotavlja enake lastnosti, kot jih ima svetovni splet: skalabilnost, razširljivost,
zanesljivost, prenosljivost itd. Torej natanko to, kar potrebujemo.
Ogledali smo si sorodne aplikacije in njihove rešitve problema, kar bomo opisali v
naslednjem poglavju. Nadaljevali bomo v poglavju 5 in 0, ki ga bomo razdelili na
priporočila, ki smo jih našli v literaturi o gradnji REST arhitektur ter nato opisali
potek naše implementacije, kjer bomo predstavili tudi orodja in programski jezik
Interoperabilnost v produktu Emit Cloud
2
(poglavje 4), s katerimi smo dosegli zastavljene cilje in obseg ter strukturo
aplikacije. Za nadaljnji razvoj aplikacije so izredno pomembni testi sprejemljivosti.
Ti bodo predstavljeni v poglavju 6.3. Nato sledita še predstavitev rezultatov in
diskusija.
V magistrski nalogi skušamo potrditi naslednjo tezo:
Za doseganje željene stopnje interoperabilnosti za spletno aplikacijo Emit Cloud je
primerno izbrati arhitekturni stil REST.
Interoperabilnost v produktu Emit Cloud
3
2 OBSTOJEČE REŠITVE
2.1 Owncloud
OwnCloud se v svojem namenu popolnoma enači s produktom Emit Cloud. Smotrno je, da
opišemo sam produkt in kako so reševali interoperabilnostni problem.
Iz dokumenta o arhitekturi [1] lahko povzamemo sliko 1:
Jedro produkta je PHP-aplikacija, ki se je sposobna izvajati na strežnikih IIS ali Apache in
operacijskih sistemih Windows ali Linux. Jedro aplikacije skrbi za uporabnike, vtičnike,
deljenje in skladiščenja datotek. Med jedrom aplikacije in podatkovnim slojem je
abstrakcija, ki omogoča, da OwnCloud uporablja katero od relacijskih baz Oracle,
MySQL, SQL Server ali PostgreSQL. Z abstrakcijo skladiščenja datotek OwnCloud
omogoča shranjevanje datotek na različnih platformah z uporabo različnih protokolov, na
primer CIFS, NFS ali GFS2 ter Red Hat Storage ali IBM Elastic Storage.
Slika 1: OwnCloud arhitektura [1]
OwnCloud navzven izpostavlja WebDAV vmesnik, s čimer lahko uporabnik upravlja z
njegovimi uporabniškimi podatki. WebDAV ni povsem alternativa arhitekturi REST, saj se
v večini primerov WebDAV drži načel REST-a. Razlika je predvsem v protokolu, kjer je
REST prilagodljiv, WebDAV pa precej specifičen.
Interoperabilnost v produktu Emit Cloud
4
WebDAV je komunikacijski protokol, načrtovan z IETF. Eden izmed ciljev IETF je
zagotavljati interoperabilnost, kar uresničujejo z jasno določenimi specifikacijami. Prva
verzija protokola je izšla leta 1999. IETF specifikacije so brezplačne in javne, kar naredi
protokol privlačen za uporabo podjetjem in odprtokodnim razvijalcem. [2]
Omenjeni protokol, s katerim OwnCloud dosega interoperabilnost, je razširitev protokola
HTTP z dodatnimi metodami. Nove metode in njihovo funkcijo smo zapisali v tabeli 1.
Lock Zaklepanjeviraznamenomzaščititigapred
pisanjem.WebDAV podpira exclusivewrite
lock(vir lahkospreminjasamotisti,kigaje
zaklenil) in shared write lock (vir lahko
spreminjavečavtorjev).
Unlock Odklepanjevira(inverznozaklepanju).
Mkcol Ustvarjanjezbirkoz.map.
Copy Kopiranjevirovinzbirkoz.map.
Move Premikanjevirovinzbirkoz.map.
Propfind Pridobivanjelastnostivirovinzbirkoz.map
v obliki XML. Kadar izvršimo Propfind nad
zbirkooz.mapo,naszanimastruktura,kijo
vsebuje.
Proppatch Hkratno spreminjanje več lastnosti virov in
zbirk oz. map v nedeljivi operaciji (angl.
atomictransaction).
Tabela 1: Dodatne WebDAV metode
Interoperabilnost v produktu Emit Cloud
5
3 UPORABLJENE TEHNOLOGIJE
3.1 ActorDB
Podatkovno bazo ActorDB1 smo razvili v podjetju Biokoda, d. o. o., in sicer za potrebe
lastnega produkta Emit Cloud. ActorDB je podatkovna baza, ki združuje porazdeljeno
računalništvo z relacijskim modelom podatkovne baze, ki je praviloma monolitna in jo je
težko skalirati. Prav tako je močno konsistentna, izredno sočasna in brez šibke točke, ki bi
ustavila celoten sistem (angl. single point of failure). Po zgledu akterskega modela
sočasnega računanja2 razbije kompleksen problem v enostavnejše koncepte akterje. Na ta
način bolje izkorišča strojno opremo in posledično omogoča vzpostavljanje velikih
računalniških sistemov. [3]
ActorDB je podatkovna baza, ki združuje distribuirano računalništvo z relacijskim
modelom podatkovne baze. Za razumevanje slednjega bomo začeli pri standardnih
relacijskih bazah (MySQL, MSSQL, Oracle RDBMS). Te so praviloma monolitne in se
skalirajo po naslednjih principih:
− master/slave ali master/master, vendar mora biti nabor podatkov na vseh
strežnikih,
− denormalizacija (zahtevnost programske kode naraste),
− deljenje (angl. sharing), zahtevnost upravljanja in uporabe podatkovne baze
izredno naraste.
Tudi če podatkovna baza ni pretirano velika, bo imela izredno zahtevne in zapletene
mehanizme zaklepanja v primeru transakcij.
1 ActorDB je odprtokodni projekt podjetja Biokoda, d. o. o., in je dosegljiv na spletnem naslovu
http://www.actordb.com/.
2 »Akterski model (ang. Actor Model) je na matematičnih konceptih osnovan model izračunavanja, ki
omogoča, da je paralelna programska koda lažje razumljiva in bolj modularna, predvsem pa brez
programskih napak, saj je o njej dosti lažje analitično razmišljati.« [14]
Interoperabilnost v produktu Emit Cloud
6
Slika 2: Organizacija in distribuiranje podatkovne baze ActorDB [4]
ActorDB kompleksnost relacijskih baz rešuje tako, da je organiziran v grozde z enim, s
tremi ali petimi vozlišči (slika 2). Število grozdov je neomejeno in vsak grozd predstavlja
enega akterja. Od treh omenjenih vozlišč je eno vozlišče matično, ki izvaja branje in
pisanje, in dve vozlišči, ki sprejemata zapise matičnega. Zapis se zgodi, kadar dosežemo
večinski konsenz (angl. Two-Phase Commit). Če matično vozlišče odpove, bo eno izmed
podrejenih vozlišč izbrano za matično vozlišče.
3.1.1 Sintaksa in uporaba
Za najboljšo uporabo podatkovne baze ActorDB moramo reševati probleme, ki jih lahko
abstrahiramo v posamezne akterje. V aplikaciji Emit Cloud je posamezen akter predstavljal
sam uporabnik. Če poenostavimo in posplošimo delovanje podatkovne baze ActorDB,
lahko rečemo, da ima vsak uporabnik svojo SQLite relacijsko bazo.
Sintaksa za uporabo naše podatkovne baze ni dosti različna od standardne uporabe baz
SQLite ali MySQL, razlika je le v tem, da moramo izbrati, s katerim akterjem želimo
delati.
1. ACTOR tip(identifikator akterja) CREATE; 2. INSERT INTO tabela VALUES(3, 'niz');
Programska koda 1: Primer ActorDB sintakse
Identifikator akterja je identifikator, ki predstavlja posameznega akterja (v naši aplikaciji
je bilo to enolično celo število). Tip akterja predstavlja shemo podatkovne baze. ActorDB
omogoča, da imamo več različnih tipov s popolnoma različnimi shemami. Imamo še
zastavico CREATE, ki jo uporabimo, če akter še ne obstaja in ga želimo ustvariti.
Enaka poizvedba kot v prejšnjem primeru, vendar hkratno pisanje v več akterjev hkrati:
Interoperabilnost v produktu Emit Cloud
7
1. ACTOR tip(akter identifikator1, akter identifikator2) CREATE; 2. INSERT INTO tabela VALUES(3, 'niz');
Programska koda 2: Primer ActorDB sintakse
Zapisujemo lahko tudi v vse akterje istega tipa hkrati:
1. ACTOR tip(*) CREATE; 2. INSERT INTO tabela VALUES(3, 'niz');
Programska koda 3: Primer ActorDB sintakse
3.2 Robot Framework
Robot Framework je programska oprema, ki temelji na programskem jeziku Python in
omogoča pisanje sprejemljivostnih testov zaradi testno usmerjenega razvoja (ATDD).
Uporablja se lahko za testiranje porazdeljenih in heterogenih aplikacij, kjer so v sistem
povezane različne tehnologije. Omogoča [5]:
− enostavno programsko kodo na principu ključnih besed, ločenih s tabulatorjem,
− definiranje novih ključnih besed, ki jih sestavimo s ponovno uporabo že obstoječih
ključnih besed (več o tem v poglavju 3.2.1),
− generiranja poročila v formatu HTML in XML, ki jih lahko integriramo in vpnemo
v sisteme,
− neodvisnost od računalniškega okolja in programske opreme,
− razširjanje osnovnega nabora knjižnic s programskima jezikoma Java ali Python,
− vmesnik z ukazno vrstico,
− Selenium spletno testiranje, javansko grafično testiranje, Telnet, SSH …,
− podatkovno odvisne teste,
− spremenljivke,
− označevanje, s katerim lahko kategoriziramo teste in jih ločeno poganjamo,
− enostavno integracijo z različnimi tehnologijami dokumentiranja sprememb,
− vzpostavitev začetnega in končnega okolja za izvajanje testov.
Robot Framework je generično orodje z modularno arhitekturo, prikazano na sliki 3. Test
data segment je programska koda na principu ključnih besed, ki jih orodje izvede in ustvari
poročila v obliki HTML in XML. Jedro orodja ne pozna sistema, nad katerim izvaja teste
sprejemljivosti (angl. System under test). Interakcija s sistemom pa je izvedena prek testnih
Interoperabilnost v produktu Emit Cloud
8
knjižnic neposredo (angl. Test libraries) ali pa se sklicujejo na orodja na nižji ravni (angl.
Test tools). [5]
Slika 3: Modularna arhitektura orodja Robot Framework [5]
3.2.1 Ključne besede
Rešitev Robot Framework za gradnjo testnih primerov uporablja ključne besede, ki se med
seboj ločijo le po stopnji. Najnižja stopnja ključnih besed izhaja iz knjižnic, ki jih
združujemo in sestavljamo v višje nivojske uporabniške ključne besede. Vse nižjenivojske
ključne besede imajo v svoji implementaciji upravljalca, ki si ga lahko predstavljamo kot
metodo ali podprogram, ki se izvede z določenimi argumenti.
Slika 4: Gradnja testnih primerov s ključnimi besedami [6]
Interoperabilnost v produktu Emit Cloud
9
Slika 5: Implementacija višjenivojskih ključnih besed s pomočjo nižjenivojskih [6]
Na sliki 4 je prikazan primer dveh enostavnih testnih primerov računskih izrazov,
sestavljen iz nižjenivojskih (npr. Input) in višjenivojskih ključnih besed (npr. Add,
Multiply in Equals), katerih implementacija je razvidna na sliki 5.
Izjemna lastnost takšnega načina testiranja je enostavno vzdrževanje in sestavljanje novih
testov, saj ni potrebno znanje programskih jezikov. To drži v primerih, kadar nam
kombinacija višjenivojskih in nižjenivojskih ključnih besed zadošča za izvedbo testa. V
nasprotnem primeru imamo možnost, da definiramo nove nižjenivojske ključne besede v
izbranem programskem jeziku, recimo Python.
3.2.2 Sprejemljivostni testi
S testiranjem lahko preverjamo, ali programska oprema deluje, kot pričakujemo. V našem
primeru je dokumentacija API-ja jasna. Zapisane imamo vhode in pričakovane izhode, na
katere se zanašajo tudi številne zunanje aplikacije. Njihovo pravilno delovanje je odvisno
od nas. Trdimo, da je razvoj programske opreme umetnost, torej, razvoj programske
opreme ni nikoli končan.
Zapisali smo, da je cilj produkta Emit Cloud čim večja interoperabilnost. Evolucija
programske opreme za strežnike in druga programska okolja ne potekajo vzporedno, zato
je pri razvoju treba paziti, da nehote ne pridemo v neskladje z zapisano dokumentacijo, po
kateri delujejo druga programska okolja. Ravno to pa nam omogočajo testi, s katerimi
lahko v vsaki fazi razvoja preverimo delujočo interoperabilnost.
Pomagali smo si z generičnim avtomatskim ogrodjem za testiranje sprejemljivostnih
testov, ki deluje na principu ključnih besed, ločenih s tabulatorjem. Ogrodje, ki je narejeno
Interoperabilnost v produktu Emit Cloud
10
v programskem jeziku Python, nam omogoča, da ga razširimo z zunanjimi knjižnicami ali
da te knjižnice napišemo sami. [6]
Robot Framework uporablja zapis v obliki tabel in podpira številne datotečne oblike, na
primer [5]:
− HTML (s končno pripono .html, .html ali .xhtml),
− TSV (s končno pripono .tsv),
− Plain text (s končno pripono .txt),
− reStructuredText (s končno pripono .rst ali .rest).
Med posameznimi ključnimi besedami moramo, glede na uporabljeno datotečno obliko,
zagotoviti tabelarično notacijo. Mi smo uporabili datotečni format Plain text, za katerega
velja ločitev posameznih ključnih besed z dvema presledkoma ali več.
Interoperabilnost v produktu Emit Cloud
11
4 PROGRAMSKI JEZIK ERLANG
Simfonični orkester je primer paralelnega problema, ki je odporen na napake. Vzporedno
lahko igra več inštrumentov, ki med seboj niso povezani. Če ena izmed violin neha igrati,
se zaradi tega orkester ne ustavi.
Če si predstavljamo reševanje problema simfoničnega orkestra s sekvenčnimi jeziki (C++,
Java, Ruby, C#), ugotovimo, da nam abstrakcije, ki so na voljo, niso pretirano v pomoč. V
nobenem primeru pa nam abstrakcije ne omogočajo gradnje sistemov, odpornih na napake.
Vsi našteti sekvenčni jeziki paralelizacijo abstrahirajo s pomočjo deljenja pomnilnika med
nitmi, ki v svojem bistvu ne omogočajo izolacije napak (spremenljivo stanje, ang. mutable
state). Dve niti, ki si delita pomnilnik, lahko sicer ugotovita druga za drugo, da je prišlo do
prekinitve, ne moreta pa vedeti, v kakšnem stanju je prekinjena nit pustila pomnilnik. Tako
bo nit, ki bo prevzela delo prekinjene niti, prišla v stanje za katerega ne bo vedela kakšno
je.
Tako ugotovimo, da je za gradnjo paralelnih sistemov pravilna abstrakcija (a ne edina), ki
jo omogoča programski jezik Erlang, ki vpeljuje paradigmo nespremenljivega stanja (angl.
immutable state) in izolacijo napak s principom, kjer je enota za gradnjo sistema proces, ki
sprejema in pošilja sporočila (angl. Actor Model). Omogoča nam tudi lokacijsko
transparentnost, ki nam omogoča da sistem paraleliziramo čez več računalnikov.
Zaradi narave jezika (Erlang je funkcijski programski jezik) moramo izpostaviti nekatere
posebnosti.
Erlang nima klasičnih zank for in while, ampak uporablja rekurzivne funkcijske klice in
upravljanje s seznami, dodeljevanje v spremenljivke poteka prek principa ujemanja
vzorcev in je enkratno, stavke, funkcije in pogojne stavke ločujemo s pikami, z vejicami in
s podpičji. Nekatere posebnosti bomo pojasnili v nadaljevanju.
Interoperabilnost v produktu Emit Cloud
12
4.1.1 Sintaksa
1. povrsina({kvadrat, Velikost}) -> 2. Velikost * Velikost; 3. povrsina({krog, Radij}) -> 4. Pi = 3.14, 5. Pi * Radij * Radij; 6. povrsina(_Neznano) -> 7. napaka.
Programska koda 4: Primer sintakse Erlang
Programiranje v programskem jeziku Erlang je zelo podobno slovenskemu ali angleškemu
pisanemu jeziku. Vejice so namenjene posameznim stavkom, ki jih kot ločeno skupino
zaključimo s podpičjem (tudi v pogojih stavkih). S piko pa zaključujemo celotno misel
funkcije, saj Erlang omogoča funkcije, ki imajo več glav in teles. Izvedlo se bo tisto telo
funkcije, katere glava funkcije se ujema s podanimi parametri.
4.1.2 Enkratno dodeljevanje
Enkratno dodeljevanje ni pravzaprav nič nenavadnega. Deluje popolnoma enako, kot
deluje v algebri. Kadar spremenljivka pridobi neko vrednost, je ne more več spremeniti.
Izredno velika moč Erlanga je ujemanje vzorcev, ki je nekako skrito v samo dodeljevanje.
Imena spremenljivk se morajo začeti z veliko tiskano črko, medtem ko atome pišemo z
malo. [7]
1. > Primer = 1. 2. > Primer = 2. %napaka 3. > X = X + 1. %napaka 4. > [{_, [{ime, Ime}, {priimek, Majcen}, {hobiji, Hobiji}]}]=[{oseba, [{ime,
"Gregor"},{priimek, "Majcen"}, {hobiji, ["tek", "kuhanje"]}]}] 5. 6. > Ime. 7. "Gregor" 8. > Priimek. 9. "Majcen" 10. > Hobiji. 11. ["tek","kuhanje"]
Programska koda 5: Primer sintakse Erlang
Ko spremenljivki dodelimo vrednost, se zgodi ujemanje vzorcev, saj je enačaj operator
ujemanja vzorcev in ne prirejanja kot v nekaterih drugih programskih jezikih. To si
poskušamo pojasniti tako, da rečemo, da se izraz na desni strani poskuša poenotiti s tistim
na levi.
Interoperabilnost v produktu Emit Cloud
13
4.1.3 Tipizacija
V prejšnjih dveh podpoglavjih smo prikazali nekatere primere dodeljevanja in funkcij, ki
pa niso nikjer omenjale tipov posameznih spremenljivk ali tipov, v katerih bo funkcija
vračala vrednosti. Erlang je namreč dinamično tipiziran jezik [7].
− Cela števila
o sistem#zapis
§ 2#001
§ 16#a
§ 5
− Plavajoča vejica
§ 3.14
− Atom
o Ne numerične konstante.
§ ok, true, false, napaka
− Tuple (n-terica)
o Fiksna količina elementov.
o Elemente lahko gnezdimo.
§ {prvi, drugi, {tretji, 3}}
− List (seznam)
o Seznami so standardni tip v funkcijskih jezikih [8].
o Sestavljeni so iz glave in teles [8].
o Vsebujejo poljubne tipe in tudi druge sezname [8].
§ [ 1, 2, 3, [ števila, besede, "primer"]]
Erlang nam omogoča tudi anonimne funkcije, ki so enake drugim funkcijam, le da ne
morejo klicati same sebe. Anonimno funkcijo lahko zapišemo v telesu standardne funkcije
in jo prenašamo naprej kot argument druge funkcije. To so funkcije prvega tipa.
1. F = fun(X, Y) -> 2. X1 = X * 2, 3. Y1 = Y * X, 4. X1 + Y1 5. end.
Programska koda 6: Anonimne funkcije v Erlangu
Interoperabilnost v produktu Emit Cloud
14
4.1.4 Gradnja aplikacij z OTP
OTP je ogrodje, ki ga uporablja večina aplikacij, napisanih v programskem jeziku Erlang.
Prinaša nam nekatere principe, ki nam omogočajo gradnjo zahtevnih strežniških sistemov.
Ti principi nam opisujejo, kako naj se neki proces obnaša (angl. behaviours) [8]:
− supervisor: proces, katerega naloga je nadzorovanje drugih procesov in ukrepanje
ob napaki,
− gen_server: splošna implementacija strežnika, to, kar je skupno vsakemu
strežniku: prejemanje in odgovarjanje na zahteve,
− gen_event: implementacija procesov, ki prejemajo dogodke; primer je beležnik
aktivnosti (angl. event logger),
− gen_fsm: implementacija končnih avtomatov,
− application: vsebnik za aplikacije.
Ni nenavadno, da ima aplikacija v Erlangu 100.000 ali več procesov. Vsak proces
predstavlja majhno opravilo, ki ga opravlja zelo dobro. Procesi so sami po sebi sekvenčni.
Predstavljamo si jih lahko kot kolonijo mravelj, ki med seboj komunicirajo s sporočili.
Omenimo, da ne gre za sistemske procese, ampak za procese virtualnega stroja
programskega jezika.
Principa supervisor in gen_server, ki ju uporabljamo tudi v aplikaciji Emit Cloud, bomo
opisali podrobneje, saj sta izredno pomembna za natančnejše razumevanje delovanja
sistema.
»Kadar gradimo sistem, ki mora delovati večno, moramo pomisliti tudi na napake, ki se
bodo zgodile. Velikih sistemov nikoli ne moremo tako dobro testirati, da bi odstranili vse
napake, ki se lahko zgodijo. Torej potrebujemo mehanizme, ki nam bodo omogočali, da
napake, ki so povzročile sesujte strežnika, ujamemo in omogočimo ponovni zagon. To
lahko dosežemo z gradnjo supervisor dreves, ki bo nadzorovalo strežnike in jih ponovno
zagnalo ob sesutju. drevo Supervisor je drevo procesov. Višje pozicionirani procesi
nadzirajo nižje pozicionirane (delavce). Poznamo različne tipe dreves:
− One-for-one
o Če se sesuje eden izmed nadzorovanih procesov, ga bo supervisor ponovno
zagnal. Prikazano na sliki 6.
Interoperabilnost v produktu Emit Cloud
15
− Simple-one-for-one
o Enostavnejša različica One-for-one, ki ponovno zaganja procese istega tipa.
− One-for-all
o Če se sesuje eden izmed nadzorovanih procesov, bo supervisor ukrepal
tako, da bo prekinil delovanje vseh podrejenih procesov (s klicem funkcije
terminate/2) in ponovno zagnal vse procese. Prikazano na sliki 6.
− Rest-for-one
o Če se sesuje eden izmed nadzorovanih procesov, bo supervisor ukrepal
tako, da bo prekinil delovanje vseh podrejenih procesov (s klicem funkcije
terminate/2), ki so bili zagnani za tem procesom, in jih ponovno zagnal v
enakem zaporedju.
Slika 6: Primer dveh supervison dreves [7]
Procese Supervison kreiramo z OTP principi v povratnem modulu (angl. callback module),
kjer definiramo strategijo delovanja in kako bomo zaganjali delavske procese. Prej
omenjeno drevo definiramo s funkcijo:
1. init([])-> 2. {ok, {StrategijaPonovnegaZagona, MaxSteviloPonovitev, Cas}, 3. [Delavec1, Delavec2, …]}.
Programska koda 7: Strategija zagona delavskih procesov
Vrednosti pri strategiji zagona delavskega procesa so:
− StrategijaPonovnegaZagona o Eden izmed atomov one_for_one ali one_for_all.
Interoperabilnost v produktu Emit Cloud
16
− MaxSteviloPonovitev in Cas o Frekvenci ponovnega zagona delavskih procesov.
Če nadzorni proces preseže MaxSteviloPonovitev in Cas in še vedno ne uspe vzpostaviti
delavskega procesa, prekine vse procese in na koncu še sebe. Poglejmo primer, kako
definiramo zagon delavskega procesa.
1. {Tag, {Mod, Func, ArgList}, 2. Restart, 3. Shutdown, 4. Type, 5. [Mod1]}
Programska koda 8: Zagon delavskega procesa
Vrednosti pri zagonu delavskega procesa so:
− Tag
o Ime delavskega procesa.
− {Mod, Func, ArgList}
o Definicija funkcije, ki jo bo klical supervisor ob zagonu (parametri so
namenjeni za apply(Mod, Func, ArgList)).
− Restart = permanent | transient | temporary
o Kadar bo parameter Restart nastavljen na permanent, bomo dotični
delavski proces zagnali vedno ponovno. Kadar je parameter nastavljen na
transient, ga bomo ponovno zagnali v primeru nepričakovane napake
(kadar proces vrne atom normal, shutdown ali n - terico {shutdown,Term}
to ni nepričakovana napaka). Kadar pa je parameter nastavljen na
temporary, procesa nikoli ne zaženemo znova.
− Shutdown
o Parameter, ki določa, koliko časa se lahko delavski proces ustavlja. Po
pretečenem času ga supervisor prekine.
− Type
o Parameter, ki je namenjen gradnji dreves, lahko ima vrednost worker ali
supervisor.
− [Mod]
o Definicija povratnega modula (angl. callback module), če je ta strežnik
(gen_server).
Interoperabilnost v produktu Emit Cloud
17
Z uporabo vseh omenjenih OTP principov lahko dosežemo sisteme z neprekinjenim
delovanjem 99.999999999 % odstotka časa, kot je to uspelo Ericssonu.« [7]
Interoperabilnost v produktu Emit Cloud
18
5 ARHITEKTURNI STIL REST
REST je usklajen niz arhitekturnih omejitev, ki poskušajo minimizirati latenco in omrežno
komunikacijo ter maksimizirati neodvisnost in skalabilnost posameznih komponent. Cilj
dosežemo s postavitvijo omejitev na semantiki priključka (angl. connector semantics),
medtem ko so se drugi arhitekturni stili osredotočili na semantiko komponent. REST
omogoča predpomnjenje in ponovno uporabo interakcij, dinamično zamenljivost
komponent, obdelavo posredniških akcij s ciljem zadovoljiti zahteve hipermedijskih
sistemov na svetovnem spletu. [11]
5.1 Arhitekturne omejitve
Arhitekturne omejitve, ki jih predstavljamo v nadaljevanju, povzete po opombi [13], se
prav nič ne oddaljujejo od tega, kaj splet pravzaprav je in kako deluje. Če želimo spletno
aplikacijo nadgrajevati, razširjati in skalirati, je dobro, da se držimo teh omejitev.
5.1.1 Poimenovanje virov
Gradniki HTTP-ja so enotni identifikatorji vira in viri. Kaj vir je oziroma kaj vir ni, ne
moremo reči natančno, saj nam HTTP omogoča, da upravljamo z logično predstavitvijo ali
informacijo vira in ne z objektom samim. Tako je lahko vir glasba, proces nakupa v spletni
trgovini ali dokument. Skoraj vse lahko predstavimo kot vir. Oblike predstavitve so
različne glede na potrebe. Med popularnejšimi so XHTML, XML, JSON, PNG. Odjemalec
bo zato včasih prejel predstavitev vira, ki pa ne bo identična viru, ki ga ima strežnik.
Različni enotni identifikatorji vira lahko usmerjajo na isti vir, ne morejo pa usmerjati na
več različnih virov. Med viri in enotnimi identifikatorji vira velja pravilo ena proti mnogo.
Kot primer vzemimo spletna naslova http://primer.com/slika1.png in
http://primer.com/slika1.jpg. V našem primeru oba enotna identifikatorja vira kažeta na
identičen vir, le predstavitev vira je drugačna. Treba je poudariti, da nas prav nič ne
obvezuje, da drugi enotni identifikator vira ne bi kazal na povsem drug vir. HTTP sam po
sebi nima mehanizmov, s katerimi bi lahko odkrivali identične vire, skrivajoč se pod
različnimi enotnimi identifikatorji vira.
Poimenovanje virov lahko sklenemo z napotkom:
Interoperabilnost v produktu Emit Cloud
19
Viri, ki so pomembni za aplikacijo in njeno stanje, naj imajo pomenljiva in globalno
enoznačna imena. Pomembno je, da viri ne predstavljajo zgolj »stvari«, s katerimi
aplikacija upravlja, ampak tudi informacije, ki so potrebne, da lahko o teh stvareh
govorimo. [10]
5.1.2 Enotni vmesnik
Vse interakcije z viri naj uporabljajo isti vmesnik. Ta vmesnik naj bo nabor metod, ki so
zadostne za upravljanje z njimi. Ravno to predstavlja popolno nasprotje spletnih storitev, ki
se poslužujejo RPC načina delovanja, tj. izpostavljanja metod, ki jih je mogoče izvesti na
daljavo. REST zgolj izpostavi vire, ki jih je mogoče upravljati s skupnim vmesnikom oz.
podmnožico teh. [10]
Posamezna metoda je zahtevek, ki narekuje strežniku, kako naj zahtevek izvede in kako
naj nanj odgovori. V tabeli 2 bomo zapisali, kako so nekatere metode definirane, in
pričakovanja, ki jih imajo do strežnika.
Metoda Opis
GET Metodapričakuje,dastrežnikpridobi invrnepredstavitevvira,ki je
bilidentificiranzenotnimidentifikatorjemvira.
POST Metoda pričakuje, da strežnik sprejme podatke, ki so v telesu
sporočila,indapodatkeshrani.
PUT Metoda pričakuje, da strežnik sprejme podatke, ki so shranjeni v
telesusporočila,indavirspodatkiposodobi.
DELETE Metodapričakuje,dastrežniknajdeviringaizbriše.
OPTIONS Pridobiinvrnemetode,kisonavoljozavir.
HEAD Metoda pričakuje, da strežnik pridobi in vrne meta podatke vira v
glavisporočila.
Tabela 2: Nekateri tipi HTTP zahtevkov
Strežnik, ki zahtevek izvede, odgovori s predefiniranimi HTTP statusnimi kodami. V tabeli
3 predstavimo najpogostejše in v tabeli 4 kategorije statusnih kod.
Interoperabilnost v produktu Emit Cloud
20
Statusna koda Opis
100 Odjemalec naj nadaljuje z zahtevkom.
200 Zahtevek je bil uspešno izveden.
201 Zahtevek je bil uspešno izveden in ustvarjen je bil vir.
301 Viru je bil spremenjen enotni identifikator vira.
400 Strežnik zahtevka ni razumel.
404 Vira ni bilo mogoče najti.
500 Napaka na strežniku.
Tabela 3: HTTP statusne kode
Kategorija Opis
1xx Kategorijastatusnihkod,namenjenazainformativneodgovore.
2xx Kategorijastatusnihkod,namenjenazauspešnoizvedenezahtevke.
3xx Kategorija statusnih kod, namenjena virom, za katere je potrebno
dodatnoukrepanje,čeželimozahtevekizvesti.
4xx Kategorija statusnih kod, namenjena opozoriti odjemalca, da
zahtevekvsebujenapako.
5xx Kategorijastatusnihkod,namenjenaopozoritiodjemalca,dastrežnik
nizmoženizvestizahtevka,kerjenaredilnapako.
Tabela 4: Kategorije statusnih kod
HTTP izpostavlja nekatere metode in statusne kode, ki so temeljni in zadostni pogoj za
večino spletnih aplikacij in upravljanje z viri.
5.1.3 Samoopisujoča sporočila
Interakcije z enotnim vmesnikom se imenujejo sporočila, ki morajo biti samoopisujoča in
samozadostna za obdelavo. [10]
Interoperabilnost v produktu Emit Cloud
21
Z izpolnjevanjem tega pogoja pridobimo na nevezanosti. Strežniku sedaj ni treba ohranjati
stanja aplikacije, navezujoč se na posameznega uporabnika ali serijo zahtevkov. Posebej
uporabno je v primeru, kadar želimo spletne aplikacije horizontalno skalirati. Če so
sporočila, poslana na strežnik, samozadostna, lahko zahtevek izvede vsak strežnik, saj za
izvedbo zahtevka ne potrebuje informacij, ki bi jih lahko imel samo nek strežnik, ki je
predhodno že obdeloval zahtevke iz serije.
5.1.4 Hipermedija kot pogon stanj aplikacije
Viri bi morali biti med seboj povezani, s čimer bi omogočili odkrivanje novih virov, ki so
dosegljivi prek enotnega vmesnika. To nam omogoča interakcijo, ki se prilagaja med
izvajanjem in tako omogoča šibko sklopljenost. Brez povezanih virov bi bilo tudi
nemogoče zagotavljati transakcije. [10]
5.1.5 Interakcije brez stanja
Vsaka interakcija med odjemalcem in strežnikom mora biti samostojna s čimer
omogočimo skalabilnost strežniškega sistema. Torej strežnik naj ne bi vodil seje
uporabnika s čimer bi povzročili odvisnosti med sejo in viri. [10]
Drži, da nam REST predpisuje nekatere arhitekturne omejitve imamo pa toliko bolj prosto
izbiro, pri vsebini protokola. Tako lahko po lastnih potrebah gradimo domensko specifične
aplikacije na ogrodju REST.
Interoperabilnost v produktu Emit Cloud
22
6 IMPLEMENTACIJA PRODUKTA EMIT CLOUD
Strežniška aplikacija produkta Emit Cloud je bila implementirana v programskem jeziku
Erlang s pomočjo platforme OTP, ki jo Ericsson daje na voljo za prosto uporabo.
Platforma OTP je nastala leta 1996 in uporabljajo jo skoraj vse aplikacije, ki potrebujejo
robustnost, in metode preskakovanja napak. Platforma vsebuje tudi številna orodja in
knjižnice. [9]
6.1 Arhitektura aplikacije Emit Cloud
Arhitektura programske opreme definira razdrobljenost, komunikacijske protokole in
umešča posamezne elemente tako, da njihovo sodelovanje tvori sistem. Arhitekturni stil je
koordiniran nabor omejitev vlog in povezav med posameznimi elementi, ki so del neke
arhitekture programske opreme in podrejene nekemu arhitekturnemu stilu. Stil torej daje
ime skupku arhitekturnih odločitev in arhitekturnih lastnosti. [9]
V procesu implementacije je bilo treba izbrati primerno arhitekturno zasnovo, ki nam bo
zagotavljala skalabilnosti, razširljivost, zanesljivost, prenosljivost. Arhitekturni stil
navadno izhaja iz uporabljenih tehnologij, ki so na voljo, kadar sistem gradimo.
Tehnologije imajo lastnosti in principe, ki definirajo pristop h gradnji celotne arhitekture.
Arhitektura aplikacije Emit Cloud je izredno pod vplivom akterskega modela sočasnega
računanja, o katerem smo več zapisali v poglavju 4.
Na kratko bomo v naslednjih podpoglavjih povzeli poglavje iz knjige [10], ki primerja
REST in WS-* s treh vidikov, in nato predstavili odločitev.
6.1.1 Arhitekturna načela
Arhitekturna načela so arhitekturni principi, ki sestavljajo tako REST kot tudi SOAP. V
nadaljevanju uporabljamo izraza WS-* in SOAP medsebojno izmenljivo (SOAP pripada
snopu WS-*).
6.1.1.1 Protokolna plast
V primeru WS-* se HTTP šteje kot podaljšek naše spletne aplikacije, ker obravnava HTTP
samo kot transportno plast, ki nam omogoča interakcijo z aplikacijo. Posledično to pomeni
močno sklopljenost.
Interoperabilnost v produktu Emit Cloud
23
Med drugim pa REST šteje HTTP kot medij, s katerim omogoča aplikacijam uporabo teh
storitev, ki postanejo del svetovnega spleta.
6.1.1.2 Heterogenost
Heterogenost WS-* storitev je osredotočena predvsem na podjetniško okolje, iz katerega
izhaja. Tukaj govorimo o podjetjih, katerih tehnologija je lahko tudi starejša od samega
svetovnega spleta. REST heterogenosti ne omogoča sam po sebi, saj predvideva, da vsak
odjemalec uporablja in razume protokol HTTP.
6.1.1.3 Sklopljenost
Časovna sklopljenost
Sinhrone interakacije nikoli ne morejo biti popolnoma ohlapne. Do neke mere jih lahko
sicer priredimo, a ne brez dodatne kompleksnosti. WS-* storitve lahko to stopnjo
ohlapnosti dosežejo s tehnologijo čakalnih vrst. REST pri tem popolnoma odpove, saj se
zanaša izključno na sinhron odgovor strežnika.
Lokacijska sklopljenost
Sklopljenost, ki jo definiramo kot lokacijsko sklopljenost, lahko razrahljamo v primeru
WS-* storitev, kadar uporabimo register za njihovo odkrivanje. Pri storitvah REST lahko
uporabimo DNS prevajanje.
Razširjanje storitev
HTTP metode, ki jih uporablja REST (PUT, POST, DELETE itd.), se ne bodo spremenile,
kar pomeni, da to ni točka sistema, ki bi lahko vplivala na delovanje odjemalcev, kar je v
nasprotju z WS-*, kjer dejansko izpostavljamo metode (npr. akcije izbriši, ustvari, uredi),
ki pa se lahko spremenijo. Oba pristopa imata tudi močno sklopljenost na telo oz. vsebino
sporočila. Sprememba lahko povzroči nedelovanje odjemalcev.
Konceptualna primerjava
Gre za primerjavo pristopov in alternativ teh pristopov, ki so možne znotraj predpisanih
arhitekturnih omejitev, ki jih predpisujeta stila. Tako nam članek [10] predstavi tabelo
primerjav. Povzamemo lahko, da je za arhitekturni stil REST treba sprejeti 8 odločitev, za
katere nam je skupno na voljo le 10 alternativ, in za WS-* vsega 5 odločitev, vendar
imamo na voljo 10 in več alternativ.
Interoperabilnost v produktu Emit Cloud
24
Konceptualna primerjava nam pokaže ali lahko podatke predstavimo v poljubni obliki
(XML, JSON, Protocol buffers idr.), ustvarjamo relacije med podatki, sinhrono ali
asinhrono komunikacijo, kakšna je semantika interkacije z viri, WS-* kombiniranje
operacij itd.
6.1.2 Tehnološki pristopi
Množica tehnoloških odločitev, ki so nam na voljo znotraj arhitekturnih omejitev,
predpisuje, da je tako za REST kot WS-* potrebnih 10 odločitev, za katere ima REST na
voljo 17 alternativ in WS-* 25.
Med tehnološke pristope spadajo tudi izbira oblike podatkov in poimenovanje virov, izbira
transportnega protokola, odkrivanje in identifikacija virov, zanesljivost dostave, varnost in
transakcije idr.
Sklep o izbiri arhitekturnega stila izpeljemo iz primerjave članka [9] in naših zahtev.
Ugotovimo, da se moramo v primeru arhitekturne plasti in sklopljenosti odločiti za REST.
Želimo najmanjšo možno sklopljenost, omogočiti verzioniranje (omogoča tudi SOAP,
vendar je napornejše). Primerjava heterogenosti obeh stilov, ki zadeva predvsem
integracijske sposobnosti v podjetniški ekosistem, nam s tem vmesnikom ni potrebna, je pa
uporabna na drugih delih sistema, kot je izvor uporabnikov (LDAP, lastni varnostni
pregledi datotek, skladiščenje datotek), kar pa ni tema te magistrske naloge.
Konceptualna primerjava nas zgodaj prisili v nekatere arhitekturne odločitve. Podatke z
odjemalci želimo izmenjevati v JSON obliki (Erlang počasi procesira XML), pri čemer
spoznamo, da zaradi tega ne moremo uporabiti SOAP. A to ni edini razlog. Prav tako
želimo vzpostaviti relacije med posameznimi viri (datoteke pripadajo mapam), kar se
sklada tudi s poimenovanjem virov, ki jih omogoča REST, in s sinhrono komunikacijo
med odjemalcem in strežnikom.
Z nekaterimi odločitvami pri konceptualni primerjavi že vplivamo na tehnološke pristope.
Recimo izbira oblike podatkov in poimenovanje virov sta neločljivo povezana s stilom
REST. SOAP nam sicer omogoča tudi izbiro transportnega protokola, a za nas je uporaben
samo HTTP. Omogoča tudi SMTP, JMS, MQ idr., ki pa je v uporabi v podjetniškem
ekosistemu.
Interoperabilnost v produktu Emit Cloud
25
Tako nas primerjava in potrebe privedejo do odločitve, da za arhitekturni stil izberemo
REST, s katerim bomo lahko najbolje zadovoljili trenutnim zahtevam strežnika, ki jih
obravnavamo v naslednjih poglavjih.
6.2 Implementacija modulov
6.2.1 Zahteve strežnika
Osnovne funkcionalnosti, ki jih mora naš produkt podpreti, so ustvarjanje map, nalaganje
datotek, prenašanje datotek, koš in sprehajanje med mapami. Funkcionalno smo se morali
približati datotečnemu sistemu, ki smo ga razširili z nekaterimi dodatnimi
funkcionalnostmi. Te so bile dodane, ker omogočajo večjo preglednost množice datotek in
s tem povečajo storilnost uporabnika. Nekatere od teh funkcionalnosti so:
− prijava v aplikacijo,
− različni pogledi na datoteke (hierarhičen pogled, samo dokumentne datoteke, slike
ali glasba),
− dodajanje datotek med priljubljene,
− vodenje različic datotek,
− pretočnost multimedijskih vsebin,
− deljenje datotek med uporabniki aplikacije (deljeno z mano, deljeno z drugimi in
javno deljene mape in datoteke),
− javno nalaganje datotek na sistem za neuporabnike aplikacije,
− meta informacije o multimedijskih datotekah.
Podpreti moramo tudi administracijsko upravljanje aplikacije Emit Cloud. Ta mora
podpirati najmanj naslednje funkcionalnosti:
− dodajanje, brisanje in urejanje lokalnih uporabnikov (lokalni, ker jih ne dodajamo
v naročnikovo podatkovno bazo uporabnikov, ampak bazo uporabnikov Emit
Clouda),
− pregled vseh uporabnikov,
− število javno deljenih datotek in njihova poraba pasovne širine,
− dodajanje in urejanje profilov,
− razpošiljanje obvestil o nedosegljivosti sistema,
Interoperabilnost v produktu Emit Cloud
26
− pregled stanja strežnikov (prostor na zunanjih pomnilnikih, poraba procesorskega
časa, zasedenost fizičnega pomnilnika),
− pregled aktivnih aplikacij na posameznem strežniku.
Strežnik bo moral biti pripravljen tudi na razširitve in popravke, zato smo v arhitekturo
REST dodali tudi različice zahtev. Javni oz. avtorizirani zahtevki bodo na voljo na priponi
/api/<verzija>/<vir>. Nekateri zahtevki bodo imeli obe funkcionalnosti. Primer takšnih
klicev je na primer pretočnost multimedijskih vsebin, prenos datotek in nalaganje datotek,
kadar so dotične datoteke ali mape označene kot javne. V vseh treh primerih se dejanska
dosegljivost virov preveri na strežniku, kjer ugotavljamo, ali lahko posamezen vir
izpostavimo javno (vrednotenje poteka na strežniku). Drugi del zahtev je administrativen
in dosegljiv na priponi /admin/<verzija>/<vir>. Ti klici gredo čez drugačen avtorizacijski
postopek, saj mora uporabnik, ki izvaja te klice, pripadati posebni skupini uporabnikov s
profilom »Admin«.
Avtorizacija in avtentikacija sta urejeni s piškotki (angl. cookie), ki jih uporabnik prejme
ob uspešni prijavi v sistem. Za generiranje identifikacijskega niza se uporabljajo številne
vrednosti, med drugim tudi uporabniški IP naslov, trenutni čas, uporabniško ime idr. Vse
vrednosti pa združene tudi šifriramo in tako zagotovimo neponovljivost ustvarjene seje.
Omenili smo sejo, vendar je v našem primeru ne uporabljamo kot klasično sejo SOAP
RPC klicev, kjer bi s sejo vzdrževali stanje aplikacije in omogočali transakcije. S takšnim
pristopom bi izgubili zahtevano avtonomnost REST klicev, kar za potrebe naše aplikacije
ne bi bilo sprejemljivo. Zaradi zahteve po skalabilnosti smo morali predpostaviti, da se n
različnih REST zahtev lahko izvede na n-strežnikih, zato je kakršnakoli relacijska
soodvisnost neprimerna.
Vse zahteve vračajo JSON obliko podatkov. V številnih primerih brskanja smo obdržali
podobno, če ne enako strukturo odgovorov na zahtevke. Poenotili smo na primer celotno
sprehajanje med datotekami in mapami. To smo želeli doseči zaradi ponovne uporabe
programerskih objektov na napravah, ki bodo te zahteve uporabljale.
Lokalizacijo za vire, ki jo potrebujejo, smo omogočili na dva načina:
− vrednost v glavi zahtev Accept-Language,
− vrednost na koncu zahtevka za vir (POST /admin/v1/users.de).
Interoperabilnost v produktu Emit Cloud
27
Tako omogočimo enako funkcionalnost tudi za naprave, ki jezika ne morejo nastaviti prek
glave HTTP zahtevka.
Viri morajo biti določeni unikatno in uporabljati moramo podprte HTTP metode, kot so
GET, PUT, POST, DELETE in HEAD. Omejili smo se le na teh 5, da zagotovimo čim
večjo interoperabilnost.
6.2.2 Implementacija
V tem poglavju se bomo osredotočili na tri najpomembnejše aplikacije znotraj našega
produkta Emit Cloud. To so vrhnja aplikacija ecloud in aplikaciji pod njo cld ter ec.
Aplikacija ecloud poskrbi, da se vse njene podrejene aplikacije in procesi ob zagonu tudi
dejansko zaženejo. Za to poskrbimo v procesu na najvišji ravni, in sicer nadzorniku (angl.
supervisor) ecloud_sup. Medtem pa je vsebinska vloga aplikacije cld najpomembnejša pri
celotni oblačni storitvi. Vsebuje nadzornik cld_fs_supervisor in implementacije strežnikov
cld_fs_maintainer, cld_sync_filedir_proc, cld_sync_userproc, cld_sync_proxyproc ter
druge pomožne module. Vloge naštetih modulov so naslednje:
− proces cld_fs_maintainer ima nadzornika cld_fs_supervisor, skupaj sta odgovorna
za vzdrževanje stanja strežnikov; k temu spada seznam pripadajočih datotek na
strežniku, prostor na zunanjih pomnilnikih, poraba procesorskega časa in
zasedenost fizičnega pomnilnika,
− strežnik cld_sync_userproc predstavlja uporabniški proces, vsak zahtevek ali
opravilo, ki vključuje uporabnika, se izvede prek tega modula,
− strežnik cld_sync_filedir_proc vzdržuje stanje deljenih datotek in map med
uporabniki,
− strežnik cld_sync_proxyproc deluje kot vmesnik med namizno aplikacijo Emit
Cloud in strežnikom cld_sync_userproc.
Komunikacija med temi strežniki se vzpostavi, kadar uporabnik datoteko naloži prek
spletnega brskalnika v mapo, ki je deljena z drugimi uporabniki. Strežniški proces tipa
uporabnik cld_sync_userproc prek našega REST zahtevka prejme informacije o datoteki,
za katero ugotovi, da pripada mapi, ki je deljena med drugimi uporabniki aplikacije Emit
Cloud. Nato obvesti strežniški proces cld_sync_filedir_proc. Ta obvesti vse preostale
strežnike uporabniškega procesa o novi datoteki. Vozlišče, ki bo datoteko prejelo
(predvidevamo, da Emit Cloud teče na več fizičnih ali virtualnih strežnikih), bo imelo
Interoperabilnost v produktu Emit Cloud
28
zagnan svoj proces cld_fs_maintainer, ta bo posodobil stanje strežnika in dodal zapis v
podatkovno bazo o novi datoteki. Vsi uporabniki, ki imajo z aplikacijo Emit Cloud
povezano namizno aplikacijo, pa bodo prek svojega uporabniškega procesa prejeli
obvestilo o novi datoteki, ki jo morajo sinhronizirati. To obvestilo bo prejel strežniški
proces cld_sync_proxyproc in ga posredoval namizni aplikaciji.
Pri tem nismo omenili vseh drugih modulov, ki prav tako sestavljajo aplikacijo cld. Za
nadaljnjo razlago, predvsem ko se bomo osredotočili na delovanje REST vmesnika, so
pomembni moduli cld_sync, cld_sqlite in cld_sqlite_api. Cld_sync je modul, ki bo
največkrat povezovalna točka med aplikacijama ec in cld. Ta modul bo namreč poiskal ali
zagnal pripadajoči uporabniški strežnik cld_sync_userproc in posredoval sinhrone ali
asinhrone zahtevke.
Interoperabilnost v produktu Emit Cloud
29
Slika 7: Potek poslanega zahtevka
Na sliki 7 prikazujemo potek zahtevka od odjemalca do strežniškega odgovora. Podrobno
nas zanima predvsem moder sloj, ki predstavlja REST vmesnik naše aplikacije in ga bomo
opisali v nadaljevanju. Dotaknili pa se bomo tudi, kako potekata pridobivanje in obdelava
podatkov, specifičnih za uporabnika.
Interoperabilnost v produktu Emit Cloud
30
V tem poglavju smo že omenili aplikacijo ec. Aplikacija bo vsebovala implementacijo
našega REST vmesnika. Modula ec_api in ec_admin_api bosta prejemala zahtevke iz
modula ec_mod, ki bo povezoval naš spletni strežnik MochiWeb in aplikacijo Emit Cloud.
Zahtevke na priponi /api/<verzija>/<vir> bo obdelal modul ec_api in zahtevke na priponi
/admin/verzija/vir pa modul ec_admin_api.
Zahtevek, ki bo prišel na spletni strežnik, kjer je postavljen Emit Cloud, bo prišel prek
spletnega strežnika MochiWeb do modula ec_mod, kjer bo zahtevek prevzela funkcija
out/1 (ime/število bo v nadaljevanju opisovalo funkcijo z imenom, ki prejme neko število
parametrov). Ta funkcija je implementirana tako:
1. out(Req) -> 2. ?SETUP, 3. butil:out(Req, fun out/2).
Programska koda 9: Usmerjanje zahtevka
Funkcija out v modulu butil bo iz zahtevka, ki je prvi parameter, izločila pot do želenega
vira in kot drugi parameter prejela funkcijo, ki jo bo poklicala. S pomočjo ujemanja
vzorcev v glavah funkcije tako preusmerimo zahtevke na primerne module, ki bodo vrnili
odgovore.
1. out("sync/"++Rem, Req) -> 2. cld_util:setup(), 3. cld_sync:out(Rem, Req); 4. out("script/sync/"++Rem, Req) -> 5. cld_util:setup(), 6. cld_sync:out(Rem, Req); 7. out("fs/"++Rem, Req) -> 8. cld_util:setup(), 9. cld_fs:out(Rem, Req); 10. out("api/"++Path, Req) -> 11. UserSession = ec_session:get_session(Req), 12. ec_api:out(Path, Req, UserSession); 13. out("admin/"++Path, Req) -> 14. UserSession = ec_session:get_session(Req), 15. ec_admin_api:out(Path, Req, UserSession);
Programska koda 10: Preusmerjanje zahtevka
Zadnji dve funkciji sta za nas še posebej pomembni, ti namreč preusmerita zahtevke na
modula (ec_api in ec_admin_api) za REST vmesnik, kjer jih bo obravnavala spodnja
funkcija:
Interoperabilnost v produktu Emit Cloud
31
1. out("v"++Rem, Req, UserSession) -> 2. cld_sync:setup(), 3. [Version, _Namespace|Other] = string:tokens(Rem, "/"), 4. case {length(Other), list_to_atom(hd(Other))} of 5. {1,Function} -> 6. apply(?MODULE, Function,[Req, UserSession, Version]); 7. {_,Function} -> 8. apply(?MODULE, Function,[Req,tl(Other), UserSession, Version]) 9. end.
Programska koda 11: Vstopna funkcija v modulu
V predpisu funkcije izkoristimo moč ujemanja vzorcev programskega jezika Erlang. Na
vhodu funkcije dobimo seznam, ki predstavlja pot do vira, na primer v1/user/auth. V
spremenljivko Rem shranimo ostanek seznama 1/user/auth. V vrstici, ki sledi, moramo v
asociativno polje trenutnega procesa shraniti nekatere informacije o privzetih strukturah, ki
so nam v pomoč pri predstavitvi informacij o datotekah in mapah. Te strukture bomo
posebej obravnavali v modulu cld_sqlite in cld_sqlite_api. V vrstici 3 nad preostankom
seznama pokličemo funkcijo modula string, ki bo seznam razbila na člene glede na
pojavitev znaka /. Tako v spremenljivo Version shranimo vrednost 1, v spremenljivko
_Namespace vrednost user ter vse drugo v spremenljivo Other. V vrstici 4 nas zanima
dolžina preostalega seznama, ki je shranjen v Other. V našem primeru bo dolžina seznama
1, zato se bo izvedla vrstica 5.
Erlangova interna funkcija apply lahko prejme dva ali tri parametre. V obeh primerih je
prvi parameter ime modula, naslednji pa ime funkcije, oba v tipu atom. Tretji opcijski
parameter predstavlja argumente za funkcijo, ki je podana kot drugi parameter. V našem
primeru bomo torej poklicali funkcijo auth v modulu, v katerem se trenutno nahajamo
(ec_api) s parametri:
− zahtevek v strukturi mochiweb_request,
− avtentifikacijska seja,
− verzija API klica.
Na primeru smo torej pokazali sled, ki se bo zgodila za vsak klic na priponi
/api/<verzija>/<vir>. Nekoliko drugačna je sled, kadar nas bo zanimala administracija na
priponi /admin/<verzija>/<vir>, kar bomo obravnavali v poglavju 6.2.4.
6.2.3 Primer implementacije REST zahtevka za pripravo nalaganja datotek
Nalaganje datotek je razdeljeno v dva koraka. V prvem koraku preverimo, ali je nalaganje
glede na parametre možno, in v drugem koraku sledi dejansko pošiljanje blokov datoteke.
Interoperabilnost v produktu Emit Cloud
32
Pripona prvega koraka je /storage/file/upload s pričakovano HTTP metodo POST. V telesu sporočila pričakujemo JSON: 1. { 2. "userId": <identifikator lastnika uporabnika za javno nalaganje datotek>, 3. "fileSize": <celo število>, 4. "fileName": <niz>, 5. "parentId": <identifikator starša | niz>, 6. "path": <opcijska vmesna pot> 7. }
Programska koda 12: Pričakovan JSON v zahtevku
Parametri nalaganja nam omogočajo, da preverimo, ali ima uporabnik dovolj prostora, da
datoteko naloži (fileSize), in pod katerim imenom jo želi shraniti (fileName) ter v katero
mapo želi datoteko odložiti (parametra parentId in path). Parameter userId uporabljamo
zgolj pri nalaganju datotek v javno dostopne mape.
Nekateri odjemalci podpirajo uporabno funkcijo nalaganja celotnih map. Problem
nalaganja map pa je, da drevo vmesnih poti do datotek včasih ne obstaja in jih je treba
ustvariti. Validacija nalaganja datotek je naslednja:
1. case FolderPath of 2. <<"">> -> 3. case ParentId of 4. <<"">> -> 5. ?RESP_BADREQ; 6. _ -> 7. ok = ec_cloudapi:check_for_upload(UserId, SessionKey,
FileSize, FileName, ParentId), 8. Proxy = upload_proxy(Req,UserId), 9. ?JSON_RESP_OK([{url, iolist_to_binary([Proxy,
"/proxy/uploadfile/", butil:tobin(UserId), "/", butil:encode_percent(FileName), "/", butil:tobin(ParentId)])}])
10. end; 11. _ -> 12. ?USER_LOG("UserId ~p is uploading to folder while we create
them ~p to parent ~p ParentId",[UserId,FolderPath,ParentId]), 13. %checking if upload is possible, creating any intermediate
folders 14. NewParentId = ec_cloudapi:check_for_upload(UserId, SessionKey,
FileSize, FileName, ParentId,lists:filter(fun(X)-> X /= <<>> end, binary:split(FolderPath,<<"/">>, [global]))),
15. Proxy = upload_proxy(Req,UserId), 16. ?JSON_RESP_OK([{url,iolist_to_binary([Proxy,
"/proxy/uploadfile/",butil:tobin(UserId), "/",butil:encode_percent(FileName), "/", butil:tobin(NewParentId)])}])
17. end.
Programska koda 13: Validacija nalaganja datotek
Če parameter path iz HTTP zahtevka (v programski kodi je to spremenljivka FolderPath)
ni nastavljen, pomeni, da odjemalec od nas ne želi, da ustvarimo vmesne mape, zato gre
izvajanje programske kode v prvi blok oziroma drugi blok, kadar je nastavljen.
Interoperabilnost v produktu Emit Cloud
33
Zahtevek se v obeh blokih nadaljuje v modulu ec_cloudapi, kjer poiščemo uporabnikov
gen_server (proces) in preverimo, ali ima uporabnik dovolj prostora za nalaganje datoteke,
ali mapa, v katero nalagamo datoteko, obstaja in ali datoteka z istim imenom v tej mapi že
obstaja ter ali je uporabnik avtentificiran. Spodaj predsavimo del funkcije, ki ustvari
sporočilo, katerega pošljemo uporabniškemu procesu:
1. Msg = case FolderPath of 2. undefined -> 3. {can_upload, ParentId, butil:toint(FileSize), FileName}; 4. [_|_] = FolderPath -> 5. {can_upload, ParentId, butil:toint(FileSize), FileName,
FolderPath} 6. end, 7. case gen_server:call(getuserproc(Uid), {checksession,Skey,Msg}, 20000) of
Programska koda 14: Ustvarjanje sporočila
Funkcija getuserproc sprejme argument, ki predstavlja identifikator uporabnika. Njena
implementacija je:
1. % Returns PID of clientproc process. 2. % Crashes if called on server that is not in configured clientproc group. 3. getuserproc(P) when is_pid(P) -> 4. P; 5. getuserproc(Clientid1) -> 6. Clientid = butil:toint(Clientid1), 7. case global:whereis_name(Clientid) of 8. undefined -> 9. case get_userinfo(Clientid) of 10. undefined -> 11. ok; 12. {ok, ExInfo} -> 13. % Crash if distgroup of node not the assigned group of
user 14. true = cld_fs_conf:distgroup() ==
butil:toatom(butil:ds_val(grp, ExInfo)) 15. end, 16. case cld_sync_userproc:start(Clientid) of 17. {ok, Pid} -> 18. ok; 19. _StartErr -> 20. ?CLD_ERR_LOG("Unable to start user ~p", [_StartErr]), 21. case global:whereis_name(Clientid) of 22. undefined = Pid -> 23. exit({unable_to_get_userproc, Clientid}); 24. Pid -> 25. ok 26. end 27. end; 28. Pid -> 29. ok 30. end, 31. Pid.
Programska koda 15: Pridobivanje uporabniškega procesa
Njen namen je, da v globalnem registru procesov poišče proces, ki pripada uporabniku s
podanim identifikatorjem, oziroma kadar ta proces ne obstaja (torej ga ne najde), ga
Interoperabilnost v produktu Emit Cloud
34
poskuša zagnati. Funkcija vrne identifikator procesa, ki mu lahko pošljemo sporočilo s
klicem funkcije call v modulu gen_server. Funkcija call je sinhrona.
Vsa možna sporočila, ki jih pošlje uporabniški proces, obdelamo v spodnjem (programska
koda 17) case izrazu. Za pozitivne odgovore vrnemo klicateljskemu procesu atom ok, ki
nato nadaljuje v vrstici 8 (ali 14) programske kode 13, kjer ustvarimo nov enotni
identifikator vira, ki bo služil za nalaganje datoteke. Ta identifikator vrnemo kot JSON
odgovor prvega zahtevka v telesu sporočila s statusno kodo 200.
1. { 2. "uri": "<naslov do strežnika>/proxy/uploadfile/<uporabniški
identifikator>/<ime datoteke>/<identifikator starša>" 3. }
Programska koda 16: JSON odgovor zahtevka
Kadar kateri iz med pogojev ni izpolnjen, na zahtevek odgovorimo s HTTP status kodo
400 oziroma 403, kadar uporabnik ni avtenticiran.
1. case gen_server:call(getuserproc(Uid), {checksession,Skey,Msg}, 20000) of 2. local -> 3. ok; 4. ok -> 5. ok; 6. {ok,_Fid} -> 7. ?CLD_DBG_LOG("Uploadfile took name from existing file ~p", [_Fid]), 8. ok; 9. {return_parent,Fid} -> 10. ?CLD_DBG_LOG("Uploadfile took name from existing file ~p", [Fid]), 11. Fid; 12. {sessionbad} -> 13. throw(#pgr{status = 403}); 14. ErrCan when is_atom(ErrCan) -> 15. ?CLD_ERR_LOG("Can upload error ~p",[ErrCan]), 16. throw(#pgr{status = 400, content = butil:tolist(ErrCan)}); 17. _Err -> 18. ?CLD_ERR_LOG("Can upload error ~p",[_Err]), 19. throw(#pgr{status = 503}) 20. end
Programska koda 17: Obravnavanje odgovorov
6.2.4 Primer implementacije REST zahtevkov za upravljanje uporabnikov
Programska koda 10 nam v vrstici 13 preusmeri zahtevek iz modula ec_mod v modul
ec_admin_api in od tam nadaljuje v funkciji:
Interoperabilnost v produktu Emit Cloud
35
1. out("v"++Rem, Req, UserSession)-> 2. cld_sync:setup(), 3. Handle = fun()-> 4. case string:tokens(Rem,"/") of 5. [Version, Other] -> 6. Function =
list_to_atom(check_if_function_has_language(Other)), 7. apply(?MODULE, Function, [Req, UserSession,
Version]); 8. [Version, Function|OtherParams] -> 9. apply(?MODULE,
list_to_atom(check_if_function_has_language(Function)), [Req, OtherParams, UserSession, Version])
10. end 11. end, 12. IP = butil:userip(Req), 13. LegitIPs = cld_global_conf:admin_interface_access(), 14. case {lists:member(IP,LegitIPs),LegitIPs} of 15. {true,_} -> 16. Handle(); 17. {false,[]}-> 18. Handle(); 19. _ -> 20. ?RESP_NOSESSION 21. end. 22. 23. check_if_function_has_language(FunctionName)-> 24. case string:tokens(FunctionName,".") of 25. [FunctionName0, Language] -> 26. erlang:put("AcceptLanguage", Language), 27. FunctionName0; 28. _ -> 29. FunctionName 30. end.
Programska koda 18: Vstopna funkcija v modul
Princip delovanja je podoben, kot je v vstopni funkciji v modul ec_api (programska koda
11), vendar se tukaj spoznamo še z anonimnimi funkcijami (spremenljivka Handle), ki jih
kličemo v primerih, kadar bo naš IP naslov iz dovoljenega območja. V vseh drugih
primerih bomo na zahtevek odgovorili s HTTP status kodo 403.
Po priporočilih iz literature [12] moramo za lokalizirane storitve nuditi dva načina vračanja
lokaliziranih virov. Prvi način je dostopanje do lokaliziranih virov tako, da lokalizacijo
nakažemo z okrajšavo jezika, v katerem ga želimo. Tako bi na primer /admin/verzija/vir.de
pomenilo, da želimo vrnjen vir v nemškem jeziku. Drugi način, ki je pogostejši, pa
sprejmemo prek vrednosti v glavi zahtevka Accept-Language. To obravnavamo v funkciji
check_if_function_has_language v vrstici 23.
Uporabnike želimo dodajati, brisati, urejati in izpisati v seznamu, torej moramo izpostaviti
temu primerne enotne identifikatorje vira in metode.
Interoperabilnost v produktu Emit Cloud
36
Pripona Metoda Opis
/admin/v1/users POST Ustvarjanjenovegauporabnika.
/admin/v1/users/<123> PUT Urejanje obstoječega
uporabnika.
/admin/v1/users/<123> DELETE Brisanjeobstoječegauporabnika.
/admin/v1/users GET Zahtevek za izpis uporabnikov v
seznamuvrneJSONseznam.
Tabela 5: Vir za sklop uporabniki
Vsak zahtevek, ki ne bo vseboval pričakovanih parametrov, bo vrnil HTTP statusno kodo
400 in v telesu sporočila lokaliziran JSON opis napake:
1. { 2. "error":"<lokaliziran opis napake>" 3. }
Programska koda 19: Lokalizirano sporočilo
Spodnja programska koda, ki obravnava ustvarjanje novega uporabnika, najprej iz telesa
sporočila, ki mora biti oblike, kot je razvidna iz programske kode 21, izvleče vse potrebne
informacije in nato v vrstici 6 potrdi, ali sta obe vneseni gesli enaki. Če nista, vrnemo
lokalizirano sporočilo (programska koda 19) in HTTP statusno kodo 400.
Interoperabilnost v produktu Emit Cloud
37
1. 'POST'-> 2. AcceptLanguage = get_language(Req), 3. JsonBody = json_from_body(Req), 4. [Username, Password1, Password2, Email, ProfileId, Groups] =
butil:ds_vals([<<"username">>, <<"password1">>, <<"password2">>, 5. <<"email">>, <<"profile">>, <<"groups">>], JsonBody,
[<<"">>, <<"">>, <<"">>, [], -1, []]), 6. Password = case Password1 == Password2 of 7. true -> 8. Password1; 9. false -> 10.
throw(?JSON_RESP_BADREQ(bjson:encode([ec_i18n:value(AcceptLanguage,"api:password_validation_match")])))
11. end, 12. case ec_cloudapi:create_user(UserId, SessionKey, Username,
Password, Email, ProfileId, Groups) of 13. {Id, ok} -> 14. ?VLINFO(admin,"Admin created user with username
~p",[Username]), 15. ?JSON_RESP_OK({<<"id">>,butil:tobin(Id)}); 16. {error,email}-> 17.
Req:respond({400,[],bjson:encode([{error,ec_i18n:value(AcceptLanguage,"api:email_validation")}])});
18. {error,password}-> 19.
Req:respond({400,[],bjson:encode([{error,ec_i18n:value(AcceptLanguage,"api:password_validation")}])});
20. %#pgr{status=400,content = "bjson:encode(Data)"}; 21.
%?JSON_RESP_BADREQ(bjson:encode({error,ec_i18n:value(AcceptLanguage,"api.password_validation")}));
22. {error,user_limit_reached}-> 23.
?JSON_RESP_BADREQ(bjson:encode([ec_i18n:value(AcceptLanguage,"api:user_limit_reached")]));
24. {error,exists}-> 25.
?JSON_RESP_BADREQ(bjson:encode([ec_i18n:value(AcceptLanguage,"api:exists")]));
26. badsession-> 27. ?RESP_NOSESSION 28. end;
Programska koda 20: Ustvarjanje uporabnika
Če je validacija gesel uspešna, sledi poskus ustvarjanja uporabnika v vrstici 12, kjer
pokličemo funkcijo create_user v modulu ec_cloudapi. Vsak možen izhod iz te funkcije
obravnavamo posebej in vračamo primerne HTTP statusne kode in sporočila.
1. { 2. "username": <uporabnško ime>, 3. "password1": <geslo>, 4. "password2": <geslo>, 5. "email": <elektronski naslov>, 6. "profile": <identifikator profila> 7. }
Programska koda 21: Telo sporočila
Interoperabilnost v produktu Emit Cloud
38
6.3 Testiranje aplikacije Emit Cloud z Robot Framework
Ogrodje smo razširili s knjižnjicama robotframework-requests in robotframework-
httplibrary, ki nam omogočata pošiljanje zahtevkov in njihovo obdelavo. Prav tako smo
ogrodju dodali štiri svoje metode, ki smo jih zapisali v datoteko Util.py v programskem
jeziku Python. Te metode so:
− prenos javno dostopnih datotek in zapis na trdi disk (download_file_pub ter
download_file_pub_error_handler),
− prenos datotek in zapis na trdi disk (download_file),
− razširjanje datotek na disk (extract_zip).
Sprejemljivostni testi si sledijo zaporedno in morajo na koncu izvajanja počistiti za sabo
(testne uporabnike, deljene datoteke in mape, prenesene datoteke). Sistem mora namreč po
testiranju ostati vsaj navidezno nedotaknjen.
Robot Framework teste poženemo s skripto run.sh z argumenti:
− domena (naslov, na katerem je dostopna instanca strežnika Emit Cloud),
− administrativno uporabniško ime,
− administrativno geslo,
− ime korenske mape.
Skripta vsebuje naslednjo programsko kodo:
1. #!/bin/bash 2. # PYBOT_BIN = $(dirname $(which pybot)) 3. # $(if $(PYBOT_BIN),,$(warning "Warning: No Robot Framework - pybot - found
in your path, this will probably not work")) 4. DOMAIN=$1 5. ADMIN_USERNAME="\""$2"\"" 6. ADMIN_PASSWORD="\""$3"\"" 7. ROOT_NAME="\""$3"\"" 8. rm -rf out/ 9. pybot --variable domain:$DOMAIN --variable AdminUsername:$ADMIN_USERNAME --
variable AdminPassword:$ADMIN_PASSWORD --variable RootName:$ROOT_NAME --pythonpath libs/ --critical critical -d out/ .
10. exit 0
Programska koda 22: Robot Framework zagonska skripta
V vrsticah 2 in 3 preverimo, ali je programsko orodje Robot Framework nameščeno. Nato
v vrsticah od 4 do 7 argumente, s katerimi smo skripto zagnali, zapišemo v pripadajoče
Interoperabilnost v produktu Emit Cloud
39
spremenljivke. V vrstici 8 pobrišemo vsa starejša poročila, ki so nastala s prejšnjimi
zagoni. V vrstici 9 prek skripte pybot izvedemo napisane sprejemljivostne teste. Zastavica -
-variable določa začetek naštevanja parametrov iz vrstic od štiri do sedem. Zastavica --
pythonpath določa, kje se nahajajo knjižnice, in z zastavico –d, kam naj se shranijo
poročila. Zastavica –critical nam omogoča nastavljanje ravni kritičnosti izvajanja testov.
Začeli bomo s sprejemljivostnimi testi za administracijsko upravljanje, saj bomo v
postopku testiranja morali ustvariti uporabnike in njihove profile, kar pa lahko naredimo
samo z administracijskim računom. Spodnji odsek kode prikazuje test prijave z
administracijskim računom, ki ga podamo kot parameter, kar je razvidno iz prejšnjega
odstavka.
1. /api/v1/user/auth (ADMIN AUTH) 2. [Tags] /api/* critical 3. ${resp}= Post Response /api/v1/user/auth {"username":
${AdminUsername},"password": ${AdminPassword},"sesssionCookie":true, "deviceName": "adminDevice", "deviceId": "adminDeviceId"}
4. Should Be Equal As Strings ${resp.status_code} 200 5. Set Global Variable ${AdminCookie} ${resp.headers['Set-Cookie']} 6. ${jsondata}= To JSON ${resp.content} 7. Dictionary Should Contain Key ${jsondata} userId 8. Dictionary Should Contain Key ${jsondata} cookie
Programska koda 23: Prijava z administracijskim računom v orodju Robot Framework
Strukturo posameznega testa bomo predstavili na zgornjem primeru. V vrstici 1 definiramo
ime testa (v našem primeru je ime definirano s potjo do vira, ki ga bomo preizkušali).
Robot Framework omogoča tudi dodajanje dokumentacije za posamezen test z določitvijo
[Documentation], ki mu sledi vsebina.
Nadaljujemo v drugi vrstici, kjer umestimo test pod oznako /api/* in ga opredelimo kot
kritičnega s ključno besedo critical.
Z oznakami lahko klasificiramo teste, ki nam omogočajo [5]:
− vidne oznake v poročilih in dnevnikih in dodajanje meta podatkov testom,
− statistično grupiranje,
− selektivno izvajanje testov glede na oznako,
− razvrščanje testov.
V tretji vrstici sledi klic višjenivojske ključne besede Post Response, ki prejme kot
argument naslov vira, kamor želimo naslednji argument poslati. Podrobneje je definirana
takole:
Interoperabilnost v produktu Emit Cloud
40
1. Post Response [Arguments] ${path} ${content} 2. Create Session ec_domain ${proto}${domain} 3. ${resp}= Post ec_domain ${path} ${content} 4. Log ${resp} 5. [Return] ${resp}
Programska koda 24: Funkcija Post Response
V prvi vrstici programske kode 24 definiramo ime ključne besede (tj. Post Response), ki ji
sledijo določitev [Arguments] in dva argumenta ${path} ter ${content}. Nato v drugi
vrstici z nižjenivojsko ključno besedo Create Session ustvarimo sejo HTTP zahtevka. Nato
v vrstici 3 izvedemo HTTP zahtevek POST, ki bo na strežnik poslal vrednost iz
spremenljivke ${content}. Odgovor strežnika zapišemo v dnevnik s ključno besedo Log in
zaključimo z določitvijo [Return], s katero določimo, katero vrednost želimo vrniti na višjo
raven, iz katere je bil klic tudi izveden.
Nadaljujemo s primerom programske kode 23 v vrstici štiri, kjer predstavimo nižjenivojsko
ključno besedo Should Be Equal As Strings, ki izvede primerjavo med statusno kodo
zahtevka in našim argumentom. Nato s Set Global Variable nastavimo globalno
spremenljivko ${AdminCookie} vrednost, ki se nahaja v glavi zahtevka pod imenom Set-
Cookie, saj bomo za vsako testiranje administracijskih funkcionalnosti potrebovali ravno to
vrednost. Nato v vrstici šest pretvorimo vsebino odgovora v format JSON. V vrsticah
sedem in osem nato s ključno besedo Dictionary Should Contain Key preverimo prisotnost
dveh ključev (userId ter cookie).
6.3.1 Primer implementacije testa za filtriranje glasbenih datotek z REST zahtevkom
Vsak REST zahtevek, ki smo ga implementirali v produktu Emit Cloud, ima
implementiran tudi funkcionalni test v orodju Robot Framework. Testi nam olajšajo
nadaljnje delo, saj tako hitreje ugotovimo, ali smo pri posodabljanju programske kode
naredili napako.
Ime testa je zapisan v vrstici 1 programske kode 25. Test v naslednji vrstici označimo z
oznako /api/* in dodamo zastavico critical, kar pomeni, da je test za nas kritičnega
pomena. Če bo Robot Framework med izvajanjem tega testa naletel na napako, bo ustavil
izvajanje preostalih testov.
Interoperabilnost v produktu Emit Cloud
41
1. /api/v1/storage/folder/music?... (GET FOLDER BY CONTENT TYPE - MUSIC) 2. [Tags] /api/* critical 3. ${resp}= Get Response Cookie No Body
/api/v1/storage/folder/music?skip=0&limit=100&order=asc&sortby=name ${CreatedUserCookie}
4. Should Be Equal As Strings ${resp.status_code} 200 5. ${jsondata}= To JSON ${resp.content} 6. Dictionary Should Contain Key ${jsondata} hasMore 7. Dictionary Should Contain Key ${jsondata} folderinfo 8. Dictionary Should Contain Key ${jsondata} groups 9. Dictionary Should Contain Key ${jsondata['groups'][0]} meta 10. Dictionary Should Contain Key ${jsondata['groups'][0]} files 11. Dictionary Should Contain Key ${jsondata['groups'][0]} dirs 12. ${number_of_files}= Get Length ${jsondata['groups'][0]['files']} 13. Should Be Equal As Strings 2 ${number_of_files} 14. Should Be Empty ${jsondata['groups'][0]['dirs']} 15. ${json_meta_keys}= Get Dictionary Keys ${jsondata['groups'][0]['meta']} 16. Sort List ${FileItems} 17. Sort List ${json_meta_keys} 18. Sort List ${DirItems} 19. Lists Should Be Equal ${DirItems} ${json_meta_keys} 20. :FOR ${item} IN @{jsondata['groups'][0]['files']} 21. \ ${json_file_keys}= Get Dictionary Keys ${item} 22. \ Sort List ${json_file_keys} 23. \ Append To List ${suite_all_files} ${item['id']} 24. \ Lists Should Be Equal ${FileItems} ${json_file_keys}
Programska koda 25: Implementacija testa za filtriranje glasbenih datotek
V nadaljevanju izvedemo GET zahtevek na enotni identifikator vira
/api/v1/storage/folder/music z argumenti, prikazanimi v tabeli 6.
Ime Vrednost
skip 0
limit 100
order asc
sortby name
Tabela 6: Argumenti zahtevka za filtriranje glasbenih datotek
Ti argumenti krmilijo strežniški odziv in uravnavajo začetek iskanja glasbenih datotek,
število datotek, ki naj jih strežnik vrne, in kako naj bodo datoteke urejene (padajoče,
naraščajoče in po abecednem vrstem redu, katerega iz med polj).
Višjenivojske ključne besede Get Response Cookie No Body smo definirali v ločenem
odseku datoteke (programska koda 26). Ta odsek se imenuje ključne besede in je namenjen
definiranju lastnih višjenivojskih ključnih besed.
Interoperabilnost v produktu Emit Cloud
42
1. Get Response Cookie No Body [Arguments] ${path} ${cookie} 2. Create Session ec_domain ${proto}${domain} 3. ${headers} Create Dictionary Cookie ${cookie} 4. ${resp}= RequestsLibrary.Get ec_domain ${path} headers=${headers} 5. Log ${resp} 6. [Return] ${resp}
Programska koda 26: Lastna višjenivojska ključna beseda
V vrstici 1 programske kode 26 definiramo ime in dva argumenta, ki ju ključna beseda
prejme. Ta argumenta sta pot in piškotek. Nato definiramo spletno sejo, nastavimo
vrednosti v glavo zahtevka in izvršimo zahtevek. Vrnjen rezultat nato zabeležimo v
dnevnik in vrnemo rezultat.
Tako smo s kombinacijo višjenivojskih in nižjenivojskih ključnih besed ustvarili svojo
višjenivojsko ključno besedo, ki jo uporabljamo v številnih testih.
Nadaljujemo v programski kodi 25, kjer v vrstici 4 pričakujemo uspešno statusno kodo
strežnika (tj. 200), in nato uporabimo višjenivojsko ključno besedo To Json, ki deserializira
JSON odgovor strežnika v JSON objekt, ki ga razume tudi Robot Framework. V vrsticah
od 6 do 11 preverimo, ali vrnjen JSON vsebuje potrebne korenske elemente z višjenivojsko
ključno besedo Dictionary Should Contain Key. Ker vemo, da pričakujemo zgolj 2 datoteki
in 0 map, to tudi preverimo v vrsticah 12, 13 ter 14.
Zaključimo tako, da preverimo polje meta, ta ima informacije o mapi, ki glasbene datoteke
vsebuje. Nato se še v vrstici 21 z zanko sprehodimo čez vse vrnjene glasbene datoteke in
preverimo, ali imajo enako obliko kot globalno definiran seznam FileItems, viden v
programski kodi 27.
1. @{FileItems}= owner shared created type user rev sha crch crc size fav mtime tdiff pub tdel name parent id scanned
Programska koda 27: Seznam obveznih polj za datoteko
6.3.2 Izvedba sprejemljivostnih testov s tehnologijo Robot Framework
K implementaciji arhitekture REST spadajo tudi sprejemljivostni testi, zato smo
podpoglavje magistrske naloge namenili tudi testiranju in izvajanju testiranja, saj je
smiselno rezultate testiranj in količino testov predstaviti tudi grafično. Robot Framework
zapiše grafični prikaz rezultatov v datoteko results.html. Posnetek te datoteke lahko vidimo
na sliki 8. Razberemo, da je bil skupno opravljen 101 test. Vsi testi so bili označeni kot
Interoperabilnost v produktu Emit Cloud
43
kritični testi. Od 101 kritičnega testa jih 92 pripada splošnim zahtevam in so označeni z
/api/* in 9, ki pripadajo znački /admin/*.
Slika 8: Testi, izvedeni z orodjem Robot Framework
Interoperabilnost v produktu Emit Cloud
44
7 REZULTATI
Rezultat našega dela je REST API za spletno aplikacijo Emit Cloud. Trenutni odjemalci, ki
uporabljajo naš REST API, so mobilne aplikacije za naprave Android, iOS in spletni
brskalniki.
Slika 9: Aplikacija Emit Cloud za naprave Android s pogledom na datotečni sistem
Rezultat izdelave protokola je najbolje prikazati tako, da pokažemo rezultat neke naprave
ali sistema, ki protokol uporablja. Zato na sliki 9 prikazujemo pogled na datotečni sistem
za naprave Android in na sliki 10 predvajanje glasbe, ki je naložena v oblaku Emit Cloud
in do nje dostopamo z napravo iOS. Omogočamo tudi pretočnost video vsebin, katerih
kakovost se prilagaja glede na uporabnikovo pasovno širino.
Interoperabilnost v produktu Emit Cloud
45
Slika 10: Aplikacija Emit Cloud za naprave iOS s pogledom na predvajanje glasbe
Sliki 11 in 12 prikazujeta pogled s spletnega brskalnika. Slika 11 prikazuje prijavo v sistem
in slika 12 pregled vseh slik, ki so v oblaku združene v mape.
Interoperabilnost v produktu Emit Cloud
46
Slika 11: Pogled na prijavo v aplikacijo Emit Cloud s spletnega brskalnika
Slika 12: Pogled na vse slike v aplikaciji Emit Cloud s spletnega brskalnika
Interoperabilnost v produktu Emit Cloud
47
8 DISKUSIJA
V magistrski nalogi smo predstavili potek razvoja spletne aplikacije in njenega REST
vmesnika, ki bo služil kot vhodna in izhodna točka za odjemalce najrazličnejših tipov, ki
podpirajo HTTP. Začeli smo s pregledom trenutno aktualnih standardov SOAP in REST. V
literaturi, ki nam je bila na voljo, smo ju spoznali in primerjali, nato razdelali še naše
zahteve in izbrali REST kot primeren arhitekturni stil.
Izkazalo se je, da smo izbrali dober in robusten pristop, ki je omogočil enostavno
implementacijo za odjemalce Android, iOS in spletne brskalnike. Iz rezultatov, ki smo jih
podrobneje predstavili v poglavju 7, sklepamo, da razvijanje nadaljnjih odjemalcev (npr.
Windows Phone) ne bo problematično. Ker se zavedamo dinamičnosti programske
opreme, smo predvideli tudi omejitve in vgradili mehanizme (verzioniranje), ki nam
omogočajo, da uvedemo spremembe ali nadgradnje.
Omeniti moramo popularne oblačne storitve, kot so Dropbox, Google Drive in Onedrive.
Ti se od produkta Emit Cloud razlikujejo v tem, da z njimi ni mogoče uporabljati lastne
strojne opreme. Podatki so zmeraj na njihovih strežnikih in zato tudi ne vemo, kaj se z
njimi dogaja in kako so spravljeni, kar večkrat predstavlja problem predvsem podjetjem.
Emit Cloud pa niso le arhitektura REST in sprejemljivostni testi, ki smo jih omenjali v
magistrski nalogi. Jedro sistema ima številne funkcionalnosti, kot so npr. deduplikacija,
replikacija in enkripcija podatkov, izredno skalabilna podatkovna baza ActorDB, ki smo jo
opisali v poglavju 3.1, skalabilnost sistema, visoka razpoložljivost, prilagojen zunanji
videz idr. V tabeli 7 primerjamo nekatere funkcionalnosti med opisano rešitvijo Owncloud
v poglavju 2.1 ter našim produktom Emit Cloud.
Interoperabilnost v produktu Emit Cloud
48
Funkcionalnost/produkt EmitCloud Owncloud
Lokalnapostavitev Da Da
Naprednaenkripcijadatotek Da Da
Predvajanje multimedijskih
vsebin
Da Da, vendar z zunanjimi
vtičniki.
Prilagojenzunanjividez Da Ne
Integracija protivirusne
zaščite
Da Da
Skalabilnost in
razpoložljivost
Da Da,vendarskombinacijoproduktovHAProxy1,GlusterFS2terMySQL Galera3
REST Da Ne
WebDAV Da Da
Tabela 7: Primerjava funkcionalnosti
Bistvena razlika med našim sistemom in sistemom, ki ga ponuja Owncloud je v
skalabilnosti in razpoložljivosti. Owncloud ju ne omogoča brez dodatne programske
opreme, s katero bi povečali kompleksnost in nepredvidljivost sistema.
Tako rezultati kot tudi razviden postopek implementacije potrjujejo zastavljeno tezo v
uvodu magistrske naloge. Menimo, da je naš produkt primerljiv z drugimi produkti na trgu,
saj ima nekatere kritične funkcionalnosti, ki jih drugi nimajo. Z njimi omogočamo
1 HAProxy je namenjen porazdelitvi obremenitve. Več na http://www.haproxy.org/.
2 Distribuirana hramba podatkov. Več na https://www.gluster.org/.
3 Replikacija podatkov za MySql podatkovno bazo. Več na http://galeracluster.com/.
Interoperabilnost v produktu Emit Cloud
49
brezhibno integracijo v večje ali manjše podjetniške ekosisteme, kjer želimo produkt, ki
deluje brezhibno na večjem številu strežnikov ali za osebno uporabo na samo enem.
Interoperabilnost v produktu Emit Cloud
50
9 VIRI
1. ownCloud. ownCloud Architecture Overview. ownCloud, Inc. [Elektronski] 8 2013.
[Navedeno: 7. 10. 2015.] https://owncloud.com/wp-content/uploads/2013/08/ownCloud-
Architecture-Whitepaper-3.3.pdf.
2. WebDAV: A network protocol for remote collaborative authoring on the Web.
Whitehead, Emmet James in Goland, Yaron Y. Copenhagen : Kluwer Academic
Publishers, 1999. European Computer Supported Cooperative Work. str. 291–311. 0-7923-
5947.
3. ActorDB - porazdeljena SQL baza. Murko, Ino in Spagnolo, Gregor. Maribor :
Konferenca OTS 2015, 2015.
4. Biokoda d.o.o. ActorDB. ActorDB Distributed SQL database with linear scalability.
[Elektronski] Biokoda d.o.o. [Navedeno: 10. 1. 2016.] http://www.actordb.com/docs-
howitworks.html#overview.
5. Robot Framework. [Elektronski] [Navedeno: 13. 5. 2015.]
http://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html.
6. Laukkanen, Pekka. CiteSeerX. Data-Driven and Keyword-Driven Test Automation
Frameworks. [Elektronski] 24. 2. 2006. [Navedeno: 24. 3. 2015.] http://eliga.fi/Thesis-
Pekka-Laukkanen.pdf.
7. Armstrong, Joe. Programming Erlang - Software for a Concurrent World. Dallas,
Texas : The Pragmatic Bookshelf, 2007. ISBN: 978-1-934356-00-5.
8. Jurečko, Sergej. Zajem in pretok videa po internetu : diplomska naloga univerzitetnega
študijskega programa. Digitalna knjižnica Univerze v Mariboru. [Elektronski] 9 2008.
[Navedeno: 13. 12. 2014.] https://dk.um.si/IzpisGradiva.php?id=9232.
9. Principled Design of the Modern Web Architecture. Fielding, Roy T. in Taylor, Richard
N. 2, New York, NY, USA : ACM Transactions on Internet Technology, May 2002, Izv. 2.
10. Wilde, Erik in Pautasso, Cesare. REST: From Research to Practice. London : Springer.
978-1-4419-8303-9.
Interoperabilnost v produktu Emit Cloud
51
11. Pautasso, Cesare, Zimmermann, Olaf in Leyman, Frank. RESTful Web Services vs.
“Big” Web Services: Making the Right Architectural Decision. New York : In WWW ’08:
Proceeding of the 17th international conference on World Wide Web, 2008. str. 805–814.
12. Cesarini, Francesco in Thompson, Simon. Erlang Programming - A Concurrent
Approach to Software Development. s.l. : O'Reilly Media, 2009. ISBN: 978-0-596-51818-
9.
13. Richardson, Leonard in Ruby, Sam. RESTful Web Services. s.l. : O'Reilly Media, 2007.
ISBN: 978-0-596-52926-0.
14. Kralj, Rok in Krajnc, Marjetka. Paralelni in distribuirani algoritmi v numerični analizi.
Ljubljana : Univerza v Ljubljani – Fakulteta za računalništvo in informatiko, 2014.
Interoperabilnost v produktu Emit Cloud
52
10 PRILOGE
10.1 Naslov študenta
Ino Murko
112 Walm Lane
NW2 4RS
London
+44 7534 095864
ino.murko@outlook.com
10.2 Kratek življenjepis
Rojen: 14. 4. 1989
Šolanje: Osnovna šola Majšperk, Gimnazija Ptuj, univerzitetni študijski program
Računalništvo in informacijske tehnologije (UN)
Smetanovaulica17
2000Maribor,Slovenija
I Z J A V A O A V T O R S T V U
Spodaj podpisani
z vpisno številko
sem avtor diplomskega dela z naslovom:
S svojim podpisom zagotavljam, da:
• sem diplomsko delo izdelal samostojno pod mentorstvom
in somentorstvom
• so elektronska oblika diplomskega dela, naslov (slov., angl.), povzetek (slov.,
angl.) ter ključne besede (slov., angl.) identični s tiskano obliko diplomskega dela. • soglašam z javno objavo elektronske oblike diplomskega dela v DKUM.
V Londonu, dne
Podpis avtorja:
UNIVERZA V MARIBORU __________________________________________________ Fakulteta za elektrotehniko, računalništvo in informatiko
IZJAVA O ISTOVETNOSTI TISKANE IN ELEKTRONSKE VERZIJE MAGISTRSKEGA DELA IN OBJAVI OSEBNIH PODATKOV DIPLOMANTOV
Ime in priimek diplomanta: ___________________________________________________
Vpisna številka: _____________________________________________________________
Študijski program: ___________________________________________________________
Naslov magistrskega dela:_____________________________________________________
Mentor: ____________________________________________________________________
Podpisani _____________________________________ izjavljam, da sem za potrebe arhiviranja oddal elektronsko verzijo magistrskega dela v Digitalno knjižnico Univerze v Maraiboru. Magistrsko delo sem izdelal sam ob pomoči mentorja. V skladu s 1. Odstavkom 21. člena Zakona o avtorskih in sorodnih pravicah (Uradni list RS, št. 16/2007 – UPB3, 68/2008, 85/2010) dovoljujem, da se zgoraj navedeno magistrsko delo objavi na portalu Digitalne knjižnice Univerze v Mariboru. Tiskana verzija magistrskega dela je istovetna elektronski verziji, ki sem jo oddal za objavo v Digitalno knjižnico Univerze v Mariboru.
Podpisani izjavljam, da dovoljujem objavo osebnih podatkov, vezanih na zaključek študija, in sicer za spremljanje zaposlovanja diplomantov, za potrebe Kariernega centra ter Alumni klubov.
Magistrsko delo zaradi zagotavljanja konkurenčne prednosti, varstva industrijske lastnine ali tajnosti podatkov naročnika: _____________________________________________________ ne sme biti javno dostopno do __________________ (datum odloga javne objave ne sme biti daljši kot 3 leta od zagovora dela). Datum in kraj: ______________________
Podpis diplomanta:
__________________________________ Podpis mentorja: _________________________ (samo v primeru, če delo ne sme biti javno dostopno) Podpis odgovorne osebe naročnika in žig: _______________________________________ (samo v primeru, če delo ne sme biti javno dostopno)
Smetanovaulica17
2000Maribor,Slovenija
IZJAVA O USTREZNOSTI ZAKLJUČNEGA DELA
Podpisani mentor :
_____________________________________________
in somentor:
_____________________________________________
Izjavljam, da je študent
Ime in priimek:_________________________________
Vpisna številka:________________________________
Na programu:__________________________________
izdelal zaključno delo z naslovom:
_______________________________________________________________________
_______________________________________________________________________
v skladu z odobreno temo zaključnega dela, Navodilih o pripravi zaključnih del in mojimi (najinimi oziroma našimi) navodili. Preveril in pregledal sem poročilo o plagiatorstvu. Datum in kraj: Podpis mentorja: Datum in kraj: Podpis somentorja: Priloga:- »Poročiloopreverjanjupodobnostizdrugimideli.«