INTEROPERABILNOST V PRODUKTU EMIT CLOUD

Smetanovaulica17

2000Maribor,Slovenija

Ino Murko

INTEROPERABILNOST V PRODUKTU EMIT CLOUD

Magistrsko delo

London, januar 2016

Magistrsko delo univerzitetnega študijskega programa

II


Š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

IV

ZAHVALA

Zahvaljujem se mentorju doc. dr. Tomažu

Kosarju za pomoč in vodenje pri opravljanju

magistrskega dela.

V


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 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


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.


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.


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


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]


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:


7

1. ACTOR tip(akter identifikator1, akter identifikator2) CREATE; 2. INSERT INTO tabela VALUES(3, 'niz');


Zapisujemo lahko tudi v vse akterje istega tipa hkrati:

1. ACTOR tip(*) CREATE; 2. INSERT INTO tabela VALUES(3, 'niz');


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


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]


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


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č.


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.


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.


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


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.


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.


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).


17

Z uporabo vseh omenjenih OTP principov lahko dosežemo sisteme z neprekinjenim

delovanjem 99.999999999 % odstotka časa, kot je to uspelo Ericssonu.« [7]


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:


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.


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]


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.


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.


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.


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.


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,


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).


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


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.


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.


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:


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.


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.


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


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:


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.


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.


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


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


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:


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.


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.


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


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


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.


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.


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


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.


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/.


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.


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.


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.


52

10 PRILOGE

10.1 Naslov študenta

Ino Murko

112 Walm Lane

NW2 4RS

London

+44 7534 095864

[email protected]

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


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:

Ino Murko

E5008696


doc. dr. Tomaz Kosar, univ. dipl. inz. rac. in inf.

/

2.3.2016

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)

Ino Murko

E5008696

Racunalnistvo in informacijske tehnologije (MAG)


Tomaz Kosar

Ino Murko

2.3.2016, London

/

/

Smetanovaulica17


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.«

Tomaz Kosar

/

Ino Murko

E5008696

Racunalnistvo in informacijske tehnologije (MAG)


Interoperability in Emit Cloud product

/

/

INTEROPERABILNOST V PRODUKTU EMIT CLOUD

Documents

Transcript of INTEROPERABILNOST V PRODUKTU EMIT CLOUD