ANALIZA IN PRIMERJAVA OBLAČNIH STORITEV ZA RAZVOJ …

UNIVERZA V MARIBORU

FAKULTETA ZA ELEKTROTEHNIKO,

RAČUNALNIŠTVO IN INFORMATIKO

Aleksander Damiš

ANALIZA IN PRIMERJAVA OBLAČNIH STORITEV ZA RAZVOJ MOBILNIH ZALEDNIH

STORITEV

Magistrsko delo

Maribor, november 2017

ANALIZA IN PRIMERJAVA OBLAČNIH STORITEV ZA

RAZVOJ MOBILNIH ZALEDNIH STORITEV Magistrsko delo

Študent: Aleksander Damiš

Študijski program: Študijski program 2. stopnje

Informatika in tehnologije komuniciranja

Smer: Informatika in tehnologije komuniciranja MAG

Mentor: doc. dr. Boštjan Šumak, univ. dipl. inž. rač. in inf.

Lektorica: Natalija Furman Pogladič, prof. slov.

II

Analiza in primerjava oblačnih storitev za razvoj mobilnih zalednih storitev

Ključne besede: BaaS, zaledne, mobilne, storitve, analiza

UDK: 621.397.7-026.26(043.2)

Povzetek

Magistrsko delo posega na področje uporabe zalednih oblačnih storitev na mobilnih

napravah, ki postajajo vedno bolj priljubljene, saj razvijalcem omogočajo hitro vzpostavitev,

povezljivost in enostavno upravljanje med mobilnimi aplikacijami in zaledjem, kjer se hranijo

podatki. V raziskovalnem delu smo predstavili koncept storitev računalništva v oblaku,

opazovali njen razvoj in prehod uporabe storitev na mobilne platforme ter možnosti njihove

uporabe. Podrobno smo analizirali in predstavili vidne ponudnike zalednih storitev ter

povzeli njihove prednosti in slabosti. Obravnavane ponudnike zalednih storitev smo

ovrednotili in ocenili po preferencah in potrebah razvijalca mobilnih aplikacij.

III

Analysis and comparison of cloud services for development of mobile backend services

Key words: BaaS, backend, mobile, services, analysis

UDK: 621.397.7-026.26(043.2)

Abstract

This master thesis concerns usage of backend cloud services on mobile phones, which are

recently gaining popularity among developers, mainly because of their rapid connection

establishment, connectivity and easy management of mobile applications. In our research,

we presented the concept of cloud services and its usage on different mobile platforms. We

also analyzed and described few of the most prominent providers of backend mobile

services. For the purpose of evaluating and assessing different providers of backend mobile

services, we developed comparative analysis, through which we summarized their cons

and pros based upon preferences and perspective of the developer.

IV

KAZALO

1 UVOD .............................................................................................................. 1

1.1 Opredelitev problema ............................................................................................. 2

1.2 Namen raziskovalnega dela ................................................................................... 3

1.3 Raziskovalna vprašanja, predvidene metode dela .................................................. 4

1.4 Sestava raziskovalnega dela .................................................................................. 5

2 RAČUNALNIŠTVO V OBLAKU ....................................................................... 6

2.1 Zgodovina .............................................................................................................. 6

2.2 Virtualizacija ........................................................................................................... 7

2.3 Modeli računalništva v oblaku ................................................................................ 9

3 UPORABA MOBILNIH ZALEDNIH REŠITEV V PRAKSI ............................... 12

3.1 Faza načrtovanja pregleda ................................................................................... 12

3.2 Faza izvajanja pregleda ....................................................................................... 15

3.3 Rezultati sistematičnega pregleda ........................................................................ 17

4 UPORABA ZALEDNIH STORITEV PRI RAZVOJU MOBILNIH APLIKACIJ .. 19

4.1 Implementacija, procesiranje in shranjevanje podatkov ........................................ 20

4.2 Povezljivost .......................................................................................................... 21

5 PREDSTAVITEV PONUDNIKOV ZALEDNIH STORITEV ............................. 24

5.1 Microsoft Azure .................................................................................................... 24

5.2 Google Firebase ................................................................................................... 26

V

5.3 Amazon AWS ....................................................................................................... 29

5.4 Backendless ......................................................................................................... 31

5.5 Kinvey .................................................................................................................. 34

6 NAČRT ZA PRIMERJAVO PONUDNIKOV ZALEDNIH STORITEV .............. 37

6.1 Izdelava namenske aplikacije ............................................................................... 37

6.2 Izdelava primerjalnega modela ............................................................................. 38

6.3 Integracija v Microsoft Azure ................................................................................ 41

6.4 Integracija v Google Firebase ............................................................................... 48

6.5 Integracija v Amazon AWS ................................................................................... 53

6.6 Integracija v Backendless ..................................................................................... 59

6.7 Integracija v Kinvey .............................................................................................. 66

7 KOMPARATIVNA ANALIZA PONUDNIKOV STORITEV BAAS .................... 74

7.1 Rezultati merjenja implementacije zalednih storitev.............................................. 74

7.2 Primerjalna analiza ponudnikov ............................................................................ 88

7.3 Rezultati in analiza primerjave .............................................................................. 98

8 SKLEP ........................................................................................................... 99

8.1 Omejitve magistrskega dela ............................................................................... 101

8.2 Predlogi za prihodnje delo .................................................................................. 101

VI

KAZALO SLIK

SLIKA 2.1: ARHITEKTURA OBLAKA S STALIŠČA VIRTUALIZACIJE [1]. ......................................... 8

SLIKA 2.2: NAJBOLJ ZNANI PONUDNIKI POSAMEZNIH MODELOV STORITEV V OBLAKU [21]........ 10

SLIKA 2.3: MODELI RAČUNALNIŠTVA V OBLAKU [22]. ............................................................ 11

SLIKA 4.1: SESTAVA ODJEMALEC – STREŽNIK APLIKACIJ [31]. .............................................. 20

SLIKA 4.2: PRIMERI UPORABE VMESNIKOV API GLEDE NA RAZLIČNE FORMATE [31]. .............. 22

SLIKA 6.1: PREDVIDEN RAZREDNI DIAGRAM NAŠE MOBILNE APLIKACIJE................................. 38

SLIKA 6.2: NADZORNA PLOŠČA PORTALA AZURE, IZ KATEREGA JE RAZVIDNO NOVO USTVARJENO

ZALEDJE NAMENSKE APLIKACIJE LIMEORDER. .............................................................. 42

SLIKA 6.3: VKLJUČITEV KNJIŽNIC RAZVOJNEGA OGRODJA AZURE MOBILE CLIENT SDK V

PROJEKT MOBILNE APLIKACIJE. ................................................................................... 43

SLIKA 6.4: IZDELAVA TABELE V SKRIPTNEM JEZIKU T-SQL. .................................................. 44

SLIKA 6.5: UPORABA NOTACIJ ZA TRANSFORMACIJO PODATKOV V PODATKOVNI BAZI

MICROSOFT SQL....................................................................................................... 45

SLIKA 6.6: AVTENTIFIKACIJO DO STORITEV AZURE. ............................................................. 46

SLIKA 6.7: IMPLEMENTACIJA SERIALIZACIJE ZA REFERENČNE ZAPISE V DRUGI PODATKOVNI

TABELI. ..................................................................................................................... 47

SLIKA 6.8: REGISTRACIJA IMPLEMENTIRANEGA VMESNIKA ZA PRETVORBO REFERENČNIH

ZAPISOV. ................................................................................................................... 47

SLIKA 6.9: DEL PROGRAMSKE KODE, KI SKRBI ZA NAKNADNO SINHRONIZACIJO PODATKOV. .... 48

SLIKA 6.10: NADZORNA PLOŠČA PORTALA FIREBASE, IZ KATEREGA JE RAZVIDNO NOVO

USTVARJENO ZALEDJE NAMENSKE APLIKACIJE LIMEORDER. .......................................... 49

SLIKA 6.11: VKLJUČITEV KNJIŽNIC RAZVOJNEGA OGRODJA FIREBASE SDK V PROJEKT MOBILNE

APLIKACIJE. ............................................................................................................... 50

SLIKA 6.12: SLIKA PRIKAZUJE NASTAVITEV PRAVIL DOSTOPA DO PODATKOVNE BAZE. ............ 51

SLIKA 6.13: INTERAKCIJA Z ZALEDNIMI STORITVAMI PONUDNIKA FIREBASE. ........................... 52

SLIKA 6.14: NADZORNA PLOŠČA PORTALA AWS, IZ KATEREGA JE RAZVIDNO NOVO USTVARJENO

ZALEDJE NAMENSKE APLIKACIJE LIMEORDER. .............................................................. 54

SLIKA 6.15: VKLJUČITEV RAZVOJNEGA OGRODJA AWS MOBILE SDK V MOBILNO APLIKACIJO. 55

SLIKA 6.16: AVTENTIFIKACIJA DO STORITEV AWS. .............................................................. 55

SLIKA 6.17: EKSPLICITNO DEFINIRANJE REGIJE PODATKOVNIH CENTROV. ............................. 56

SLIKA 6.18: UPORABA NOTACIJ ZA PODATKOVNO BAZO AMAZON DYNAMODB. ...................... 58

VII

SLIKA 6.19: NADZORNA PLOŠČA PORTALA BACKENDLESS, IZ KATEREGA JE RAZVIDNO NOVO

USTVARJENO ZALEDJE NAMENSKE APLIKACIJE LIMEORDER. .......................................... 61

SLIKA 6.20: AVTENTIFIKACIJO ZA UPORABO ZALEDNIH STORITEV BACKENDLESS. .................. 62

SLIKA 6.21: IZDELAVA ATRIBUTOV PODATKOVNE BAZE PREKO NAMENSKEGA ČAROVNIKA ZA

UPORABO ZALEDNIH STORITEV BACKENDLESS. ............................................................ 62

SLIKA 6.22: STRUKTURA OBJEKTA ZA SHRANJEVANJE V PODATKOVNO BAZO PONUDNIKA

BACKENDLESS. ......................................................................................................... 63

SLIKA 6.23: PROGRAMSKA KODA, IZ KATERE JE RAZVIDNA SERIALIZACIJA OBJEKTOV ZNOTRAJ

PRIPADAJOČIH FUNKCIJ IN UPORABA ASINHRONEGA OPRAVILA. ..................................... 65

SLIKA 6.24: NADZORNA PLOŠČA PORTALA KINVEY. ............................................................. 67

SLIKA 6.25: AVTENTIFIKACIJA DO STORITEV KINVEY. ........................................................... 68

SLIKA 6.26: UPORABA NOTACIJ ZA TRANSFORMACIJO PODATKOV. ........................................ 69

SLIKA 6.27: POTREBNA PRIJAVA UPORABNIKA PRED INTERAKCIJO Z ZALEDNIMI STORITVAMI

PONUDNIKA KINVEY. .................................................................................................. 70

SLIKA 6.28: PROGRAMSKA KODA, IZ KATERE JE RAZVIDNA UPORABA POSLUŠALCEV PRI KLICU

ZALEDNIH STORITEV KINVEY. ...................................................................................... 72

SLIKA 6.29: DEL PROGRAMSKE KODE ZA DELO V NAČINU BREZ POVEZAVE. ........................... 73

SLIKA 7.1: GRAF REZULTATA ZA MERJENJE POSAMEZNIH OPERACIJ PRI INTEGRACIJI

MICROSOFT AZURE. .................................................................................................. 77

SLIKA 7.2: GRAF REZULTATA MERJENJA POSAMEZNIH OPERACIJ PRI INTEGRACIJI GOOGLE

FIREBASE. ................................................................................................................. 80

SLIKA 7.3: GRAF REZULTATA MERJENJA POSAMEZNIH OPERACIJ PRI INTEGRACIJI AMAZON

AWS. ....................................................................................................................... 82

SLIKA 7.4: GRAF REZULTATA MERJENJA POSAMEZNIH OPERACIJ PRI INTEGRACIJI

BACKENDLESS. ......................................................................................................... 85

SLIKA 7.5: GRAF REZULTATA MERJENJA POSAMEZNIH OPERACIJ PRI INTEGRACIJI

BACKENDLESS. ......................................................................................................... 88

SLIKA 7.6: GRAF REZULTATOV MERJENJA HITROSTI DOSTOPA DO PODATKOV. ....................... 89

SLIKA 7.7: GRAF REZULTATOV TOČKOVANJA PONUDBE OBRAVNAVANIH PONUDNIKOV. .......... 97

VIII

KAZALO TABEL

TABELA 1.1: UPORABLJENE RAZISKOVALNE METODE IN METODE ANALIZE. .............................. 4

TABELA 3.1: SEZNAM UPORABLJENIH DIGITALNIH KNJIŽNIC. ................................................. 12

TABELA 3.2: SESTAVA KLJUČNIH BESED IN NJIHOVIH SOPOMENK. ......................................... 13

TABELA 3.3: SESTAVLJENI ISKALNI NIZI. .............................................................................. 13

TABELA 3.4: VKLJUČITVENI IN IZKLJUČITVENI KRITERIJI ZA OPREDELITEV USTREZNE

LITERATURE. ............................................................................................................. 14

TABELA 3.5: REZULTATI ZA IZVEDBO PREGLEDA LITERATURE. .............................................. 15

TABELA 3.6: ŠTEVILO RELEVANTNIH IN IZBRANIH VIROV. ...................................................... 16

TABELA 3.7: IZBRANA RAZISKOVALNA DELA. ....................................................................... 16

TABELA 5.1: CENIK ZA UPORABO STORITEV PLATFORME MICROSOFT AZURE [39]. ................ 26

TABELA 5.2: CENIK ZA UPORABO STORITEV PLATFORME FIREBASE [42]. ............................... 28

TABELA 5.3: ZAJETE MOBILNE STORITVE ZNOTRAJ OMEJENE BREZPLAČNE RAZLIŽICE AWS

FREE TIER [49]. ......................................................................................................... 31

TABELA 5.4: CENIK UPORABE STORITEV PLATFORME BACKENDLESS [52]. ............................ 34

TABELA 5.5: CENIK ZA UPORABO STORITEV PLATFORME KINVEY [59]. .................................. 36

TABELA 6.1: NAČRT ZA IZVEDBO PRIMERJALNE PROCEDURE 1. ............................................ 39



TABELA 7.1: REZULTATI MERJENJA INTEGRACIJE STORITEV MICROSOFT AZURE PO KORAKIH ZA

PRIMERJALNO PROCEDURO 1. .................................................................................... 75





TABELA 7.4: REZULTATI MERJENJA POSAMEZNIH OPERACIJ PRI INTEGRACIJI MICROSOFT

AZURE. ..................................................................................................................... 76

TABELA 7.5: REZULTATI MERJENJA INTEGRACIJE STORITEV GOOGLE FIREBASE PO KORAKIH ZA






TABELA 7.8: REZULTATI MERJENJA POSAMEZNIH OPERACIJ PRI INTEGRACIJI FIREBASE. ........ 79

IX

TABELA 7.9: REZULTATI MERJENJA INTEGRACIJE STORITEV AMAZON AWS PO KORAKIH ZA






TABELA 7.12: REZULTATI MERJENJA POSAMEZNIH OPERACIJ PRI INTEGRACIJI AWS MOBILE. . 82

TABELA 7.13: REZULTATI MERJENJA INTEGRACIJE STORITEV BACKENDLESS PO KORAKIH ZA






TABELA 7.16: REZULTATI MERJENJA POSAMEZNIH OPERACIJ PRI INTEGRACIJI BACKENDLESS. 84

TABELA 7.17: REZULTATI MERJENJA INTEGRACIJE STORITEV KINVEY PO KORAKIH ZA






TABELA 7.20: REZULTATI MERJENJA POSAMEZNIH OPERACIJ PRI INTEGRACIJI KINVEY. .......... 87

TABELA 7.21: REZULTATI MERJENJA HITROSTI DOSTOPA DO PODATKOV. .............................. 89

TABELA 7.22: REZULTATI STATISTIČNIH TESTOV NA PODLAGI HITROSTI. ................................ 91

TABELA 7.23: REZULTATI ZA VELIKOSTI PODATKOVNIH BAZ. ................................................. 93

TABELA 7.24: PRIMERJAVA ZAJETIH STORITEV OBRAVNAVANIH PONUDNIKOV ZALEDNIH

STORITEV. ................................................................................................................. 94

TABELA 7.25: RAZPOREDITEV TOČK GLEDE NA OBRAVNAVANE KRITERIJE. ............................ 95

TABELA 7.26: REZULTATI TOČKOVANJA PONUDBE OBRAVNAVANIH PONUDNIKOV. .................. 97

X

SEZNAM KRATIC

NIST – National institute of Standards and Technology, U.S. Department of Commerce

VMM – Virtual Machine Manager

EC2 – Elastic Compute cloud

SaaS – Software as a Service

PaaS – Platform as a Service

IaaS – Infrastructure as a Service

BaaS – Backend as a Service

MBaaS – Mobile Backend as a Service

API – Application Program Interface

SDK – Software Development Kit

AWS – Amazon Web Service

SQL – Structured Query Language

SSMS – Microsoft SQL Server Management Studio


1

1 UVOD

Magistrsko delo posega na področje uporabe zalednih oblačnih storitev in dostopa do njih

iz mobilnih naprav. V zadnjih letih se je uporaba storitev računalništva v oblaku zelo razširila

in se nevidno integrirala v vsakdanje delo z računalnikom [1]. Ob vsakodnevnem napredku

tehnologij, vezanih na pametne mobilne naprave, se je pojavila potreba po novi vrsti

podpornega sistema kot storitev, na kar se znotraj našega raziskovalnega dela sklicujemo

kot zaledne oblačne storitve oziroma zaledne storitve. Mobilni podporni sistem kot storitev

oziroma mobilne zaledne storitve (angl. »Mobile backend as a service«) so model oblačnih

storitev, ki temelji tako na modelu platforme v smislu storitve (angl. »Platform as a service«).

Mobilni podporni sistem kot storitev tako predstavlja dostop do podatkov, dostop do

določenih funkcionalnosti ali drugih informacij z uporabo mobilne aplikacije. Uporaba

zalednih mobilnih storitev predstavlja spletnim ali mobilnim razvijalcem aplikacij možnost

povezovanja razvitih aplikacij preko izpostavljenega aplikacijskega vmesnika API (angl.

»Application Program Interface«) ali knjižnice SDK (angl. »Software Development Kit«) z

zalednimi storitvami [2] [3]. Te se v večini primerov uporabljajo za shranjevanje podatkov,

vezanih na uporabo aplikacije, njihova uporaba pa prav tako omogoča operiranje z

uporabniki, pošiljanje potisnih sporočil, integracijo s socialnimi omrežji, geolokacijske

storitve, biometrične analize, validacije in drugo.

Podporni sistem kot storitev oziroma zaledne storitve (BaaS – angl. »Backend as a

Service«) so iz dneva v dan popularnejše tudi zato, ker omogočajo razvijalcem hitro

vzpostavitev, povezljivost in enostavno upravljanje med zaledjem in njihovo aplikacijo.

Zaledne storitve omogočajo razvijalcem mobilnih aplikacij popolno abstrakcijo na strežniški

strani. Razvijalci lahko tako izbirajo med potrebnimi gradniki in uporabijo zgolj del

programske kode, s katero se želijo na zaledno storitev povezati. Omenjena abstrakcija

omogoča razvijalcem, da se lahko namesto upravljanja in razvoja zaledne infrastrukture

osredotočijo na razvoj in uveljavitev bogate uporabniške izkušnje [4]. Pomembnost mobilnih

zalednih storitev s stališča integracije se je pokazala že ob sami uvedbi storitev leta 2010,

ko so pri ponudniku obravnavanih storitev Parse beležili 40-odstotno tedensko rast prometa

[5]. Na priljubljenost uporabe mobilnih zalednih storitev kaže tudi podatek analitične

organizacije Gartner, ki navaja, da je v letu 2016 več kot 40 odstotkov mobilnih aplikacij na

svetovnem trgu uporabljalo zaledne mobilne storitve [6]. Analitična organizacija Gartner

predvideva, da bo uporaba zalednih ali drugih podobnih storitev do leta 2020 popolnoma


2

izpodrinila tradicionalne pristope razvoja mobilnih aplikacij [7]. Uporaba mobilnih zalednih

storitev je zelo razširjena tudi v rešitvah večjih organizacij ali podjetjih. Gartner namreč

ocenjuje, da bo do leta 2020 več kot 75 odstotkov večjih organizacij upravljalo s hibridno

infrastrukturo, ki bo omogočala uporabo mobilnih zalednih storitev enega ponudnika ali več

različnih ponudnikov [8].

1.1 Opredelitev problema

Na podlagi pregleda obstoječe literature, ki je v našem raziskovalnem delu vezana na razvoj

in možnosti uporabe zalednih storitev, smo ugotovili, da z uporabo oblačnih mobilnih

storitev znotraj mobilnih aplikacij razvijalci dobijo veliko število dodatnih možnosti za

izdelavo kakovostne in vsestranske mobilne aplikacije, ki ni vezana in dosegljiva zgolj na

eni mobilni napravi. Uporaba zalednih storitev je vsestranska; zaledne storitve se tako

uporabljajo v različnih mobilnih igrah (shranjevanje podatkov, dosežki, lestvice, upravljanje

virtualne ekonomije in podobno). Enako se uporabljajo v športnih aplikacijah za beleženje

aktivnosti kakor tudi v aplikacijah za socialna omrežja (sinhronizacija, objave uporabnikov,

sporočila in podobno).

Kljub razširjeni uporabi in širokim naborom ponudnikov omenjenih storitev pa se razvijalci

pogosto srečujejo s težavo pri izbiri ponudnika in potrebnim naborom funkcionalnosti, ki so

potrebne za delovanje zastavljene mobilne aplikacije. Storitve ponudnikov se razlikujejo

zlasti po cenovnih modelih, naboru funkcionalnosti, možnosti dodatne implementacije

lastnih modulov, možnosti povezljivosti in možnosti delovanja v načinu brez povezave.

Večina prepoznavnih ponudnikov ponuja brezplačen model uporabe z omejenim naborom

funkcionalnosti dostopa do storitev, pomnilnega prostora, arhiviranja podatkov in podobno.

Vendar v večini primerov mobilnih aplikacij omejena raba virov in storitev ne zadostuje, tako

da imajo ponudniki zalednih storitev tudi možnost dodatnega zakupa procesorskih virov,

pomnilnega prostora ali storitev samih. Obenem ima večina ponudnikov obravnavanih

storitev na voljo že v naprej pripravljene pakete uporabe, ki se razlikujejo v ceni. Ti paketi

imajo glede na ceno primerno veliko število zakupljenih virov, število hkratnih dostopov do

storitev in podobno. Vsi vidni ponudniki še imajo možnost uporabe cenovne strategije

»freemium«, ki brezplačno ponuja omejen nabor virov in funkcionalnosti, glede na potrebo

razvoja mobilne aplikacije pa razvijalci lahko zgolj zakupijo potrebne dodatne vire ali jih

plačajo po porabi. Osrednja problematika našega raziskovalnega dela se tako nanaša na


3

težavnost pri odločanju pravilne izbire ponudnika in potrebnega nabora funkcionalnosti, do

katerih želijo razvijalci dostopati preko svojih mobilnih aplikacij. Prav tako smo znotraj

magistrskega dela želeli poudariti preostale možnosti, težave in pridobitve, ki jih za

razvijalce prinaša uporaba zalednih mobilnih storitev.

1.2 Namen raziskovalnega dela

Namen raziskovalnega dela je podrobneje predstaviti delovanje zalednih storitev za

mobilne naprave, obenem pa raziskati dobre prakse in modele implementacije, ki so vezani

na integracijo s storitvami BaaS izbranih ponudnikov. V magistrskem delu je zajeta

obravnava izbranih ponudnikov zalednih storitev, pri kateri smo predstavili njihove

funkcionalnosti in možnosti uporabe ter integracije s knjižnicami ali aplikacijskimi vmesniki.

V magistrskem delu smo analitično predstavili prednosti in slabosti obravnavanih

ponudnikov, ki jih te prinašajo razvijalcem in posledično tudi končnim uporabnikom tovrstnih

mobilnih aplikacij.

V praktičnemu delu raziskave smo se osredotočili na načine integracije zalednih storitev v

namensko razvito mobilno rešitev, kjer so nas zanimali načini implementacije povezljivosti

do storitev kot tudi možnosti ter zmogljivosti prikazovanja, shranjevanja, sinhronizacije,

procesiranja in dostopa do podatkov. Po analizi omenjenih ponudnikov in razlik v naboru

funkcionalnosti smo izdelali primerjalni model, ki na podlagi preferenc razvijalca pomaga pri

izbiri najprimernejšega ponudnika obravnavanih zalednih storitev; namen izdelanega

modela bo tako pripomogel k lažjemu in hitrejšemu razvoju mobilne aplikacije. Cilji

raziskovalnega dela so bili:

pregled relevantne literature s področja raziskovanja;

pregled raziskovalnih modelov in ključnih spremenljivk, vključenih v izbrane

raziskave;

podrobneje predstaviti ponudnike storitev BaaS za mobilne naprave;

analitično predstaviti prednosti in slabosti obravnavanih ponudnikov;

izdelava testne mobilne aplikacije z omejenim naborom funkcionalnosti, na podlagi

katere smo lahko empirično ovrednotili zmogljivosti in možnosti uporabe storitev za

izbranih ponudnikov;


4

izdelava primerjalnega modela na podlagi vhodnih preferenc z vidika razvijalca in

podaja primerjalne analize med različnimi vrstami storitev izbranih ponudnikov

mobilnih zalednih storitev.

1.3 Raziskovalna vprašanja, predvidene metode dela

Z namenom doseganja ciljev raziskovalnega dela smo v procesu načrtovanja pregleda

splošnega pregleda literature, ki je podrobneje predstavljena v nadaljevanju magistrske

naloge, podali naslednja raziskovalna vprašanja:

RV1: Kako se razlikuje arhitektura mobilnih aplikacij, ki uporabljajo zaledne storitve

BaaS?

RV2: Kateri poslovni model uporabe zalednih storitev BaaS je najbolj razširjen?

RV3: Kateri ponudnik zalednih storitev BaaS ponuja največji nabor funkcionalnosti?

RV4: Kateri ponudnik zalednih storitev BaaS je najugodnejši?

RV5: Kateri ponudniki zalednih storitev BaaS omogočajo delo brez povezave?

RV6: Kateri ponudnik zalednih storitev BaaS ponuja najhitrejši dostop in

procesiranje podatkov?

Na podlagi zastavljenih raziskovalnih vprašanj smo pred raziskavo predvideli raziskovalne

metode in uporabljene metode za analizo pridobljenih podatkov. Tabela 1.1 prikazuje

uporabljene metode raziskovanja, s katerimi smo odgovorili na raziskovalna vprašanja.

Tabela 1.1: Uporabljene raziskovalne metode in metode analize.

Raziskovalno vprašanje

Uporabljene raziskovalne metode Uporabljene metode analize

RV1 Metoda proučevanja primerov Deskripcija, kompilacija, statistična metoda

RV2 Metoda proučevanja primerov Komparativna metoda, statistična metoda

RV3 Metoda proučevanja primerov, eksperiment

Klasifikacija, deskripcija

RV4 Metoda proučevanja primerov Statistična metoda

RV5 Metoda proučevanja primerov,

eksperiment

Komparativna metoda, statistična metoda

RV6 Eksperiment Metoda merjenja


5

1.4 Sestava raziskovalnega dela

Magistrsko delo je sestavljeno iz osmih tematskih sklopov. Po uvodu smo v drugem

poglavju podali kratko analizo in pregled stanja na področju storitev BaaS. Navedli smo tudi

dosežke drugih avtorjev, ki so izhodišče za magistrsko delo. V tretjem sklopu smo

predstavili koncept računalništva v oblaku, se dotaknili zgodovine razvoja in opisali pojem

virtualizacije. Omenili smo trenutno stanje uporabe oblačnih storitev v Sloveniji. V četrtem

poglavju smo podrobneje opredelili koncept storitev BaaS za mobilno platformo ter

empirično predstavili koncepte implementacije, povezljivosti, procesiranja in shranjevanja

podatkov. V petem delu smo natančneje predstavili večje število najbolj prepoznavnih

ponudnikov na področju storitev BaaS za mobilne rešitve. V nadaljevanju smo predstavili

proces integracije posameznega ponudnika v izdelano mobilno aplikacijo, nato smo podali

primerjavo posameznih ponudnikov z vidika uporabe razvijalca ter analitično ovrednotili

predhodno predstavljene ponudnike. V istem poglavju smo predstavili rezultate analitičnega

modela. V zadnjem, osmem poglavju, smo navedli spoznanja in odgovorili na raziskovalna

vprašanja. Podrobno so navedene omejitve, težave pri procesu raziskovalnega dela,

sklepna beseda in predlogi za prihodnje delo.


6

2 RAČUNALNIŠTVO V OBLAKU

Računalništvo v oblaku (angl. »Cloud computing«) predstavlja tehnologijo, ki z uporabo

medmrežja in oddaljenih strežnikov zagotavlja uporabo aplikacij ter omogoča nemoten

pretok izračunljivih podatkov in informacij. Koncept implementacije računalništva v oblaku

omogoča končnim uporabnikom uporabo aplikacij, nemoten dostop do podatkov in njihovo

obdelavo preko medmrežne dostopne točke brez potrebe po namestitvi ali ročnem prenosu

podatkov na lokacijo dostopa končnega uporabnika [1].

Zaradi takojšnjega dostopa do podatkov je razširjenost te tehnologije vsak dan večja. Iz

enega od podatkov analitične hiše Gartner je pokazano, da je za storitve po modelu

infrastrukture kot storitev predvidevana 29,1-odstotna skupna stopnja rasti do leta 2019 [6].

Razširjenost tehnologije se kaže tudi v številu ponudnikov in številu rešitev, ki temeljijo na

konceptu računalništva v oblaku tako za poslovno kakor za osebno rabo. Tehnologija je na

področju poslovne rabe razširjena zlasti zaradi visoke operativnosti in razpoložljivosti

obravnavanih podatkov v zameno za majhne stroške infrastrukture [9]. Računalništvo v

oblaku tako omogoča podjetjem, da njihove aplikacije z manj vzdrževanja, manj

infrastrukture in manjšim tveganjem obvladljivosti tečejo hitreje, želeni podatki pa na voljo

v želenem trenutku [10]. Struktura podjetja IT se lahko zato hitreje spreminja in prilagaja

poslovnim potrebam, težnjam trga, njihovim strankam in uporabnikom [11].

Razvoj in uveljavitev računalništva v oblaku sta pripomogla k izboljšanju računalniške

učinkovitosti in zmanjševanju stroškov za končnega uporabnika [12] [13] .

2.1 Zgodovina

Prvo omembo termina računalništva v oblaku lahko zasledimo v literaturi Ramnatha

Chellappe iz leta 1997, čeprav konceptualni začetki pojma računalništva v oblaku segajo v

60. leta prejšnjega stoletja, ko je John McCarhty zapisal, da bi lahko bilo računalništvo

nekega dne organizirano kot javni pripomoček [14] [15]. Nato se je v 90. letih pojavila ideja

računalniških mrež; koncept povezave naprav v električne mreže, s katerimi bi omogočili

enostaven dostop do razprostranih računalniških virov. Eno od prvih uveljavljenih podjetij

na področju računalništva v oblaku je bilo podjetje Salesforce.com, ki je leta 1999

predstavilo koncept uporabe naprednih poslovnih rešitev preko spletne strani. Naslednji

večji produkt na področju računalništva v oblaku je bil Amazon Web Service, ki ga je leta


7

2002 predstavilo podjetja Amazon. Vsakdanjo uporabnost za širšo populacijo za koncept

računalništva v oblaku pa je leta 2006 doprinesel produkt Google Docs. Istega leta je bil

predstavljen tudi produkt Amazon EC2, tj. komercialna spletna storitev, ki omogoča

manjšim podjetjem in posameznikom najem računalniških virov za poganjanje internih

aplikacij, produktov in rešitev. Temu trendu so sledila še druga velika podjetja in korporacije

[14]. Podjetji Google in IBM sta bila med prvimi, ki sta na podlagi ponujanja storitev

računalništva v oblaku začeli sodelovati z različnimi inštituti in univerzami širom ZDA.

Koncept računalništva v oblaku je dosegel nov nivo leta 2008, ko se pojavile prve

odprtokodne programske rešitve podjetja Eucalyptus Systems in OpenNebula, namenjene

za izdelavo zasebnih oblakov. Leta 2009 je podjetje Microsoft predstavilo njihovo storitev

Microsoft Azure, ki je danes eno od vodilnih na področju uporabe storitev računalništva v

oblaku [14].

Uporaba oblačnih storitev in število ponudnikov se še vedno veča iz dneva v dan, enako so

se oblačne storitve in uporabnost z leti razvijale tudi na območju Slovenije. V Sloveniji danes

vsakodnevno uporablja oblačne storitve 17 odstotkov srednjih ali malih podjetij [16].

Obstajajo tudi slovenska podjetja, ki nudijo tako svoje poslovne kakor zasebne rešitve,

vezane na storitve računalništva v oblaku. Med številnimi domačimi ponudniki sta najbolj

prepoznavni podjetji Virtu, ki nudi rešitev Flip IT za manjša in velika podjetja, ki za svoje

poslovanje potrebujejo primerno urejen informacijski sistem, ter podjetje SAOP

računalništvo, ki ponuja spletni računovodski program miniMAX, namenjen malim

podjetjem in računovodskim servisom [17].

2.2 Virtualizacija

Virtualizacija predstavlja ključno komponento za zagotavljanje storitev shranjevanja in

računalniških virov. Virtualizacija je skupek povezanih strojnih naprav in računalniških virov

kot neodvisno plast strojne opreme na strežniku ali delovni postaji. Na Slika 2.1 vidimo

shemo arhitekture oblačne infrastrukture, s stališča virtualizacije. Virtualizacija temelji na

tehnologiji VMM ali virtualnem skrbniku, ki upravlja in predstavlja skupek računalniških virov

kljub ločeni dejanski fizični lokaciji oziroma infrastrukturi. Z virtualizacijo zagotovimo tudi

skalabilnost. Na podlagi zagotavljanja performančnih zahtev podjetja lahko vire vedno

dodajamo ali odvzemamo.


8

Slika 2.1: Arhitektura oblaka s stališča virtualizacije [1].

Kot je razvidno iz Slike 2.1, računalništvo v oblaku omogoča končnim uporabnikom dostop

do storitev kjer koli skozi različne vrste medijev. Obdelani viri ali podatki za končnega

uporabnika niso več prikazani kot lokalno shranjena entiteta, temveč so dosegljivi na

zahtevo uporabnika na terminalu, prenosnem računalniku, mobilnem telefonu ali drugi

napravi dostopa. Uporabniki lahko te informacije uporabljajo, zadržijo in varno delijo.

Upravljajo lahko opravila, ki niso mogoča na enem računalniku. Sloj upravljanja z uporabniki

(angl. »User managent layer«) predstavlja interakcijsko povezavo med uporabnikom in

oblakom, preko katere se vršita dostop in identifikacija uporabnika. Storitveni sloj (angl.

»Service layer«) preoblikuje različne oblačne vire v zahtevano obliko storitev (pomnilnik,

SaaS, PaaS) in jo nato prikaže končnemu uporabniku, medtem ko sloj virtualnih virov (angl.

»Virtual resources layer«) povezuje različne virtualne vire in jih predaja zgornjim slojem.

Naslednji sloj upravlja z dejanskim procesom virtualizacije in skrbi za združevanje

računalniških virov, ki so infrastrukturno in fizično ločeni. Zadnji sloj predstavlja fizične vire

(angl. »Physical resource layer«) in zagotavlja temelje celotne oblačne platforme, enako

zagotavlja proces za fizično shranjevanje podatkov. Uveljavitev virtualizacije omogoča

uporabnikom oblačnih storitev, da lahko brezskrbno operirajo z zahtevanimi viri, brez

potrebe po vzdrževanju ali optimizaciji fizične lokacije računalniških virov.


9

Ugotovimo, da se pri pregledu literature in pri uporabi terminologije v realnem svetu večkrat

mešata pojma računalništva v oblaku in virtualizacije [18] [19].

Oba pojma predstavljata skupek povezanih računalniških virov, vendar obstaja razlika v

načinu dostopa do podatkov in virov. V primeru uporabe oblaka se dostop do virov vrši s

storitvijo na zahtevo preko medmrežja. Pri tem pa pojavi tudi nov koncept zasebnega

oblaka, pri čemer virtualizacija, ki predstavlja skupek povezanih strojnih naprav,

posamezne vire prikazujejo in uporabljajo kot celoto, le da v tem primeru medija pretoka

informacij ne predstavlja medmrežje, ampak lokalno omrežje ali skupek lokalnih povezav

organizacije ali podjetja [18] [20].

2.3 Modeli računalništva v oblaku

Pojem računalništva v oblaku so na inštitutu NIST opisali s petimi ključnimi karakteristikami,

ki ga sestavljajo ga trije modeli storitev in štirje razvojni modeli. Na Slika 2.3 je prikazan

skupen diagram modelov računalništva v oblaku. Ključne karakteristike računalništva v

oblaku, ki so jedro ideje računalništva v oblaku, kot ga poznamo danes, so:

samostojna storitev na zahtevo (angl. »On demand self-service«);

vseprisotnost omrežnega dostopa (angl. »Ubiquitous network access«);

združevanje virov neodvisno od lokacije (angl. »Location independent resource

pooling«);

hitra elastičnost (angl. »Rapid elasticity«);

plačilo za uporabo (angl. »Pay per use«).

Modeli storitev so definirani kot:

Programska oprema kot storitev (storitev SaaS) – uporabnik pri uporabi tovrstnih

storitev brezskrbno razpolaga s podatki in funkcionalnostmi storitev, medtem ko ima

ponudnik popoln nadzor nad upravljanjem, vzdrževanjem in varnostjo. Najbolj

razširjeni rešitvi storitev SaaS sta Gmail in Salesforce CRM (na Slika 2.2 so

prikazani preostali ponudniki omenjenih storitev).

Platforma kot storitev (storitev PaaS) – platforma nudi uporabnikom operiranje na

vseh nivojih delovanja želene aplikacije. Vidni ponudniki storitev PaaS so Google

Apps Engine in Microsoft Windows Azure.


10

Infrastruktura kot storitev (storitev IaaS) – ponudniki storitev proti plačilu zagotavljajo

virtualne računalnike, pomnilni prostor, infrastrukturne komponente za odjemalce in

drugo. Pionir in najbolj razširjen ponudnik na tem področju je podjetje Amazon.

Slika 2.2: Najbolj znani ponudniki posameznih modelov storitev v oblaku [21].

Razvojni modeli so:

zasebni oblak – infrastrukturo oblaka upravlja zgolj podjetje, organizacije ali

posameznik;

skupinski oblak – infrastruktura je deljena znotraj različnih skupnosti, organizacij ter

koncernov in je primerna za deljenje virov, informacij in drugo;

javni oblak – infrastruktura oblaka je dostopna širši množici uporabnikov ali večjim

industrijskim skupinam, praviloma v lasti ponudnika teh omenjenih storitev;

hibridni oblak – infrastruktura je sestavljena iz dveh ali več različnih oblakov (drugih

modelov – zasebnih ali javnih) in omogoča prenos na podlagi standardizacije entitet.


11

Slika 2.3: Modeli računalništva v oblaku [22].

Ob vsestranskem razvoju mobilnih naprav pa čedalje večji delež uporabnosti na podlagi

modela storitev predstavljajo tudi mobilne zaledne rešitve, ki so podrobneje opisane v

naslednjem poglavju [23] [24].


12

3 UPORABA MOBILNIH ZALEDNIH REŠITEV V PRAKSI

V sklopu magistrskega dela smo opravili pregled obstoječe literature, stanja na področju

računalništva v oblaku in uporabe mobilnih zalednih rešitev. Proučili smo koncept

računalništva v oblaku in koncept delovanja storitev BaaS za mobilne rešitve, zmogljivosti

storitev, njihove omejitve in možnosti uporabe, ki so vezane tako na razvijalca kakor tudi na

končnega uporabnika. Za pregled literature smo uporabili empirično raziskovalno metodo

sistematičnega pregleda literature, s katero smo povzeli in združili obstoječa dela na

področju mobilnih zalednih storitev. Z omenjeno raziskovalno metodo smo lahko odgovorili

na prvo (RV1) in drugo (RV2) raziskovalno vprašanje. Metodo sistematičnega pregleda

literature sestavljajo naslednje faze:

faza načrtovanja pregleda – definicija raziskovalnih vprašanj, izdelava strategije

iskanja virov, postavitev iskalnega niza in identificiranje vira podatkov;

faza izvajanja pregleda – predstavitev rezultatov, pridobljenih v procesu glede na

zasnovane kriterije in vire;

faza poročanja o pregledu – na podlagi prikazanih rezultatov pregleda obstoječe

literature smo pridobili osnovo za iskanje odgovorov na raziskovalna vprašanja.

3.1 Faza načrtovanja pregleda

V sklopu prve faze sistematičnega pregleda literature smo podali raziskovalna vprašanja,

iskalni niz in definirali podatkovne vire. Pri tej fazi smo določili kriterije za izbiro primarnih

raziskav in strategijo iskanja obstoječih del drugih avtorjev, pri čemer smo se sklicevali na

raziskovalna vprašanja, navedena v uvodu raziskovalnega dela.

Za pregled obstoječe literature in dosežkov drugih avtorjev smo uporabili različne digitalne

vire. Ti so navedeni v Tabeli 3.1M, kjer je prikazan seznam uporabljenih digitalnih knjižnic

skupaj z njihovimi povezavami.

Tabela 3.1: Seznam uporabljenih digitalnih knjižnic.

Digitalna knjižnica Spletni naslov

Science Direct www.sciencedirect.com

Springer http://www.springer.com/

http://www.sciencedirect.com/

http://www.springer.com/


13

Google Scholar https://scholar.google.si/

IEEE http://ieeexplore.ieee.org/

Z namenom, da bi odgovorili na zastavljena raziskovalna vprašanja, smo za iskanje

literature po omenjenih virih, opredelili besede, ki sovpadajo S tematiko našega

raziskovalnega dela. To so:

BaaS;

mobile;

provider;

implementation;

api;

sdk;

access;

development.

Na podlagi izbranih besed smo določili glavne besede in njihove pomožne sopomenke. V

Tabela 3.2 je prikazana izdelava ključnih besed in pomožnih besed, na podlagi katerih smo

lahko definirali iskalne nize.

Tabela 3.2: Sestava ključnih besed in njihovih sopomenk.

Ključne besede Pomožne besede

BaaS Backend, service

MBaaS Mobile backend

Provider /

Implementation API, SDK, access

Development Integration

Na podlagi ključnih besed smo izdelali iskalne nize. V Tabela 3.3 so ponazorjeni sestavljeni

iskalni nizi skupaj z obrazloženim namenom.

Tabela 3.3: Sestavljeni iskalni nizi.

Iskalni niz Namen

1 mobile BaaS backend providers service

difference

Pridobiti podatke o različnih

ponudnikih zalednih storitev in

https://scholar.google.si/

http://ieeexplore.ieee.org/


14

razlikah med njihovim delovanjem in

ponudbo

2 mobile BaaS backend implementation

access api sdk

Pridobiti podatke o načinih

delovanja, poslovnih modelih

uporabe in implementaciji

3 development mobile BaaS application Pridobiti podatke o razvoju

aplikacije z vključenimi zalednimi

storitvami

Kot je razvidno iz Tabele 3.3, smo iz prvega iskalnega niza pridobili podatke o ponudnikih

mobilnih zalednih storitev in njihovih razlikah. Z drugim iskalnim nizom smo pridobili podatke

o poslovnih modelih in načinih delovanja, medtem ko smo s tretjim iskalnim nizom pridobili

podatke o načinu razvoja mobilne aplikacije in možnostmi integracije zalednih storitev v

mobilni aplikaciji. S pomočjo sestavljenih iskalnih virov smo pridobili skupek potencialnih

virov, ki so podrobneje predstavljeni v naslednjem podpoglavju. Z namenom pridobitve

ustrezne in relevantne aktualne literature smo pridobljene vire klasificirali po vnaprej

definiranih vključevalnih oziroma izključevalnih kriterijih. V Tabela 3.4 lahko vidimo nabor

sestavljenih iskalnih nizov.

Tabela 3.4: Vključitveni in izključitveni kriteriji za opredelitev ustrezne literature.

Vključitveni

kriteriji iskanja

Omejitve Samo literatura s področja računalništva

v oblaku, storitev BaaS in mobilnih

tehnologij.

Samo knjige in znanstveni članki z

izjemo poljudnoznanstvenih člankov na

spletu.

Samo literatura, vezana na mobilno.

Časovno

obdobje

Od leta 2010 dalje.

Vključene

raziskovalne

metode

študija literature;

klasifikacija;

deskripcija;

kompilacija;

komparativna metoda;

statistična metoda;

metoda proučevanja primerov;


15

metoda merjenja.

Odgovori na

raziskovalna

vprašanja

Vsebina virov mora v celoti ali deloma odgovoriti

na eno ali več zastavljenih raziskovalnih

vprašanj.

Izključitveni

kriteriji iskanja

Poljudne revije;

nepreverjena vsebina;

v celoti nedostopni viri in viri, ki niso napisani v angleškem

ali slovenskem jeziku.

Kot je razvidno iz Tabele 3.4, smo pridobljene vire omejili zgolj na literaturo s področja

računalništva v oblaku, storitev BaaS in drugih mobilnih tehnologij. Pri tem smo izključili

članke iz poljudnih revij ali druge vsebine, ki niso preverjene ali niso napisane v angleškem

oziroma slovenskem jeziku. Enako smo opredelili časovno obdobje po letu 2010, kajti pred

tem se tehnologija zalednih storitev za mobilne naprave še ni uporabljala.

3.2 Faza izvajanja pregleda

V procesu pregleda literature smo na podlagi podanih iskalnih nizov in uporabljenih kriterijev

pridobili večje število sorodnih raziskovalnih del. V Tabela 3.5 so ponazorjeni rezultati za

izvedbo sistematičnega pregleda literature, pri čemer podatki v vrsticah predstavljajo število

najdenih virov glede na zastavljen iskalni niz v uporabljeni digitalni knjižnici.

Tabela 3.5: Rezultati za izvedbo pregleda literature.

Iskalni niz 1 Iskalni niz 2 Iskalni niz 3

Science Direct 2 1 32

Springer 5 2 1091

Google Scholar 192 37 5220

IEEE 34 1 11

Na podlagi potreb in ciljev našega raziskovalnega dela smo pridobljeno literaturo analizirali

tako, da smo najprej pregledali naslove in druge meta podatke, nato pa ustrezna dela v

primeru izpopolnjevanja vključitveno izključitvenih kriterijev vključili v seznam izbranih

obstoječih del. V Tabela 3.6 je prikazano število najdenih relevantnih virov in število izbranih

virov, ki so služili kot izhodišče za naše raziskovalno delo.


16

Tabela 3.6: Število relevantnih in izbranih virov.

Število virov Število izbranih del

Iskalni niz 1 233 3

Iskalni niz 2 41 1

Iskalni niz 3 6354 4

V Tabela 3.7 je ponazorjen seznam izbranih obstoječih raziskovalnih del, ki so osnova za

naše raziskovalno delo.

Tabela 3.7: Izbrana raziskovalna dela.

Naslov Avtor Članek ISBN Leto

izdaje

Virtualization and

Cloud Computing

Yuping Xing,

Yongzhao Zhan

Future Wireless

Networks and

Information

Systems [1]

978-3-642-

27322-3

2012

The Lowly API Is

Ready to Step Front

and Center

Lee Garber Computer Vol.

46; Issue 8 [2]

0018-9162 2013

Backend As A

Service – Using the

Example of Eniginio

a Cloud Service to Qt

Wilfried Kohl Cloud service for

Qt WS 2013/14

[4]

2013

Beginning Hybrid

Mobile Application

Development

Mahesh Panhale Introduction to

Mobile

Application

Development

Ecosystems [25]

978-1-4842-

1315-5

2016

Solving the Cloud

Computing Impasse

with MBaaS

Michael P.

Rogers, Bill

Siever

SIGCSE '16

Proceedings of

the 47th ACM

Technical

Syposium on

Computing

978-1-4503-

3685-7

2016


17

Science

Education [26]

Availability

Evaluation and

Sensitivity Analysis

of a Mobile Backend-

as-a-service Platform

Igor Costa, Jean

Araujo, Jamilson

Dantas, Eliomar

Campos,

Francisco Airton

Silva, Paulo

Maciel

Quality and

Reliability

Engineering

International [27]

2015

Develop and Scale

Mobile Services in

Cloud Computing

Scenarios

Martin Ott [3] 2013

Cloud Solutions for

Mobile Applications

Anssi Soinu [28] 2014

3.3 Rezultati sistematičnega pregleda

Po pridobljenih rezultatih sistematičnega pregleda literature smo dobili izhodišče za naše

raziskovalno delo. Z analizo izbranih raziskav, pridobljenih s sistematičnim pregledom

literature, smo spoznali zgodovino, razvoj in delovanje računalništva v oblaku, skupaj s

spremembami, ki jih je v informacijske tehnologije prinesla obravnavana tehnologija [1].

Znotraj izbranih rezultatov smo pridobili znanje o modelih delovanja, načinih dostopa in

možnostih implementacije [4]. Na podlagi izbranih del [1] [2] smo lahko v naslednjih

poglavjih podrobneje predstavili modele delovanja, arhitekturo in ponudnike tovrstnih

storitev [4]. V naslednjih poglavjih smo predstavili tudi korelacijo med virtualizacijo in

računalništvom v oblaku, varnostna tveganja, ki jih obravnavana tehnologija prinaša, in

rešitve [1] [2]. Znotraj samega procesa izdelave sistematičnega pregleda literature smo se

osredinili na dela, ki zajemajo predstavitev in uporabo podpornega sistema kot storitev za

mobilne aplikacije, ki temelji na tehnologiji računalništva v oblaku [3] [4] [25] [26] [27] [28].

Na podlagi izbranih del [4] [25] smo pridobili znanje o razvoju mobilnih aplikacij skozi čas in

izluščili razloge in potrebe za izdelavo hibridnih mobilnih aplikacij, kar smo podrobneje

opisali v preostalih poglavjih magistrskega dela. Znotraj pregleda literature smo pridobili

tudi osnovno znanje o izgradnji mobilne aplikacije s trislojno arhitekturo mobilnih storitev


18

[27]. Kot rezultat izbranih del [4] [25] [26] [28] smo s predstavljeno študijo primera pridobili

potrebno znanje o ponudnikih podpornih sistemov kot storitev, znanje o implementaciji

zalednih storitev in osnovne kriterije (hitrost, varnost, dostop do podatkov, podpora in

podobno) za primerjavo pozneje predstavljenih izbranih ponudnikov znotraj našega

raziskovalnega dela. Prav tako smo na podlagi spoznanj zaključkov del drugih avtorjev

pridobili osnovno znanje, ki smo ga potrebovali za odgovore na zastavljena raziskovalna

vprašanja.


19

4 UPORABA ZALEDNIH STORITEV PRI RAZVOJU MOBILNIH APLIKACIJ

Ob vsakodnevnem napredku tehnologij, vezanih na pametne mobilne naprave, se je

pojavila potreba po novi vrsti tako imenovanih zalednih oblačnih storitev. Mobilne zaledne

storitve (angl. »Mobile backend as a service«) predstavljajo model oblačnih storitev, ki

omogoča spletnim ali mobilnim razvijalcem aplikacij možnost povezovanja razvitih aplikacij

preko izpostavljenega aplikacijskega vmesnika API ali knjižnice SDK z zalednimi storitvami.

Zaledne storitve se v večini primerov uporabljajo za shranjevanja podatkov, vezanih na

uporabo aplikacije, njihova uporaba pa prav tako omogoča operiranje z uporabniki, možnost

pošiljanja potisnih sporočil, integracijo s socialnimi omrežji, geolokacijske storitve,

biometrične analize, validacije in drugo [2] [4] [25] [27].

Začetki uporabe storitev BaaS segajo v leto 2010, zato je ta vrsta storitev za zdaj še

razmeroma slabo poznana tako razvijalcem kakor končnim uporabnikom [29]. Vendar

zaradi splošne priljubljenosti uporabe mobilnih naprav, hitrega razvoja mobilnih aplikacij in

storitev ter vse večje potrebe po skladiščenju podatkov mobilnih aplikacij so storitve BaaS

hitro rastoči trend v konceptu računalništva v oblaku.

Storitve BaaS so iz dneva v dan popularnejše tudi zato, ker omogočajo razvijalcem hitro

vzpostavitev, povezljivost in enostavno upravljanje med zaledjem in njihovo aplikacijo.

Zaledne storitve omogočajo razvijalcem mobilnih aplikacij popolno abstrakcijo na strežniški

strani. Razvijalci lahko tako izbirajo med potrebnimi gradniki in uporabijo zgolj del

programske kode, s katero se želijo na zaledno storitev povezati [30]. Omenjena abstrakcija

omogoča razvijalcem, da se lahko, namesto upravljanja in razvoja zaledne infrastrukture,

osredotočijo na razvoj in uveljavitev bogate uporabniške izkušnje. Prednosti uporabe

storitev BaaS za razvijalce so:

ponudniki zalednih storitev uporabljajo tehnike optimizacije podatkov, ki zmanjšujejo

probleme, vezane na razmetanost podatkov med platformami in napravami;

prihranek časa in truda razvijalcev, kar omogoča paketna infrastruktura, ki

zagotavlja skalabilnost in visoke zmogljivosti aplikacije;

uporaba storitev BaaS pospeši čas razvoja aplikacije in implementacije prihodnjih

posodobitev.


20

4.1 Implementacija, procesiranje in shranjevanje podatkov

Veliko število poslovnih ali zasebnih mobilnih aplikacij lahko kategoriziramo kot aplikacije

odjemalec – strežnik (angl. »client-server apps«). Omenjene aplikacije so z odjemalčeve

strani (angl. »client side«) ali iz ospredja (angl. »frontend«) ter s strani strežnika (angl.

»server side«) ali iz zaledja (angl. »backend«). Ospredje je tisti del, ki je viden končnemu

uporabniku, naj bo to na zaslonu mobilne naprave ali osebnega računalnika. Ospredje je

zadolženo za vodenje končnega uporabnika skozi potek delovanja mobilne aplikacije.

Ospredje vsake mobilne aplikacije predstavlja uporabniško izkušnjo, medtem ko zaledje

predstavlja njegovo logiko [3] [31]. Na Slika 4.1 je podrobneje prikazano zaledje, sestavljeno

iz dveh komponent. To so:

poslovna logika aplikacije (angl. »application business logic«);

upravljanje/procesiranje podatkov (angl. »data processing / management«).

Komponenta procesiranja podatkov upravlja na podlagi različnih virov. Ti so lahko

uporabniki, statični podatki, sporočila, elektronska pošta, geolokacijski podatki, datoteke,

medijski zapisi in drugo [31].

Slika 4.1: Sestava odjemalec – strežnik aplikacij [31].

Arhitekturno ločevanje sloja poslovne logike od preostanka operacij procesiranja in

shranjevanja podatkov je pomemben del pri načrtovanju arhitekture aplikacije. V nekaterih


21

situacijah je lahko sloj poslovne logike tudi generičen; o generični poslovni logiki govorimo

v primerih, ko so operacije poslovne logike enake operacijam dostopa ali shranjevanja

podatkov. V kompleksnejših primerih in uporabi zlasti poslovnih aplikacij, pri čemer

potrebujemo kaj več kot shranjevanje, branje, urejanje in brisanje podatkov, pa je uporaba

ločenega sloja poslovne logike ključnega pomena pri razvoju aplikacije [3]. Primeri uporabe

poslovne logike v kompleksnejših mobilnih rešitvah predstavljajo prijavo oziroma

identifikacijo uporabnika, nalaganje datotek, pošiljanje poštnih sporočil, procesiranje

podatkov, pošiljanje potisnih sporočil in podobno. Te funkcionalnosti se v primeru

implementacije na strani odjemalca lahko od platforme precej razlikujejo in predstavljajo

razvijalcem dodatno delo, zato se v omenjenih kompleksnih primerih te funkcionalnosti

zavijejo v modul ali paket in predstavljajo vrhnjo plast na strežniški strani.

4.2 Povezljivost

Z namenom, da bi lahko razvijalci znotraj svojih aplikacij uporabljali zaledne storitve, so

predvideni komunikacijski protokoli, ki definirajo pretok podatkov kot tudi strukturo podatkov

med stranjo odjemalca in strežnika [26]. Rezultat združitve protokola za povezljivost in

dogovorjeno strukturo podatkov je programski vmesnik, ki omogoča strani odjemalca

komunikacijo s strežniško stranjo. Standardni izraz za omenjen rezultat je vmesnik API in ti

so lahko različnih formatov [2] [3] [31]. Na Slika 4.2 so ponazorjeni vmesniki API. Formati

programskih vmesnikov API so lahko:

Generični vmesniki API (angl. »Generic API«) – primerni za komunikacijo ne glede

na format in strukturo podatkov mobilne aplikacije. S tem je možna uporaba

vmesnika API katerega koli mobilnega odjemalca. Primer tovrstnega vmesnika je

storitev REST.

Namenski vmesniki API (angl. »Specialized API format«) – ti vmesniki so razviti za

specifične odjemalce v različnih programskih jezikih. Primeri so vmesniki API za

programski jezik Java (platforma Android), vmesnik za programski jezik C (platforma

iOS), vmesnik za programske jezike NET (platforma Windows Phone) in drugo. Kot

je povedano, so namenski vmesniki API praviloma distribuirani kot knjižnice v

naravnem (angl. »native«) programskem jeziku za odjemalce posameznih platform,

ki jih razvijalci uporabijo za dostop do funkcij zalednih storitev.


22

Slika 4.2: Primeri uporabe vmesnikov API glede na različne formate [31].

Kot je bilo že povedano, omogoča uporaba vmesnikov API razvijalcem mobilnih rešitev

hitrejši razvoj mobilne aplikacije. Razvijalci se namreč morajo osredotočiti zgolj na razvoj

sprednjega dela aplikacije, zagotavljanje celovite uporabniške izkušnje, medtem ko za

procesiranje podatkov in programsko logiko uporabijo storitve BaaS. Pri tem je treba

omeniti, da lahko nastanejo težave, kajti zaledne storitve so ne glede na različno poslovno

logiko generične, vsaka mobilna rešitev pa ima svoj nabor specifičnih zahtev, zato je treba

nekatere dele programske logike vključiti tudi na sloj odjemalca. Pri uporabi zalednih

storitev se v teh primerih uporabljajo naslednji pristopi:

Upraviteljska konzola (angl. »Developer/Management console«) – tipična zaledna

rešitev vsebuje konzolo, ki za razvijalca predstavlja vmesnik do zalednih storitev.

Uporaba konzole je vezana na konfiguracijo zalednih storitev in funkcij upravljanja.

Z uporabo konzole lahko razvijalec operira s podatki aplikacije, vzpostavlja

varnostne politike in prilagaja nekatere poslovne rešitve.

Koda na strežniški strani po meri – možnost izvajanja namenske kode na strani

strežnika predstavlja najbolj fleksibilno možnost za vključevanje storitev BaaS v

mobilno aplikacijo s specifično logiko. Koda po meri lahko vsebuje obstoječe dele

funkcionalnosti zalednih storitev ali ustvari novo samostojno logiko. Ta pristop

omogoča razvijalcem objavo svojih storitev s specifično programsko logiko za

reševanje specifičnih primerov uporabe.


23

Poslovna logika na strani odjemalca – ta pristop omogoča razvijalcem razvoj

specifične poslovne logike neposredno na svojo mobilno aplikacijo. Ta modificirana

različica odjemalca tako vsili svojo poslovno logiko pred tisto od zalednih storitev.


24

5 PREDSTAVITEV PONUDNIKOV ZALEDNIH STORITEV

V tem poglavju smo analitično predstavili pet različnih ponudnikov zalednih storitev. Zaradi

vsesplošne razširjenosti uporabe mobilnih zalednih storitev število ponudnikov zalednih

storitev BaaS narašča iz dneva v dan, tako da smo v sklopu magistrskega dela izbrali

ponudnike storitev BaaS, na podlagi kriterija prepoznavnosti, možnosti brezplačne uporabe

in razširjenosti glede uporabe [32] [33] [34]. Zaradi širokega nabora funkcionalnosti smo v

raziskovalno delo vključili večje ponudnike storitev Microsoft Azure, Amazon Web Services

in Google Firebase. Predstavili in podrobneje smo analizirali storitve ponudnika

Backendless, še zlasti zaradi širokih možnosti brezplačne uporabe, in storitve ponudnika

Kinvey zaradi razširjenosti glede uporabe. Vsakega ponudnika zalednih storitev smo

podrobneje predstavili v svojem podpoglavju, pri čemer smo poudarili njihove ključne

karakteristike in načine delovanja sistemov. Pri obravnavi vsakega ponudnika zalednih

rešitev smo opisali tako osnovne gradnike njihovih platform kakor tudi osnovne cenovne

modele za uporabo zalednih storitev.

5.1 Microsoft Azure

Microsoft Azure je platforma računalništva v oblaku in infrastruktura, ustvarjena za razvoj,

vpeljavo in upravljanje aplikacij ter storitev preko globalnega omrežja [35]. Microsoft je svojo

storitveno platformo Azure predstavil na konferenci za razvijalce Microsoft PDC leta 2008.

Sprva se je storitev imenovala Windows Azure, nakar je bila leta 2014 preimenovana v

Microsoft Azure [36]. Platformo sestavljajo spletne storitve Windows Azure, Microsoft SQL,

Microsoft .NET, Live, Microsoft SharePoint in Microsoft Dynamics CRM [37]. Razvijalcem

nudi okolje za razvoj storitev PaaS in storitev IaaS, v okviru je možen razvoj s poljubnim

programskim jezikom, podprtem v .NET Framework in interakcijo z dobro znanimi

storitvami. Storitvena platforma Azure Services Platform uresničuje združevanje

programske opreme in storitev, prav tako pa omogoča razvoj aplikacij povezanih po principu

računalništva v oblaku z infrastrukturnimi storitvami shranjevanja podatkov v podatkovnih

centrih na področju spleta in mobilnih tehnologij. Vse storitve gostujejo na Microsoftovih

strežnikih v oblaku, kar povečuje računsko moč gostujočih aplikacij.

Gradniki platforme Microsoft Azure

Windows Azure za gostovanje in upravljanje storitev, računske operacije,

shranjevanje podatkov in omrežne storitve;


25

storitve Microsoft SQL za širok nabor storitev podatkovnih zbirk in poročanja;

storitve Microsoft .NET – storitvene implementacije konceptov ogrodja .NET

Framework (delovni tokovi in nadzor dostopa);

storitve Live za dosleden način shranjevanja, skupne rabe in sinhronizacije

dokumentov, fotografij, datotek in informacij na osebnih računalnikih, telefonih,

aplikacijah in spletnih straneh;

storitve Microsoft SharePoint in Microsoft Dynamics CRM za poslovne vsebine,

sodelovanje in hiter razvoj rešitev v oblaku [37].

Zasnova storitvene platforme

Platforma Microsoft Azure uporablja namensko prilagojen operacijski sistem, ki temelji na

gručah Microsoftovih podatkovnih centrov, ki upravljajo z računskimi operacijami,

zmogljivostmi računalnikov in viri aplikacij znotraj platforme Azure. Omenjena platforma je

kakor oblačna plast nad številnimi sistemi Windows Server, ki temeljijo na operacijskem

sistemu Windows Server 2008 in uporabljajo prilagojeno verzijo sistema Hyper-V, tj.

Microsoft Azure Hypervisor, katerega naloga je zagotavljanje virtualizacije uporabljenih

storitev [35]. Skalabilnost in zanesljivost delovanja je nadzorovana in upravljana od

Microsoft Fabric Controller, ki skrbi, da se v primeru izpada ali zaustavitve posameznega

podatkovnega strežnika viri, storitve in podatki prenesejo v pomnilnik drugega strežnika.

Tako končnim uporabnikom omogočajo nemoteno delovanje in uporabo storitev in aplikacij.

Microsoft Azure zagotavlja programski vmesnik API, narejen na REST, HTTP in XML, ki

omogoča razvijalcem interakcijo z želenimi storitvami platforme. Microsoft tudi ponuja

končno programsko knjižnico, ki na strani odjemalca zagotavlja vse potrebne funkcije za

interakcijo s storitvami platforme Azure. Platforma Microsoft Azure je integrirana v razvojno

okolje Microsoft Visual Studio, Git in Eclipse. Kot dodatek za upravljanje s storitvami preko

programskega vmesnika API lahko končni uporabniki ali razvijalci upravljajo s storitvami

preko spletnega portala Azure Portal [38]. Portal tako omogoča uporabnikom pregled nad

aktivnimi viri, spreminjanje nastavitev, zagon novih virov in spremljanje podatkov iz aktivnih

virtualnih sistemov in storitev [35].

Cenik uporabe platforme

Platforma Microsoft Azure ponuja širok nabor posameznih storitev ali storitvenih paketov,

ki so različno cenovno vrednoteni. Za potrebe našega raziskovalnega dela smo podrobneje

predstavili cenik za uporabo mobilnih storitev Azure. Možnost uporabe mobilnih storitev


26

platforme Azure je na voljo v treh slojih: Free, Basic, Standard [39]. V Tabela 5.1 je prikazan

razčlenjen pregled storitev, ki so na voljo znotraj posameznega sloja.

Tabela 5.1: Cenik za uporabo storitev platforme Microsoft Azure [39].

FREE BASIC STANDARD

Cena na mesec 0 € 12,64 € 118,05 €

Število klicev API 500.000 1.500.000 15.000.000

Število aktivnih naprav 500 Neomejeno Neomejeno

Število notifikacij push 1.000.000 10.000.000 10.000.000

Sinhronizacija brez povezave Omejeno Podprto Podprto

Izdelava opravil po urnikih Omejeno Podprto Podprto

Vključena količina podatkov v

podatkovni bazi

20 MB 20 MB 20 MB

Varnostno kopiranje Ni podprto Podprto Podprto

Kot je razvidno iz Tabele 5.1, je pri vseh slojih cenikov vključena omejena velikost

podatkovne baze SQL; večja količina podatkov se tako zakupi posebej glede na potrebno

velikost podatkovne baze. Ponudnik v plačljivih cenovnih modelih ponuja različno število

procesorskih virov (6 virov v modelu BASIC in neomejeno število virov v modelu

STANDARD), ter možnost uporabe realno-časovnega sporočanja in uporabo spletnih

vtičnikov. Plačljivi modeli pa prav tako ponujajo neomejen dnevni izhodni prenos podatkov

[39]. Cenovna politika platforme Microsoft Azure omogoča tudi plačevanje storitev po meri,

tako da si lahko posamezni razvijalci svoj cenovni model prilagodijo zgolj glede na potrebne

storitve ali pakete storitev, ki jih potrebujejo. Prav tako je razvijalcem omogočen zakup

različne količine storitev, na primer: storitve vezane na CPU kapacitete, število notifikacij

push, število virov in podobno.

5.2 Google Firebase

Firebase je ponudnik oblačnih storitev na področju zalednih aplikacij. Platforma omogoča

razvijalcem programske opreme številna orodja in produkte, ki lahko uporabijo tekom

razvoja svojih mobilnih in spletnih aplikacij. Osrednji produkt podjetja je podatkovna baza v

realnem času (angl. »real-time database«), ki zagotavlja aplikacijski programski vmesnik, s

katerim lahko razvijalci mobilnih in spletnih aplikacij shranjujejo in sinhronizirajo podatke


27

čez več odjemalcev. Firebase je posledica podjetja Envolve (start-up), ki sta ga začela

Anders Lee in James Tamplin leta 2011. Omenjeno podjetje start-up je v prvi vrsti ponujalo

aplikacijski uporabniški vmesnik, ki je omogočal razvijalcem programske opreme integracijo

spletnih klepetalnic v svoja spletna mesta. Ko je storitev spletne klepetalnice prešla v javno

uporabo, so to razvijalci množično pričeli uporabljati za sinhronizacijo aplikacijskih

podatkov, kot so stanja iger med uporabniki v realnem času. Zaradi uvidene nove poslovne

priložnosti sta Tamplin in Lee ločila storitev spletne klepetalnice z arhitekturo, ki omogoča

storitev v realnem času, in tako ustanovila novo podjetje Firebase, leta 2012 Tega je nato

leta 2014 k sebi priključil gigant Google kot sestavni del platforme Google Cloud [40], katero

pa slednje podjetje predstavlja kot skupek produktov in storitev, ki omogočajo gostovanje,

upravljanje storitev, računske operacije in shranjevanje podatkov ter omogočajo širok nabor

oblačnih storitev, gostovanje razvojnih orodij za razvijalce in podobno [41]. Za izdelavo

mobilnih aplikacij je za razvijalce predvidena obravnavana platforma Firebase z možnostjo

razširitve s paketom storitev Google App Engine. Za potrebe magistrskega dela smo

podrobneje predstavili paket Firebase.

Gradniki platforme Firebase

To so:

Firebase Analyitics predstavlja rešitev spremljanja porabe virov mobilne aplikacije

in druge vrste nadzora;

paket Develop, ki vsebuje storitve obveščanja in pošiljanja sporočil med mobilnimi

ter spletnimi aplikacijami, autorizacijo uporabnikov na strani odjemalca, realno

časovno podatkovno bazo, gostovanje, shranjevanje uporabniških nastavitev ali

datotek, oddaljeno konfiguriranje storitev, konzolo za testiranje in poročila za

pregled napak in drugih informacij;

storitve Glow, ki omogočajo izmenjavo in pošiljanje notifikacij končnim

uporabnikom, operacije indeksiranja trajnih podatkov mobilne aplikacije, nastavitve

vedenja in prikaza mobilne aplikacije za različne mobilne platforme in podobno

[40].

Zasnova platforme Firebase

Kot je bilo povedano v samem opisu, je zaledna storitev Firebase sestavni del platforme

Google Cloud, ki temelji na modelu infrastrukture kot storitev (IaaS). Že od samega začetka

razvoja je delovanje platforme pod vplivom delovanja operacijskega sistema Linux. V

temeljnem sloju (angl. »fundamental layer«) so tako v podjetju Google uporabili svojo


28

prilagojeno različico sistema Linux. V višjih nivojih pa je delovanje pogojeno z Linux KVM

nadzornikom (angl. »Linux KVM hypervisor«), kar omogoča uporabnikom upravljanje

virtualne infrastrukture na različnih operacijskih sistemih Linux kot tudi Windows Server.


Obravnavana platforma Firebase za uporabo storitev ponuja različne storitvene pakete. V

osnovi so na voljo trije sloji: brezplačni Spark, Flame in Blaze. Vsak izmed paketov pa brez

dodatnega plačila vključuje Google Analytics, App Indexing, Authentication, Cloud

Messaging, Crash Reporting, Dynamic Links, Invites, Notifications & Remote Config. V

Tabela 5.2 je prikazan razčlenjen pregled storitev, ki so na voljo znotraj posameznega sloja.

Tabela 5.2: Cenik za uporabo storitev platforme Firebase [42].

SPARK FLAME BLAZE

Cena na mesec 0 € 23,71 € Po uporabi

Število klicev API 20.000 100.000 Po zakupu

Število aktivnih naprav 100 Neomejeno Neomejeno

Število notifikacij push Ni opredeljeno Ni opredeljeno Ni opredeljeno

Sinhronizacija brez povezave Podprto Podprto Podprto

Izdelava opravil po urnikih Ni podprto Ni podprto Ni podprto


podatkovni bazi

20 MB 20 MB 20 MB

Varnostno kopiranje Ni podprto Ni podprto Podprto

Kot je razvidno iz Tabele 5.2, je pri vseh slojih cenikov vključena omejena velikost

podatkovnih baz kakor tudi možnosti uporabe ostalih storitev in funkcionalnosti. V pravilih

uporabe je naveden še pomemben podatek, da je število simultanih povezav omejeno na

10 tisoč. Brezplačni cenovni model obenem ponuja tudi 10 GB izhodnega prenosa podatkov

na dan, v preostalih plačljivih različicah so te vrednosti višje (cenovni model Spark ponuja

50 GB izhodnega prenosa podatkov na dan) ali se plačujejo po zakupu. Za napredne

uporabnike je na voljo cenovni model Blaze, namenjen uporabi po meri, in zajema celoten

nabor ponujenih funkcionalnosti in storitev. Cenovni model Blaze obenem vsebuje

napredne funkcije za varnostno kopiranje, ki v brezplačni in različici Spark nista vključeni

[42]. Plačilo storitev v najvišjem cenovnem modelu Blaze je vezano na dejansko porabo.

Napredni uporabniki si lahko prav tako sestavijo svoj paket glede na potrebe mobilne

rešitve. Kot dodatek ponuja podjetje znotraj uporabe Google Cloud Platform tudi kalkulator


29

uporabe storitev (angl. »Pricing Calculator«), v katerem razvijalci zajamejo predvidevano

uporabo virov in storitev [43]. Za potrebe raziskovalnega dela napredne uporabe in zakupov

storitev s kalkulatorjem nismo podrobneje obravnavali.

5.3 Amazon AWS

Platforma Amazon Web Service (AWS) je storitev podjetja Amazon.com in v splošnem

ponuja širok nabor oblačnih storitev, ki v celoti zagotavljajo učinkovito računalniško

platformo kot storitev (angl. »on-demand platform«) [44]. Začetki uporabe platforme

Amazon segajo v leto 2003, ko sta Chris Pinkham in Benjamin Black predstavila celostno

vizijo za računalniško infrastrukturo, ki bi bila popolnoma standardizirana, avtomatizirana in

bi se v veliki meri zanašala na spletne storitve. Iz teh novih naložb v infrastrukturo sta v

svoji predstavitvi med drugim omenila možnosti ustvarjanja dobička s prodajo virtualnih

strežnikov kot storitev [45].

V letu 2016 ima platforma AWS na voljo preko 70 storitev, ki segajo na področja

podatkovnega skladiščenja, baze podatkov, analitike, uporabniških storitev, področja

uporabniških storitev in še veliko več [44]. Širom uporabljene storitve platforme sta Amazon

Elastic Compute Cloud, poznana pod kratico EC2, in storitev Amazon Simple Storage

Service, poznana pod kratico S3. Ta je namenjena za upravljanje in shranjevanje podatkov

iz mobilnih aplikacij, medtem ko EC2 predstavlja večnamensko in širokopasovno platformo

IaaS. Čeprav podjetju Amazon na področju uporabe zalednih storitev predstavljajo ciljno

tržišče velika podjetja ali korporacije, delujejo na njihovih storitvah naslednji priljubljeni

produkti: Periscope, Yelp, Airbnb, Angry Brids, tinder, Netflix, Clash of Clans, Etry in drugi

[46].

Gradniki storitvene platforme AWS

Storitve AWS niso neposredno izpostavljene končnim uporabnikom, ampak zgolj ponujajo

funkcionalnosti, ki jih lahko razvijalci vključijo v svoje aplikacije. Za potrebe našega

raziskovalnega dela smo v obravnavo vključili paket storitev AWS Mobile, ki so namenjene

razvoju mobilnih aplikacij, in interakcijo z zalednimi storitvami. Storitve so dostopne preko

protokola HTTP z uporabo arhitekturnega načina REST in protokola SOAP. Paket storitev

AWS Mobile vsebuje naslednje komponente:


30

integrirano ogrodje SDK za hiter razvoj mobilnih aplikacij, ki sestavljajo AWS Mobile

SDK, upravljalanje preko AWS Management Console in končne točke za integracijo

s programskim vmesnikom API;

storitve, optimizirane za mobilne aplikacije, ki vključujejo Lambda funkcije, Amazon

Cognito, analitični modul Amazon Mobile Analytics in Amazon SNS Mobile Push

modul za obveščanje push;

mobilno optimizirane povezave sestavljajo Amazon Kinesis Recorder, DynamoDB

Mapper za transformacije podatkov, S3 Transfer Manager, SQS Client in Amazon

SES Client;

sestavni bloki jedra storitev, ki omogočajo računske operacije, operacije za

shranjevane podatkov, omrežne in analitične storitve [47].

Zraven zgoraj predstavljenih blokov AWS Mobile SDK vključuje še programske knjižnice, ki

vsebujejo nizkorazredne vmesnike, funkcije za avtentifikacijo, primere kode in referenčno

dokumentacijo. Med pomembne gradnike spadajo:

Amazon Cognito, ki zagotavlja avtentifikacijo uporabnikov in sinhronizacijo

osnovnih uporabniških podatkov znotraj uporabniških aplikacij;

Amazon S3, ki zagotavlja shranjevanje in sinhronizacijo uporabniških datotek in

drugih podatkov (slike, lastne nastavitve in podobno);

AWS Lambda, ki omogoča razvijalcem mobilnih aplikacij implementacijo lastnih

funkcij, skript ali modulov ter vključevanje teh v interakcijo z zalednimi storitvami;

Amazon DynamoDB predstavlja zmogljivo NoSQL podatkovno bazo za trajno

shranjevanje podatkov;

Amazon Mobile Analytics za spremljanje in analizo različnih metrik znotraj razvite

mobilne aplikacije;

Amazon CloudFront, ki omogoča prenos vsebin v medpomnilnik mobilne naprave

za optimizirano in hitro delovanje mobilne aplikacije [46].

Zasnova platforme AWS Mobile

Platforma AWS je na 13 ločenih geografskih regijah po vsem svetu (večinoma na področju

Amerike, Evrope, severne Azije in Avstralije), pri čemer so pri podjetju napovedali uvedbo

dodatnih petih točk preko leta 2017 [44]. Vsako regijo sestavljajo številni podatkovni centri

za zagotavljanje storitev AWS. Dostop do uporabe storitev je zagotovljen preko

programskih vmesnikov API, do storitev AWS pa je mogoče dostopati še preko vmesnika

REST. Različni gradniki storitev ponudnika Amazon AWS delujejo na operacijskih sistemih

Linux, v večini primerov se za trajno shranjevanje podatkov njihovih storitev uporablja

podatkovna baza podjetja Oracle. Same storitve so implementirane v programskih jezikih

C++, Perl, Mason, Java in Jboss [48].


31


Za razliko od Microsoft Azure, Kinvey ali Backendless se vse storitve pri ponudniku Amazon

računajo glede na porabo virov po principu »koliko porabite, toliko plačate«, vendar se cena

na porabo v zvezi s storitvami razlikuje. Na voljo je tudi 12-mesečna preizkusna različica

AWS Free Tier. V Tabela 5.3 je ponazorjena zajeta količina uporabe mobilnih storitev za

preizkusno različico AWS Free Tier [49].

Tabela 5.3: Zajete mobilne storitve znotraj omejene brezplačne razližice AWS Free Tier [49].

AWS FREE TIER

Cena na mesec 0 €

Število klicev API 1.000.000

Število aktivnih naprav Ni opredeljeno

Število notifikacij push 1.000.000

Sinhronizacija brez povezave Podprto

Izdelava opravil po urnikih Podprto

Vključena količina podatkov v podatkovni bazi 10 GB

Varnostno kopiranje Podprto do 20 GB

Za razliko od preostalih navedenih cenikov iz tega poglavja, kjer so zajete količine vezane

na mesečno porabo, so te enote vezane na celoletno porabo. Pri prekoračitvi porabe ene

določene količine se ta zaračuna po njihovem standardnem ceniku.

5.4 Backendless

Platforma Backendless je storitev istoimenskega podjetja Backendless. Ponuja oblačno

storitev, ki zagotavlja univerzalni backend za razvijalce, ki se ukvarjajo z razvojem mobilnih

in namiznih aplikacij. Pri podjetju navajajo, da gre za tesno integrirani sistem, ki so ga

zasnovali zaradi poenostavitve in pospešitve procesa razvoja mobilnih aplikacij. Izboljšanje

produktivnosti razvijalcev je eden od pomembnejših ciljev in smernic pri razvoju platforme

[50]. Sam začetek razvoja platforme sega v leto 2012. Že marca leta 2013 so pri podjetju

izdali prvo beta verzijo omenjene platforme. Podjetje Backendless je od svojega začetka

prevzelo veliko manj tveganega kapitala od nekaterih konkurentov. Ustanovitelj in direktor


32

Mark Piller je na forumu Backendless support tudi zapisal, da je podjetje na točki

poslovanja, na kateri se lahko samo financira in zato tudi ne potrebuje tujega kapitala [51].

Platforma ponudnika Firebase ponuja številna orodja, kot so razni generatorji kode, grafična

orodja za upravljanje s podatki in oblačnimi razhroščevalniki kode, s katerimi želijo

razvijalcem aplikacij poenostaviti delo in zmanjšati čas potreben za razvoj svojih aplikacij.

Razvijalcem v veliki meri ni treba skrbeti za programsko logiko na strani strežnika, tako se

lahko toliko bolj osredotočajo na vidik končnega odjemalca. Platforma sicer ponuja različne

programske vmesnike, s katerimi lahko aplikacije dostopajo do samega zaledja platforme

Backendless. Ti vmesniki so vključeni znotraj paketa SDK, ki je na voljo za različne jezike

(Android, iOS, Mac OS X, JavaScript, .NET, Unity3D, PHP in ActionScript) [50].

Gradniki platforme

Individualni deli oziroma produkti platforme naslavljajo različne potrebe za razvoj mobilnih,

spletnih ali drugih poslovnih aplikacij. Backendless združuje svojo ponudbo produktov v

celovito platformo, ki sestavlja storitev mBaaS, spletno gostovanje storitev, imenovano

Backendless Hosting, storitev API Engine in spletno tržišče backend storitev Marketplace

[50] [52] [53].

Gradniki so:

Storitev Backendless MBaaS – Predstavlja skupek integriranih storitev, ki so

osnova platforme Backendless.

Storitev Backendless Hosting – Backendless v sklopu svojih SDK-jev ponuja

okolje za shranjevanje podatkov, pri čemer podpira statično in dinamično

(Node.js) vsebino. Vsebuje različne programske vmesnike za učinkovito

upravljanje podatkov. Vse operacije, povezane s shranjevanjem podatkov, so

dostopne preko namenske konzole, preko katere je moč poljubno vsebino

nalagati, brisati, spreminjati, dodeljevati različne pravice in drugo.

Storitev Backendless API Engine – S storitvijo Backendless API Engine je moč

pretvoriti poljubno programsko kodo v lastno mikrostoritev s svojim vmesnikom

API. Sistem za to storitev avtomatsko generira nov SDK kot tudi vmesnik

REST API in preostalo dokumentacijo. Platforma tudi priskrbi okolje za

dodatno testiranje teh mikrostoritev, ki jih lahko razvijalci pozneje vključijo v

svoje aplikacije.

Spletna trgovina Backendless Marketplace – Spletna trgovina Backendless

Marketplace je del platforme Backendless, kjer se nahajajo vsi produkti in


33

storitve, ki jih lahko razvijalci vključijo v svoje aplikacije, s tem pa obogatijo

njeno delovanje in izboljšajo zaledje (angl. »backend«).

Zasnova plaftorme

Platforma Backendless je na voljo v treh različnih nivojih [54]:

Nivo Backendless Cloud

Je najosnovnejši nivo, v okviru katerega uporabniki dostopajo do centralizirane platforme

na strežnikih podjetja Backendless. Ta nivo zajema že vnaprej konfigurirane nastavitve, kjer

si več aplikacij različnih razvijalcev deli razpoložljive vire ene instance Backendless. Pri

podjetju zagotavljajo, da so viri med seboj primerno izolirani, tako da določena aplikacija ne

more dostopati do datotek drugih aplikacij. Ta različica platforme je na voljo v treh različnih

cenovnih kategorijah (brezplačna uporaba, Cloud9 in Cloud99), pri čemer ima vsaka

kategorija določene omejitve pri vključenih storitvah in količini podatkov.

Nivo Backendless Managed

Pri omenjenem načinu gre za podobno arhitekturo in naborom vsebovanih storitev kot pri

nivoju Backendless Cloud, vendar pri tem nivoju ni omejitev uporabe zalednih storitev

(neomejena količina prostora, klicev API, število obvestil push idr.). Instanca Backendless

je pri tem nivoju na voljo v popolnoma izoliranem okolju, tako da se računalniški viri ne delijo

z drugimi aplikacijami in so tako v celoti razpoložljivi le eni aplikaciji oziroma uporabniku. Za

razliko od nivoja Backendless Cloud, ki ima različne cenovne kategorije, se pri tem nivoju

zaračunava glede na porabo. Cena se določi glede na število zahtev klicev API in

porabljene količine podatkov.

Nivo Backendless Standalone

Nivo Standalone ponuja platformo Backendless kot celoto, ki jo lahko razvijalci prenesejo

in jo namestijo lokalno ali pa jo celo po želji namestijo pri katerem drugem ponudniku

oblačnih storitev (na primer Google Cloud, Amazon ali Azure). Pri tem nivoju velja, da

platforma nima omejitev glede prostora in storitev, pri čemer so dodatno vključeni podpora

24/7, servis in nadzor pravilnega delovanja.


Platforma Backendless je na voljo kot brezplačno okolje, ki ga lahko namesti podjetje na

svoje sisteme in razpoložljive računalniške vire [52]. Prav tako je na voljo omejena

brezplačna ali plačljiva razširjena različica mobilne platforme. Platforma Backendless Cloud

na voljo v treh različnih cenovnih kategorijah – ima možnost brezplačne uporabe in možnost


34

plačljivih razširitvenih različicah Cloud9 in Cloud99. V Tabela 5.4 je prikazan razčlenjen

pregled storitev, ki so na voljo znotraj posameznega sloja.

Tabela 5.4: Cenik uporabe storitev platforme Backendless [52].

FREE Cloud9 Cloud99 Enterprise

Cena na mesec 0 25 99 Po dogovoru

Število klicev API 300 600 1200 Neomejeno

Število aktivnih naprav 1 5 Neomejeno Neomejeno

Število notifikacij push 100.000 500.000 1.000.000 Neomejeno

Sinhronizacija brez povezave Ni podprto Ni podprto Ni podprto Ni podprto

Izdelava opravil po urnikih Podprto Podprto Podprto Podprto


podatkovni bazi

5 GB 10 GB 20 GB Neomejeno

Varnostno kopiranje Ni podprto Ni podprto Ni podprto Ni podprto

Kot je razvidno iz Tabele 5.4, ima vsaka cenovna kategorija oziroma model določeno

omejitev glede pomembnih storitev znotraj posamezne cenovne različice. Pri tem so glede

na različen cenovni model omejeni tudi velikosti podatkovne baze in število podatkovnih

tabel. Cenovna politika pri platformi Backendless je naravnana na način, da se v primeru

večjih potreb po le določeni uporabi storitve ali drugih virov ta tudi dodatno dokupi,

konkretno na primeru; v trgovini Backendless Market lahko dokupimo lahko zgolj število

klicev API na minuto oziroma le število notifikacij push, seveda pa je moč dokupiti več

storitev hkrati. Takšna razširitev določene omejitve je mogoča z dokupom oziroma

funkcijskega paketa (angl. »function pack«) na spletnem tržišču Marketplace, vendar je

mogoča le pri plačljivih cenovnih kategorijah [52].

5.5 Kinvey

Podjetje Kinvey je ponudnik zalednih storitev na področju oblačnih storitev. Podjetje je pionir

na področju ponudbe mobilnih zalednih storitev [55]. Ustanovljeno je bilo leta 2010. Po

velikosti sodi med tista z 11 do 50 zaposlenimi [56]. Podjetje zagotavlja razvijalcem

standardizirano, skalabilno in varno okolje za izdelavo domorodnih, spletnih ali mobilnih

aplikacij. Njihova platforma zalednih storitev ponuja razvijalcem mobilno orientirane storitve,

kot so shranjevanje podatkov, shranjevanje datotek, uporaba notifikacij push, analiza


35

mobilnih aplikacij, možnosti izdelave poslovne logike po meri in integracije naravnosti iz

škatle (angl. »out-of-the-box«) z različnimi oblačnimi storitvami. Prav tako podjetje

zagotavlja varnostne algoritme za enkripcijo shranjenih podatkov.

Gradniki platforme Kinvey

Ciljna skupina uporabnikov zalednih storitev platforme Kinvey so tako posamezni razvijalci

kot tudi večja podjetja, kajti uporabnikom omogoča [57]:

uporabo navzkrižno-platformskih knjižnic (angl. »cross-platform«) z možnostjo

medpomnjenja v načinu brez povezave;

dostop do s požarnim zidom zaščitenih podatkov preko vmesnika API;

avtentifikacijo uporabnikov na podlagi več identifikacijskih sistemov, kot so

LDAP in OAuth;

enkripcijske protokole, ki skrbijo za varovanje podatkov na spletu in posamezni

napravi;

uporabo funkcij, kot so notifikacije push in možnosti povezave do zunanjih

storitev;

uporabo analitičnih orodij za upravljanje in nadzor nad večjim številom mobilnih

aplikacij.

Zgoraj navedene storitve so naravnane, da bi razvijalcem omogočile enostavno integracijo,

obenem pa omogočile razvijalcem jasen pregled nad upravljanjem mobilnih aplikacij.

Zasnova platforme Kinvey

Rešitev Kinvey mBaaS temelji na asinhroni arhitekturi I/O, ki jo zagotavljata NGINX in

node.js. Za optimalno delovanje uporabe zalednih storitev ponudnika Kinvey skrbijo

naslednji protokoli in rešitve [58]:

platforma kot storitev (PaaS), ki skrbi za poslovno logiko samega celovitega

sistema;

REST/SOAP programski vmesniki API;

protokoli za avtorizacijo Auth/IAM;

upravljanje s programskimi vmesniki API;

oblačne storitve, ki preko uporabe zalednih storitev podjetja Kinvey skrbijo za

upravljanje z notifikacijami push, geolociranjem, analizo in povezave s

socialnimi omrežji;


36

sistemi podjetja Kinvey, zadolženi za shranjevanje podatkov, upravljanje z

omrežjem, CRM/EPS/CMS sistemi in podobno.


Platforma Kinvey ima podobno kot platforma Microsoft Azure različne cenovne sloje:

Developer, Startup, Business, Enterprise [59]. V Tabela 5.5 je ponazorjen razčlenjen

pregled storitev, ki so na voljo znotraj posameznega sloja.

Tabela 5.5: Cenik za uporabo storitev platforme Kinvey [59].

DEVELOPER STARTUP BUSINESS ENTERPRISE

Cena na mesec 0 € 178,05 € 1780,63 € Po dogovoru

Število klicev API 1.000 100.000 100.000 Neomejeno

Število aktivnih naprav 1.000 100.000 100.000 Neomejeno

Število notifikacij push Ni podatka Ni podatka Ni podatka Ni podatka

Sinhronizacija brez

povezave

Podprto Podprto Podprto Podprto

Izdelava opravil po

urnikih

Podprto Podprto Podprto Podprto

Vključena količina

podatkov v podatkovni

bazi

1 GB 10 GB 30 GB 500 GB

Varnostno kopiranje / / Podprto Podprto

Kot je razvidno iz zgornje tabele, so cenovni modeli ponudnika Kinvey podobni ceniku

storitev platforme Microsoft Azure. Cenovni model Enterprise omogoča tudi plačevanje

storitev po meri, pri čemer si lahko večja podjetja ali korporacije cenovni model prilagodijo

zgolj glede na potrebne storitve ali pakete storitev. Vsi cenovni sloji imajo vključeno osnovno

podporo, zadnja dva cenovna sloja omogočata tudi varnostno kopiranje podatkov, instantno

podporo po telefonu, možnost zavarovanja in podobno. Cenovna politika ponudnika Kinvey

ne predvideva, da bi lahko razvijalci preostalih cenovnih slojev imeli možnost dodatnega

zakupa različne količine shranjenih podatkov, enot CPU ali drugega.


37

6 NAČRT ZA PRIMERJAVO PONUDNIKOV ZALEDNIH STORITEV

Na podlagi problematike, predstavljene v uvodnem poglavju, smo v našem raziskovalnem

delu v sklopu pregleda literature pridobili osnovno znanje o delovanju zalednih storitev in

načinih implementacije in povezljivosti [28]. Na podlagi pridobljenega znanja iz pregleda

literature smo izdelali namensko mobilno aplikacijo po principu trislojne arhitekture. Za

dostop do zalednih mobilnih storitev smo uporabili vnaprej pripravljene programske

knjižnice SDK izbranih ponudnikov. Z namenom, da bi pridobili odgovore še na preostala

raziskovalna vprašanja, smo za potrebe merjenja performančnih zmogljivosti dodelali

mobilno aplikacijo do te mere, da beleži čas dostopa in izvedbe posamezne storitve. Glede

na pridobljene empirične podatke smo v naslednjem poglavju izbrane ponudnike primerjali.

6.1 Izdelava namenske aplikacije

Da bi lahko pridobili odgovore, vezane na eksperimentalni del raziskovalnih vprašanj, smo

morali zagotoviti enoten sistem vrednotenja. Zato smo izdelali projekt mobilne aplikacije, ki

iz izbrane naprave omogoča interakcijo s storitvami obravnavanih ponudnikov preko

programskega vmesnika API. Aplikacija je namenjena testiranju na operacijskem sistemu

Android 4.2.2. Razvita je v programskem jeziku Java v razvojnem okolju Android Studio

1.5. Aplikacija je modificirana različica lastno razvite mobilne aplikacije za podporo

daljinskemu naročanju v gostinstvu, kjer lahko končni uporabnik (v tem primeru natakar)

sprejema in oddaja naročila gostov, pa tudi izdela račune pri mizi same stranke v

gostinskem poslopju. Kot je bilo omenjeno v začetku poglavja, je mobilna aplikacija

modificirana do te mere, da beleži časovne vrednosti dostopa in izvršitve posamezne

interakcije s storitvijo ponudnika storitev BaaS, obenem pa lahko znotraj enega zagona

komunicira s storitvami vseh obravnavanih ponudnikov zalednih storitev. Da bi zagotovili

konsistentnost in točnost rezultatov, smo pripadajoče primerjalne procedure znotraj razvite

mobilne aplikacije testirali v enakem okolju na mobilnem telefonu Samsung Galaxy S4. Z

namenom, da bi zagotovili veljavnost podatkov, smo pri integraciji uporabe zalednih storitev

obravnavanih ponudnikov za poslovno logiko in podatkovne objekte uporabili enako

programsko kodo. Da bi se izognili tveganju zaradi ne odzivanja ali preobremenjenosti

mobilne naprave za testiranje, smo omenjeno napravo predhodno ponastavili na tovarniške

nastavitve in onemogočili vsa odvečna opravila in procese. Da bi se izognili motnjam


38

omrežja s strani preostalih naprav in zagotovili čim bolj natančne ter verodostojne rezultate,

smo napravo za testiranje, povezali na namensko dostopno točko, ki je bila skozi proces

integracije in poznejšega pridobivanja rezultatov vedno v ločenem prostoru skupaj z

mobilno napravo na vedno enaki razdalji. Na Slika 6.1 je prikazan razredni diagram, iz

katerega so razvidni tako atributi kakor tudi relacije med posameznimi objekti.

Slika 6.1: Predviden razredni diagram naše mobilne aplikacije.

Če je bilo mogoče, smo pri implementaciji dostopa do storitev za različne ponudnike

uporabili enake podatkovne tipe posameznih atributov. Prav tako smo pri vseh ponudnikih

izdelali podatkovno bazo z enakimi podatkovnimi tabelami in atributi. Če je bilo mogoče,

smo pri vseh ponudnikih izbrali entitetno-relacijsko podatkovno bazo SQL.

6.2 Izdelava primerjalnega modela

Z namenom, da bi pridobili podatke o performančnih zmogljivostih klica posameznih storitev

izbranih ponudnikov, smo izdelali različne primerjalne procedure. Pri vrednotenju

posameznega ponudnika zalednih storitev nas je zanimalo naslednje:


39

povprečen čas dostopa izvedene primerjalne procedure 1 (Tabela 6.1) po treh

zaporednih ponovitvah;

povprečen čas dostopa izvedene primerjalne procedure 2 (Tabela 6.2) po desetih


povprečen čas dostopa izvedene primerjalne procedure 3 (Tabela 6.3) po desetih


pregled velikosti posamezne podatkovne baze ponudnika, po končanih desetih

primerjalnih procedurah;

možnost izdelave lastnih operacij znotraj storitev posameznega ponudnika;

možnost dela in interakcija s storitvami posameznega ponudnika storitev BaaS

brez povezave.

Naslednje tabele prikazujejo načrt izvedbe primerjalnih procedur, s katerimi smo pridobili

odgovore na tretje, peto in šesto raziskovalno vprašanje.

Tabela 6.1: Načrt za izvedbo primerjalne procedure 1.

Zaporedna številka operacije Opis operacije

1. Pregled shranjenih prodajnih artiklov

2. Brisanje vseh prodajnih artiklov v bazi

3. Vstavljanje novih 45 prodajnih artiklov

Znotraj prve primerjalne procedure nas je zanimalo branje večje količine podatkov (vseh

zapisov v podatkovni tabeli). Po uspešnem branju in transformaciji podatkov v podatkovne

objekte se izvede brisanje vseh podatkov iz podatkovne tabele prodajalnih artiklov. Po

končani operaciji se izvede vstavljanje novo generiranih zapisov.



1. Pregled shranjenih prodajalcev

2. Iskanje prodajalca po identifikacijski številki, ki ni

indeksirana


40

3. Iskanje prodajalca po identifikacijski številki, ki je

indeksirana

Kot je razvidno iz zgornje tabele, smo pri drugi primerjalni operaciji najprej naložili vse

shranjene zapise iz tabele prodajalcev, nato smo pa izvedli še klic iskanja podatka iz iskanja

po ne indeksiranem atributu in pretvorbo iz podatkovnega zapisa iz tabele. V tretjem koraku

smo prav tako izvedli iskanje, vendar smo tokrat iskali po indeksiranem ključu. Znotraj

tretjega koraka je zajeta še transformacija iz zapisa v tabeli podatkovne baze v objekt

znotraj mobilne aplikacije.



1. Kreacija nove mize ob prihodu stranke v gostinsko

poslopje

2. Sprejem naročila s štirimi postavkami prodajnih

artiklov

3. Oddaja naročila

4. Dopolnitev naročila mize s štirimi novimi postavkami

prodajnih artiklov

5. Preklic naročila prve postavke prodajnih artiklov

6. Zaključek naročila in izdelava računa

Pri zadnji operaciji gre za kompleksnejšo operacijo shranjevanja in posodabljanja podatkov,

kajti gre za shranjevanje entitete z relacijo ena proti mnogo in drugimi referencami. Kakor

je razvidno iz zgornje tabele, se v prvem koraku izvrši storitev shranjevanja podatkovnega

zapisa, v drugem koraku modificira in v tretjem posodobi. V četrtem koraku se po

indeksiranem ključu podatek preko klica storitve ponovno naloži v pomnilnik mobilne

aplikacije in transformira v podatkovni objekt, sledi dodatna sprememba objekta in poznejši

klic storitve za posodobitev podatkovnega zapisa.

Da bi v eksperimentalnem delu raziskovalne naloge dobili čim bolj točne in relevantne

rezultate, smo vsako operacijo večkrat ponovili, vse meritve beležili in na koncu upoštevali

povprečni čas. Enako smo kot dodatek znotraj integracije vsakega ponudnika po končanih

meritvah preverili velikost nastale podatkovne baze.


41

6.3 Integracija v Microsoft Azure

Zaledne storitve Mobile Apps so sestavni del paketa storitev Azure App Service. Mobile

App ponujajo visoko skalabilno, globalno dosegljivo ogrodje za razvoj mobilnih aplikacij

različnih nivojev in potreb uporabnikov kot tudi razvijalcev. Uporaba zalednih storitev Mobile

Apps tako razvijalcem omogoča [60]:

razvoj domorodnih (angl. »native«) in navzkrižno-platformnih aplikacij (angl. »cross

platform apps«);

povezljivost do sistemov v podjetju;

razvoj aplikacij, ki delujejo tudi brez načina povezave (angl. »offline-ready apps«);

pošiljanje obvestil push.

Z razvojnim ogrodjem Azure Mobile App pridobimo programske knjižnice, ki zagotavljajo

avtentifikacijo in avtorizacijo posameznih uporabnikov mobilne aplikacije ali razvijalcev.

Pridobimo tudi dostop do trajnega shranjevanja podatkov, pri katerih lahko uporabljamo

tradicionalno relacijsko podatkovno bazo kot tudi podatkovno bazo NoSQL. Znotraj ogrodja

so knjižnice s programskimi vmesniki API za možnost implementacije načina delovanja

mobilne aplikacije v načinu brez povezave kakor tudi vmesniki za pošiljanje notifikacij push.

Za potrebe našega raziskovalnega dela smo uporabili Free-različico računa za razvijalce.

Tako smo pridobili pravico do 30-dnevne brezplačne uporabe storitev Microsoft Azure

skupaj z bonitetami v vrednosti 188 evrov za porabo preostalih podatkovnih virov in storitev.

Razvojno ogrodje Azure Mobile App Client SDK za Android vsebuje:

programske knjižnice – to so razredi za dostop do vmesnikov spletnih storitev,

razredi za avtentifikacijo, dostop do podatkov, pošiljanje obvestil push in delo v

načinu brez povezave in podobno;

dokumentacijo – to je referenčna dokumentacija za razvojno okolje AWS Mobile

SDK, vezana na operacijski sistem Android.

Znotraj portala Azure smo morali ustvariti mobilno aplikacijo, ki smo jo uporabili za namene

testiranja in zgoraj opisanih primerjalnih procedur. Pri kreiranju mobilne aplikacije smo

morali kreirati tudi lokacijsko določene podatkovne vire. Platforma Azure je razmeščena na

različnih geografskih regijah širom sveta, večinoma na področju Amerike, Evrope, severne

Azije in Avstralije. Za optimalno delovanje naše mobilne aplikacije in hitro časovno

dostopnost smo izbrali strežnik s podatkovnimi viri v Evropi. Prav tako je treba pri izdelavi

mobilne aplikacije izbrati načrt stroškovnega financiranja v primeru uporabe dodatnih,


42

nezakupljenih podatkovnih virov oziroma procesorskih enot. Kot omenjeno, smo za potrebe

našega raziskovalnega dela izbrali brezplačni načrt, omejen na 30 dni uporabe. Na Slika

6.2 je prikazana osnovna stran portala naše mobilne aplikacije limeOrder po končani

namestitvi.

Slika 6.2: Nadzorna plošča portala Azure, iz katerega je razvidno novo ustvarjeno zaledje

namenske aplikacije limeOrder.

Po končani vzpostavitvi mobilne aplikacije na portalu Azure smo vzpostavili začetno

integracijo z razvojnim ogrodjem Azure Mobile Client SDK za operacijski sistem Android.

Pri integraciji je razvijalcem na voljo tudi namenski čarovnik, preko katerega lahko na

podlagi želenih parametrov, potrebnih za delovanje mobilne aplikacije, samodejno izdelamo

projekt mobilne aplikacije s predhodno vključenimi referencami in programskimi knjižnicami

za dostop do zalednih storitev Azure. Znotraj samodejno generiranega projekta mobilne

aplikacije je vključena tudi funkcionalna programska koda, ki znotraj začetne aktivnosti

razvijalcem nazorno prikazuje interakcijo s storitvami dostopa do vnosa in branja podatkov

iz podatkovne baze. Predhodno omenjen čarovnik poskrbi, da so znotraj nastalega projekta

že vključeni avtentifikacijske številke in nizi, ki pri interakciji dovoljujejo uporabo dostopa do

spletnih storitev. Prav tako imajo razvijalci pri procesu vnosa nastavitev in želenih


43

parametrov za izdelavo začetnega projekta mobilne aplikacije preko čarovnika, čarovnik v

izdelan projekt, možnost izdelave entitetno-relacijske podatkovne baze, ki jo obravnavani

čarovnik pozneje preko niza podatkovne povezave samodejno vključi v kreiran projekt.

Razvijalci imajo možnost ročne integracije programskih knjižnic do zalednih storitev Azure

v obstoječi projekt mobilne aplikacije. V tem primeru je znotraj projekta treba ročno vključiti

potrebne programske knjižnice, vendar je uporaba čarovnika za samodejno kreacijo

projekta priporočljiva zlasti razvijalcem, ki se prvič srečujejo z integracijo zalednih mobilnih

storitev. Na Slika 6.3 je ponazorjen del programske kode, potreben za integracijo

omenjenega razvojnega ogrodja v projekt naše mobilne aplikacije.

Slika 6.3: Vključitev knjižnic razvojnega ogrodja Azure Mobile Client SDK v projekt

mobilne aplikacije.

Kot omenjeno, portal Azure omogoča izdelavo začetnega projekta mobilne aplikacije preko

čarovnika. S čarovnikom lahko razvijalci tudi izdelajo začetno podatkovno bazo. Za potrebe

izvršitve eksperimentalnega dela magistrskega dela smo morali našo začetno podatkovno

bazo z imenom limeDatabase nadgraditi z namenskimi tabelami in atributi. Razvijalci imajo

možnost urejanja podatkovne baze na samem portalu Azure, prav tako pa je dopuščena

možnost za urejanje podatkovne baze v Microsoft SQL Server Management Studio (SSMS)

ali drugi aplikaciji, ki je povezljiva s podatkovno bazo Microsoft SQL. Za proces izdelave

smo uporabili SQL Server Object Explorer znotraj razvojnega okolja Microsoft Visual Studio

Community Edition 2013. Kot je omenjeno, se za trajno shranjevanje podatkov pri uporabi

zalednih storitev Azure uporablja entitetno-relacijska podatkovna baza ali podatkovna baza

NoSQL. V našem primeru smo uporabili relacijsko podatkovno bazo SQL in znotraj

omenjenega orodja z ukazi Transcript-SQL (T-SQL) izdelali tabele s potrebnimi atributi.

Znotraj nastale podatkovne baze se samodejno kreirajo naslednji atributi:


44

id – predstavlja primarni ključ zapisa v tabeli;

createdAt – predstavlja časovni zapis, kdaj je bil zapis vnesen;

updatedAt – predstavlja časovni zapis, kdaj je bil zapis nazadnje spremenjen;

deleted – predstavlja logični zapis v primeru brisanja zapisa iz podatkovne tabele.

Omenjeni atributi se za posamezen zapis v podatkovni tabeli tudi samodejno kreirajo in

posodobijo. Znotraj uporabe podatkovne baze bi želeli izpostaviti, da se v primeru izvršitve

storitve brisanja iz podatkovne tabele sam zapis ne izbriše. V primeru brisanja zapisa se

spremeni zgolj atribut deleted na pozitivno logično vrednost, medtem je ta izbrisan zapis pri

klicu storitev nalaganja podatkov iz podatkovne baze ignoriran. Na Slika 6.4 je prikazana

izdelava podatkovne tabele v skriptnem jeziku T-SQL znotraj orodja SQL Server Object

Explorer.

Slika 6.4: Izdelava tabele v skriptnem jeziku T-SQL.

Pri uporabi razvojnega ogrodja Azure Mobile Client SDK znotraj klica procedur za

shranjevanje ali nalaganje zapisov v podatkovni tabeli uporablja format JSON. V razvojno

ogrodje je vključena razširitev GSON za pretvorbo zapisov v tabeli v objekte znotraj naše

aplikacije ali obratno. Za samodejno serializacijo ali deserializacijo je znotraj objektov


45

razvijalcem treba definirati notacije. Slika 6.5 prikazuje primer uporabe notacij. Če

posameznega atributa v programski kodi ne označimo s potrebno notacijo, se ta ne

prenese. Kot je omenjeno, se pri izdelavi podatkovne baze kreirajo dodatni atributi, teh pa

pri razvoju mobilen aplikacije ni potrebno uporabiti.

Slika 6.5: Uporaba notacij za transformacijo podatkov v podatkovni bazi Microsoft SQL.

Po kreaciji podatkovnih tabel in pripadajočih atributov v podatkovni bazi SQL smo v

programski kodi projekta mobilne aplikacije vzpostavili povezavo za dostop do zalednih


46

storitev Azure. Na Slika 6.6 lahko vidimo del programske kode v mobilni aplikaciji za

pridobitev uporabe storitev Azure znotraj naše mobilne aplikacije.

Slika 6.6: Avtentifikacijo do storitev Azure.

Za uporabo storitev za delo in shranjevanje podatkov preko podatkovne baze in drugih

klicev zalednih storitev Azure je potrebna uporaba asinhronih opravil. Pri implementaciji

operacij za doseg meritev v eksperimentalnem delu našega magistrskega dela smo naleteli

na težave pri pridobitvi podatkov iz objektov, ki vsebujejo povezave preko tujih ključev do

druge podatkovne tabele z relacijo ena proti mnogo. Omenjena razširitev GSON, ki skrbi

za samodejno pretvorbo zapisov v podatkovni tabeli v programske objekte, deluje zgolj na

zapisih iz podatkovnih tabel brez sklicevanja na zapise v drugi podatkovni tabeli. V ta

namen smo morali za pretvorbo objektov v želeni zapis iz podatkovne tabele izdelati lastne

pretvornike na podlagi razširitve pretvornikov JSON. Na Slika 6.7 vidimo implementacijo

namenskega pretvornika za pretvorbo zapisov iz referenčne podatkovne tabele.


47

Slika 6.7: Implementacija serializacije za referenčne zapise v drugi podatkovni tabeli.

Prav tako smo po implementaciji namenskih pretvornikov znotraj zagona naše mobilne

aplikacije morali omenjene pretvornike registrirati. Na Slika 6.8 opazimo vključitev in

registracijo implementiranega vmesnika za pretvorbo zapisov.

Slika 6.8: Registracija implementiranega vmesnika za pretvorbo referenčnih zapisov.

Uporaba zalednih mobilnih storitev Azure omogoča razvijalcem razvoj mobilne aplikacije,

ki deluje v načinu brez povezave. Znotraj programskih knjižnic za dostop do storitev Azure

je vključena možnost uporabe shranjevanja ali nalaganja podatkov, tudi v primeru, kadar

znotraj mobilne aplikacije ni neposrednega dostopa do storitev Azure. V tem primeru se

zapisi za ažuriranje shranijo v medpomnilnik mobilne aplikacije in se posodobijo ob


48

naslednji uspešni vzpostavitvi povezave s storitvami Azure. Na Slika 6.9 je prikazano

implementirano opravilo, ki skrbi za naknadno sinhronizacijo podatkov v primeru, kadar je

neposredna povezava s storitvami Azure onemogočena.

Slika 6.9: Del programske kode, ki skrbi za naknadno sinhronizacijo podatkov.

Po končani implementaciji smo pričeli z merjenjem rezultatov z zagonom posameznih

primerjalnih procedur.

6.4 Integracija v Google Firebase

Kot je bilo omenjeno v sami predstavitvi obravnavanega ponudnika zalednih storitev, je

Firebase sestavni del platforme Google Cloud. Razvijalcem ponuja nabor orodij za razvoj

visokokakovostnih mobilnih aplikacij. Znotraj uporabe zalednih storitev Firebase imajo

razvijalci možnost za uporabo naslednjih paketov storitev:


49

Google Analytics – pregled in analiza delovanja mobilne aplikacije;

Develop – omogoča razvoj mobilne aplikacije, uporabo sporočil, avtentifikacije

uporabnikov, uporabo realno časovne podatkovne baze, uporabo podatkovnega

prostora v oblaku, gostovanje in laboratorij za testiranje;

Grow – uporaba notifikacij, konfiguracije oddaljenega dostopa, indeksiranje

prometa mobilnih aplikacij, uporabo AdWords in drugo;

Earn – uporaba monetizacije znotraj razvite mobilne aplikacije.

Za potrebe našega raziskovalnega dela smo uporabili brezplačen račun za razvijalce za

dostop do zalednih storitev Firebase. Kot omenjeno pri opisu ponudnika zalednih storitev,

brezplačna različica omogoča omejeno uporabo zalednih storitev kakor tudi omejeno

količino prenosov in velikosti za trajno shranjevanje podatkov. Po uspešni registraciji smo

na portalu Firebase ustvarili nov projekt. Slika 6.10 prikazuje osnovno stran portala naše

mobilne aplikacije po končani namestitvi.

Slika 6.10: Nadzorna plošča portala Firebase, iz katerega je razvidno novo ustvarjeno zaledje



50

Po končani namestitvi mobilne aplikacije na portalu za razvijalce Firebase smo vzpostavili

začetno integracijo z razvojnim ogrodjem Firebase SDK za operacijski sistem Android. Za

delovanje zalednih storitev ponudnika Firebase smo morali znotraj razvojnega okolja

Android Studio, preko upravljalnika razvojnih ogrodij (angl. »Android SDK Manager«),

namestiti repozitorij storitev Google (angl. »Google Repository«). V primeru uporabe

razvojnega okolja Android Studio 2.2 je na voljo posebno razvito orodje z nazivom asistent

Firebase (angl. »Firebase Assistant«). Omenjeno orodje omogoča razvijalcem, da preko

čarovnika in vnosa želenih parametrov ter identifikacijske številke mobilne aplikacije na

portalu Firebase samodejno ustvari reference in prenese potrebne programske knjižnice v

projekt mobilne aplikacije. Zaradi konsistentne uporabe in dosega relevantnih rezultatov

merjenja pri izvršitvi primerjalnih procedur smo tudi pri integraciji zalednih storitev

ponudnika Firebase uporabili starejšo različico razvojnega okolja Android Studio 1.5, v

katerem še uporaba asistenta Firebase ni bila implementirana. V ta namen smo morali

ročno prenesti potrebne programske knjižnice in znotraj konfiguracijskih datotek nastaviti

potrebne reference. Na Slika 6.11 lahko vidimo del programske kode, ki je potreben za

integracijo omenjenega razvojnega ogrodja v projekt naše mobilne aplikacije.

Slika 6.11: Vključitev knjižnic razvojnega ogrodja Firebase SDK v projekt mobilne

aplikacije.


51

Po uspešni integraciji, ki zagotavlja dostop do uporabe zalednih storitev ponudnika

Firebase, smo izdelali podatkovno bazo. Za trajno shranjevanje podatkov pri uporabi

zalednih storitev je na voljo dokumentno orientirana podatkovna baza NoSQL. Znotraj

portala za razvijalce Firebase je mogoče zgolj izdelati podatkovno bazo, podatki pa se

kreirajo znotraj interakcije uporabe storitev s podatkovno bazo. Uporaba podatkovne baze

Firebase je omejena na pravice posameznih končnih uporabnikov mobilne aplikacije ali

razvijalcev. V namen izdelave mobilne aplikacije smo definirali pravila dostopa tako, da ima

vsak uporabnik mobilne aplikacije možnost branja, spreminjanja in dodajanja zapisov v

podatkovno bazo. Na Slika 6.12 je ponazorjena nastavitev pravic za uporabo podatkovne

baze.

Slika 6.12: Slika prikazuje nastavitev pravil dostopa do podatkovne baze.

Kot omenjeno, se za trajno shranjevanje podatkov uporablja podatkovna baza NoSQL, zato

se podatki iz objektov v mobilni aplikaciji samodejno shranjujejo in pretvorijo v želeni zapis

v podatkovni bazi, prav tako za atribute znotraj podatkovnih objektov ni predvidena uporaba

notacij. Znotraj izvršitve funkcij dostopa do podatkovne baze se za prenos podatkov

uporablja format JSON, enako se podatki samodejno transformirajo iz zapisa v formatu

JSON v podatkovni objekt znotraj mobilne aplikacije. Za omenjeno transformacijo skrbi

referenčna knjižnica GSON. Podatkovna baza ponudnika Firebase ne generira primarnega

ključa samodejno, tako da smo v ta namen morali implementirati ročno generacijo UUID

primarnega ključa.


klicev zalednih storitev ponudnika Firebase je potrebna uporaba in implementacija

poslušalcev, ki ob končani interakciji s podatkovno bazo vrnejo želen rezultat ali obvestilo

o prekinitvi. Za preprosto uporabo vnosa posameznega zapisa ali branja in nalaganja v

seznam na grafičnem vmesniku končnega uporabnika je uporaba poslušalcev zelo


52

preprosta. Znotraj našega primera, v okviru katerega je bilo treba uporabiti kompleksnejšo

poslovno logiko, pa je postopek implementacije za razvijalce zelo zamuden in nepregleden.

Na Slika 6.13 vidimo del programske kode, pri čemer smo za klic posamezne funkcije za

dostop do zalednih storitev uporabili implementacijo poslušalca.

Slika 6.13: Interakcija z zalednimi storitvami ponudnika Firebase.


53

Ponudnik zalednih storitev omogoča tudi avtomatsko izdelavo varnostnih kopij podatkov, ki

jo lahko razvijalci vključijo v proceduro programske kode. Ponudnik zalednih storitev

Firebase med drugim omogoča delo v načinu brez povezave do storitev. Pri tem imajo

razvijalci možnost implementacije različnih poslušalcev, ki zajemajo upravljanje s shrambo

v načinu brez povezave, možnostmi pravil medpomnjenja v primeru zrušitve mobilne

aplikacije, možnost implementacije procedure v trenutku prekinitve povezave ter v trenutku

ponovne vzpostavitve povezave in podobno. Po končani implementaciji smo pričeli z

merjenjem rezultatov z zagonom posameznih primerjalnih procedur.

6.5 Integracija v Amazon AWS

Z razvojnim ogrodjem AWS Mobile SDK pridobimo programske knjižnice, ki zagotavljajo

povezavo med odjemalcem in storitvami AWS. Te programske knjižnice zagotavljajo

mobilno optimizirane vmesnike za dostop do storitev, kot so DynamoDB, Amazon S3 in

Amazon Kinesis. Razvojno ogrodje prav tako vsebuje možnost povezave do Amazon

Cognito in Amazon Mobile Analytics, ki so namenjene izključno razvijalcem mobilnih

rešitev.

Za potrebe našega raziskovalnega dela smo uporabili različico AWS Free za operacijski

sistem Android. Razvojno ogrodje AWS Mobile SDK za Android vsebuje naslednje:

Programske knjižnice – tj. razredi za dostop do vmesnikov spletnih storitev, razredi

za avtentifikacijo, ponovno pošiljanje zahtevkov in razrede za upravljanje z

napakami. Vsaka storitev je vključena v svoji programski knjižnici, tako da

razvijalci uporabijo zgolj tiste, ki jih potrebujejo; s tem lahko dosežejo, da je

velikost in kompleksnost razvite mobilne aplikacije manjša.

Primere uporabe – tj. praktični primeri uporabe knjižnic potrebnih za izdelavo

mobilnih rešitev.

Dokumentacijo – tj. referenčna dokumentacija za razvojno okolje AWS Mobile

SDK, vezana na operacijski sistem Android.

Kot je bilo povedano, smo v namene raziskovalnega dela uporabili brezplačni račun za

razvijalce (angl. »free tier development account«), pri katerem smo sledili čarovniku za

namestitev mobilne aplikacije. Uporaba platforme AWS znotraj mobilne aplikacije je tesno

vezana na deljene podatkovne centre, ki se nahajajo na različnih fizičnih lokacijah.


54

Platforma AWS je razmeščena na 13 ločenih geografskih regijah širom sveta, večinoma na

področju Amerike, Evrope, severne Azije in Avstralije [44]. Podatkovni centri zagotavljajo

vire, ki zajemajo dostop do podatkovnih baz, analiz, vodenja računov in drugo. Lokacijo

virov je treba izbrati pri izdelavi uporabniškega računa kakor tudi za vsak posamezen

projekt oziroma mobilno aplikacijo. Da bi zagotovili optimalno delovanje in največjo

zmogljivost, smo izbrali podatkovni center v Frankfurtu (EU_CENTRAL_1). Na Slika 6.14

je prikazana osnovno stran portala naše mobilne aplikacije limeOrder po končani

namestitvi.

Slika 6.14: Nadzorna plošča portala AWS, iz katerega je razvidno novo ustvarjeno zaledje


Po uspešni vzpostavitvi projekta na portalu AWS smo prenesli razvojno ogrodje AWS

Mobile SDK za operacijski sistem Android. Slika 6.15 prikazuje del programske kode v

mobilni aplikaciji, ki je bil potreben za integracijo omenjenega razvojnega ogrodja.


55

Slika 6.15: Vključitev razvojnega ogrodja AWS Mobile SDK v mobilno aplikacijo.

Po namestitvi razvojnega ogrodja AWS Mobile SDK smo za dostop do naše aplikacije

nastavili potrebna dovoljenja za uporabnika znotraj konzole Amazon Cognito. Na Slika 6.16

je prikazana programska koda avtentifikacije do storitev AWS znotraj naše mobilne

aplikacije.

Slika 6.16: Avtentifikacija do storitev AWS.


56

Po uspešni kreaciji in pridobitvi poverilnic smo izdelali podatkovno bazo s tabelami,

potrebnimi za izvedbo naših operacij. Pri tem smo morali za vsako izdelano tabelo izbrati

tudi pravice dostopa. Vsaka novo ustvarjena tabela ima privzeto zaklenjen dostop do

podatkov za neidentificirane uporabnike; poleg tega pa je mogoče za vsako posamezno

tabelo in za vsakega posameznega uporabnika nastaviti različne nivoje pravic. Pravice so

vezane na vsako mobilno storitev AWS in na posamezno akcijo znotraj posamezne storitve.

Pri uporabi mobilnih storitev AWS lahko imajo določeni uporabniki zgolj pravice za dostop

do baze, drugi zgolj za vnos podatkov, tretji pa nimajo dostopa do podatkov, vendar imajo

dostop do upravljanja poverilnic storitev AWS ali podobno. Za potrebe našega

raziskovalnega dela smo našemu uporabniškemu računu nastavili vse pravice in

pripadajoče akcije za delo s podatkovno bazo. Kot je bilo že omenjeno, platforma AWS

Mobile ponuja dostop do shranjevanja podatkov, preko njihove storitve Amazon

DynamoDB, ki predstavlja NoSQL podatkovno bazo. Razvijalcem je na voljo tudi uporaba

Amazon Data Storage, ki predstavlja shranjevanje in upravljanje z multimedijskimi

datotekami, kot so slike, posnetki, digitalna potrdila in drugo.

Pri sami vzpostavitvi in zagonu posameznih operacij smo naleteli na začetne težave, kajti

znotraj implementacije vsakega vmesnika za dostop do podatkov je treba eksplicitno

zapisati regijo dostopa do podatkovnih virov. Pri tem se privzeto uporablja regija

US_WEST_1, kar je za razvijalca, ki ni pri vzpostavitvi projekta izbral omenjene regije, zelo

moteče. Na Slika 6.17 je prikazan del programske kode, iz katere je razvidna eksplicitna

identifikacija regije dostopa do podatkovnih centrov oziroma virov. Kot je bilo že omenjeno,

smo zaradi optimalnega delovanja pri razvoju mobilne aplikaciji uporabili vire iz

podatkovnega centra v Frankfurtu (EU_CENTRAL_1).

Slika 6.17: Eksplicitno definiranje regije podatkovnih centrov.

Kot je bilo povedano, ponudnik zalednih storitev AWS Mobile za trajno shranjevanje

podatkov znotraj storitve DynamoDB uporablja podatkovno bazo NoSQL, kar nam je

omogočilo hitro implementacijo in upravljanje s podatki pri kompleksnejših razredih. Za

razliko od uporabe entitetno-relacijskih podatkovnih baz za shranjevanje podatkov

kompleksnejših razredov nismo potrebovali implementacije namenskih pretvornikov, ki bi


57

reševali primere v relacijah ena proti mnogo. Pri implementaciji je za posamezne entitete

treba zgolj uporabiti različne notacije. Na Slika 6.18 je prikazan primer uporabe notacij za

preprost razred, ki smo ga uporabili pri implementaciji.


58

Slika 6.18: Uporaba notacij za podatkovno bazo Amazon DynamoDB.


59

Iz zgornje slike je razvidna uporaba notacij brez katerih shranjevanje, spreminjanje in

nalaganje podatkov ne delujejo. Pri implementaciji shranjevanja podatkov v DynamoDB so

na voljo naslednje notacije [61]:

DynamoDBAttribute – predstavlja navaden atribut v tabeli;

DynamoDBAutoGeneratedKey – predstavlja dodatek primarnega ključa in

omogoča samodejno kreacijo primarnega ključa;

DynamoDBDocument – predstavlja kompleksnejši objekt ali razred za serializacijo;

DynamoDBHashKey – predstavlja primarni ključ v tabeli;

DynamoDBIgnore – predstavlja ignoriran atribut v tabeli;

DynamoDBIndexHashKey – predstavlja sekundarni ključ v tabeli;

DynamoDBIndexRangeKey – predstavlja globalni sekundarni ključ v tabeli;

DynamoDBMarshalling – predstavlja zapis, za katerega je treba izdelati lastno

implementacijo za serializacijo objektov;

DynamoDBNativeBoolean – predstavlja dodatek navadnem atributu in predstavlja

logični da/ne atribut v tabeli;

DynamoDBRangeKey – predstavlja indeksiran atribut;

DynamoDBTable – predstavlja razred celotne tabele;

DynamoDBVersionAttribute – predstavlja verzijo atributa v primeru posodobitev.

Za uporabo storitev za delo in shranjevanje podatkov preko Amazon DynamoDB kot tudi

uporabe drugih vmesnikov je bila potrebna implementacija asinhronih opravil, kajti v

operacijskem sistemu Android razvojno ogrodje AWS Mobile SDK ne dopušča klica funkcij

znotraj glavne niti procesa naše mobilne aplikacije. Razvojno ogrodje AWS Mobile SDK

dopušča in predvideva uporabo mobilne aplikacije, kadar je dostop do zalednih storitev

moten ali prekinjen. V tem primeru je treba uporabiti orodje Amazon Cognito Sync Manager

in znotraj mobilne aplikacije nastaviti potrebno konfiguracijo. Po končani implementaciji smo

pričeli z merjenjem rezultatov z zagonom posameznih primerjalnih procedur.

6.6 Integracija v Backendless

Backendless MBAAS predstavljajo sistem integriranih, mobilno orientiranih storitev preko

REST programskih vmesnikov API [50]. Z razvojnim ogrodjem Backendless SDK pridobimo


60

programske knjižnice, ki zagotavljajo dostop do zalednih storitev mBaaS ponudnika

Backendless. Obravnavani sistem storitev zajema naslednje:

upravljanje z uporabniki;

shranjevanje podatkov;

geolociranje;

pretok medijskih vsebin;

upravljanje elektronskih sporočil;

notifikacije push;

izdelavo poslovne logike po meri;

analize;

generiranje programske kode za mobilne naprave.

Znotraj razvojnega ogrodja Backendless SDK za Android smo pridobili programsko

knjižnico za dostop do spletnih storitev preko programskih vmesnikov API, začetno

dokumentacijo in osnovne primere uporabe. Za namene raziskovalnega dela smo se

registrirali kot brezplačni razvijalec. Omejitve uporabe znotraj brezplačnega preizkusa

zalednih storitev so podrobneje opisane v predhodnem poglavju. Pri izdelavi uporabniškega

računa in vzpostavitve aplikacije na portalu za razvijalce, za razliko od drugih ponudnikov

zalednih storitev, ni možnosti ročnega vnosa lokacije uporabe računalniških virov. Na Slika

6.19 vidimo osnovno stran portala za našo mobilno aplikacijo limeOrder po končani

namestitvi.


61

Slika 6.19: Nadzorna plošča portala Backendless, iz katerega je razvidno novo ustvarjeno

zaledje namenske aplikacije limeOrder.

Po uspešni vzpostavitvi projekta na portalu za razvijalce Backendless smo prenesli

razvojno ogrodje Backendless SDK za operacijski sistem Android. V postopku namestitve

smo znotraj razvojnega okolja Android Studio morali ročno namestiti in integrirati

programsko knjižnico. Dodatna modifikacija znotraj konfiguracijskih datotek za integracijo v

našo aplikacijo ni bila potrebna. Po uspešni integraciji programske knjižnice v našo mobilno

aplikacijo smo morali v programski kodi vzpostaviti začetno povezavo. Slika 6.20 prikazuje

del programske kode, ki nam je omogočila uporabo zalednih storitev podjetja Backendless.


62

Slika 6.20: Avtentifikacijo za uporabo zalednih storitev Backendless.

Po uspešni integraciji, ki zagotavlja dostop do uporabe zalednih storitev, smo izdelali

podatkovno bazo za namene našega raziskovalnega dela. Za trajno shranjevanje podatkov

pri uporabi zalednih storitev podjetja Backendless je na voljo entitetno-relacijska

podatkovna baza. Pri sami izdelavi podatkovne baze je razvijalcem v pomoč prilagojen

čarovnik, ki po kreaciji tabele omogoča napredne nastavitve za posamezen atribut v tabeli.

Na Slika 6.21 je prikazana uporaba čarovnika pri kreaciji naše podatkovne baze. Čarovnik

prav tako omogoča takojšnjo izdelavo validacije na nivoju podatkovne baze kot tudi

nastavitev primarnih ključev ter indeksiranja atributov.

Slika 6.21: Izdelava atributov podatkovne baze preko namenskega čarovnika za uporabo

zalednih storitev Backendless.

Znotraj izdelave naše mobilne aplikacije je za uporabo objektov, ki se shranjujejo v

podatkovno bazo, dovoljena uporaba javnih atributov. Ogrodje Backendless za

transformacijo objektov v podatkovno bazo ne potrebuje dodatnih notacij. Preostale

dodatne nastavitve posameznih atributov se tako nastavljajo znotraj predhodno

omenjenega čarovnika na portalu Backendless. Znotraj tabele se samodejno kreirajo

naslednji atributi za delovanje:


63

objectId – predstavlja primarni ključ zapisa v tabeli;

ownerId – predstavlja zapis lastnika v primeru, da aplikacija podpira za več

uporabnikov;

created – predstavlja časovni zapis o tem, kdaj je bil zapis vnesen;

updated – predstavlja časovni zapis o tem, kdaj je bil zapis nazadnje spremenjen.

Za potrebe našega raziskovalnega dela smo izmed samodejno kreiranih atributov uporabili

zgolj objectId. Na SSlika 6.22 je programska koda izdelave enostavnega razreda za izvedbo

zgoraj navedenih operacij.

Slika 6.22: Struktura objekta za shranjevanje v podatkovno bazo ponudnika Backendless.

Med procesom implementacije mobilne aplikacije smo ugotovili, da posamezne tabele

podatkovne baze ni treba predhodno ustvarjati. Procedura na strani ponudnika

Backendless ob prvem klicu funkcije shranjevanja podatka, ki je v skladu z zahtevami

izdelave objektov za shranjevanje znotraj mobilne aplikacije, sama ustvari ustrezno tabelo


64

v podatkovni bazi, kar je s stališča razvijalcev, ki niso vešči modeliranja entitetno-relacijskih

podatkovnih baz, zelo dobrodošlo. Prav tako v tem primeru razvijalcem ni treba skrbeti za

izdelavo tujih ključev v primeru relacij tabel ena proti mnogo, kajti za to poskrbi zgoraj

omenjena samodejna procedura znotraj podatkovne baze Backendless. Za reševanje

relacij ena proti mnogo, znotraj serializacije objektov, nismo potrebovali implementacije

dodatnih namenskih vmesnikov za serializacijo in deserializacijo objektov. Na Slika 6.23 je

del programske kode, kjer se znotraj klica funkcije za nalaganje podatkov objekt samodejno

serializira. Zraven samodejne serializacije in deserializacije zapisov v tabeli podatkovne

baze so na voljo funkcije za pridobitev in upravljanje s podatki v klasičnem tekstovnem

načinu v strukturi JSON.


klicev zalednih storitev Backendless MBAAS je dovoljena uporaba sinhronih in asinhronih

opravil. V primeru uporabe sinhronih funkcij preko glavne niti procesa mobilne aplikacije je

tako predvidena implementacija poslušalcev (angl. »listeners«), ki vračajo rezultate in

informacije nazaj na glavno nit procesa. V našem primeru izdelave mobilne aplikacije smo

uporabili pristop implementacije z uporabo asinhronih opravil. Na Slika 6.23 lahko vidimo

del programske kode, kjer smo za klic posameznih funkcij za dostop do storitev

Backendless uporabili izvršitev znotraj asinhronega opravila. Pri implementaciji uporabe

storitev omenjenega ponudnika je pomembno tudi to, da uporaba mobilne aplikacije v

načinu brez povezave do zalednih storitev ni možna.


65

Slika 6.23: Programska koda, iz katere je razvidna serializacija objektov znotraj

pripadajočih funkcij in uporaba asinhronega opravila.


66



6.7 Integracija v Kinvey

Ponudnik zalednih storitev Kinvey zagotavlja razvojno ogrodje za razvoj domorodnih,

hibridnih in spletnih aplikacij. V naboru storitev zagotavlja mehanizme za uporabniško

izkušnjo pri delu brez povezave, sinhronizacijo podatkov, avtentifikacijo uporabnikov in

podobno. Vsi shranjeni podatki pri ponudniku zalednih storitev Kinvey so zaščiteni po

algoritmu AES-256 [62]. Ponudnik Kinvey znotraj nabora uporabe zalednih storitev zajema:

upravljanje z dostopom in identiteto uporabnikov;

trajno shranjevanje podatkov;

shranjevanje datotek;

upravljanje z notifikacijami, push storitvami SMS in storitvami elektronskih sporočil;

uporabo lokacijskih storitev;

podporo svetilnikov (angl. »Beacon support«);

analizo na podlagi uporabnikov ali porabe.

Znotraj razvojnega ogrodja Kinvey za Android smo pridobili programsko knjižnico za dostop

do zalednih spletnih storitev. Na portal za razvijalce smo se registrirali kot brezplačni

razvijalec. Omejitve uporabe znotraj brezplačnega preizkusa zalednih storitev so

podrobneje opisane v predhodnem poglavju za ponudnika Kinvey. Pri kreiranju

uporabniškega računa in vzpostavitve aplikacije na portalu za razvijalce, enako kot pri

ponudniku Backendless, opisanem v predhodnem poglavju, ni možnosti ročnega vnosa

lokacije uporabe računalniških virov. Na Slika 6.24 vidimo osnovno stran portala naše

mobilne aplikacije limeOrder po končani namestitvi. Pri sami izdelavi mobilne aplikacije je

treba omeniti dejstvo, da za razliko od drugih ponudnikov zalednih storitev znotraj podjetja

Kinvey priporočajo namensko štirislojno arhitekturo mobilne aplikacije. Po njihovem mnenju

naj bi se njihov način štirislojne arhitekture učinkovito izkazal pri izgradnji kompleksnejših

mobilnih aplikacij kot tudi pri poznejšem vzdrževanju in urejanju programske kode [63].

Predlagana arhitektura se tako deli na naslednje sloje:

sloj odjemalca (angl. »client tier«) – upravljanje z uporabniki, medpomnjenje v

primeru dela v načinu brez povezave, ustvarjanje notifikacij push in podobno;


67

sloj dostave (angl. »delivery tier«) – nalaganje in transformacija podatkov na

podlagi preferenc v sloju odjemalca (kontekst aplikacije, prijavljen uporabnik,

lokacija, stanje mobilne naprave in podobno);

sloj agregacije (angl. »aggregation tier«) – upravljanje s prenosom podatkov;

sloj storitev (angl. »service tier«) – predstavlja interakcijo mobilne aplikacije z

zalednimi storitvami

Slika 6.24: Nadzorna plošča portala Kinvey.

Znotraj nadzorne plošče na portalu za razvijalce obravnavanega ponudnika smo zasledili

možnost sodelovanja več razvijalcev. Znotraj vzpostavitve sodelovanja nas vodi čarovnik,

preko katerega na podlagi identifikatorja elektronske pošte vnesemo druge razvijalce, ki jim

lahko nastavimo tudi različne pravice. V našem primeru brezplačnega računa za razvijalce

sodelovanje ni možno. Po končani vzpostavitvi mobilne aplikacije na portalu Kinvey smo

vzpostavili začetno integracijo z razvojnim ogrodjem Kinvey Client SDK. V postopku

namestitve smo znotraj razvojnega okolja Android Studio morali ročno namestiti in

integrirati programsko knjižnico za dostop do zalednih storitev Kinvey, skupaj s preostalimi

programskimi knjižnicami za pravilno delovanje dostopa do zalednih storitev. Za pravilno

delovanje potrebuje programska knjižnica Kinvey Client SDK še knjižnico GSON, knjižnico


68

GUAVA, programske knjižnice za dostop do Google HTTP programskih vmesnikov API in

knjižnico Jackson. Dodatna modifikacija znotraj konfiguracijskih datotek za integracijo v

našo aplikacijo ni bila potrebna. Po uspešni integraciji programske knjižnice v našo mobilno

aplikacijo smo morali v programski kodi vzpostaviti začetno povezavo. Na Slika 6.25 je del

programske kode, ki nam je omogočila uporabo zalednih storitev podjetja Kinvey.

Slika 6.25: Avtentifikacija do storitev Kinvey.

Po implementirani začetni vzpostavitvi dostopa do zalednih storitev ponudnika Kinvey smo

pričeli z izdelavo podatkovne baze. Podatkovno bazo za trajno shranjevanje podatkov lahko

izdelamo preko portala za razvijalce ali pa se podatkovna tabela z atributi samodejno kreira

iz objekta v mobilni aplikaciji ob klicu prve interakcije s podatkovno bazo. Znotraj portala je

omogočena zgolj kreacija podatkovne tabele, brez dodatnega orodja za izdelavo želenih

atributov ali relacij. Kot omenjeno, se atributi za posamezno podatkovno tabelo samodejno

kreirajo ob prvi interakciji s podatkovno bazo. Pri tem je dovoljena uporaba naslednjih tipov

atributov:

String – tekstovni niz podatkov;

Int – vrednost celega števila;

Double – vrednost decimalnega števila;

Long – vrednost razširjenega decimalnega števila;

Boolean – vrednost logičnega operanda da ali ne;

Collection – vrednost kolekcije v primerjavi sklicevanja na zapis v drugi podatkovni

tabeli;


69

GenericJSON – vrednost po meri v formatu JSON.

Znotraj izvršitve funkcij dostopa do podatkovne baze se za prenos podatkov uporablja

format JSON, prav tako se podatki samodejno transformirajo iz zapisa v formatu JSON v

podatkovni objekt znotraj mobilne aplikacije. Za omenjeno transformacijo skrbi referenčna

knjižnica GSON. Za uspešno samodejno kreacijo atributov v podatkovni tabeli kot tudi za

transformacijo zapisa v formatu JSON v podatkovni objekt je potrebna uporaba notacij. Na

Slika 6.26 vidimo primer uporabe notacij. Če posameznega atributa v programski kodi ne

označimo s potrebno notacijo, se ta ne prenese. Znotraj nastale podatkovne baze se

samodejno ustvarijo naslednji atributi:

_id – predstavlja primarni ključ zapisa v podatkovni tabeli;

_acl – predstavlja id uporabnika, ki je zapis izdelal;

_kmd – predstavlja skupek časovnih zapisov, kdaj je bil zapis ustvarjen in kdaj je

bil zapis nazadnje spremenjen.

Slika 6.26: Uporaba notacij za transformacijo podatkov.


70

Uporaba zgoraj omenjenih samodejno kreiranih atributov, znotraj projekta mobilen

aplikacije, je opcijska; v našem primeru smo uporabili zgolj atribut, ki je primarni ključ.

Podatkovna baza ponudnika Kinvey ne generira primarnega ključa samodejno, zato smo v

ta namen morali implementirati ročno generacijo UUID primarnega ključa.

Pred prvo interakcijo dostopa do zalednih storitev Kinvey pri projektu mobilne aplikacije

smo najprej prijavili uporabnika. Za produkcijsko delo je predvideno, da se vsak razvijalec

ali končni uporabnik pred uporabo mobilne aplikacije, ki vsebuje dostop do zalednih storitev

Kinvey, identificira z unikatnim žetonom ali uporabniškim imenom oziroma geslom. Na Slika

6.27 je del programske kode za identifikacijo uporabnika. Kot je razvidno s slike, je dovoljen

tudi generična identifikacija uporabnika, ki je vezana na lastnika ustvarjene aplikacije na

portalu za razvijalce Kinvey. Za potrebe naše mobilne aplikacije smo za identifikacijo

uporabnika uporabili omenjen način.

Slika 6.27: Potrebna prijava uporabnika pred interakcijo z zalednimi storitvami ponudnika

Kinvey.


klicev zalednih storitev ponudnika Kinvey je potrebna uporaba in implementacija

poslušalcev, ki ob končani interakciji s podatkovno bazo vrnejo želen rezultat ali napako..

Na Slika 6.28 je prikazan del programske kode, pri čemer smo za klic posameznih funkcij

za dostop do zalednih storitev Kinvey uporabili implementacijo poslušalca. Za preprosto


71

uporabo vnosa posameznega zapisa ali branja in nalaganja v seznam na grafičnem

vmesniku končnega uporabnika je uporaba poslušalcev zelo preprosta. V primeru

kompleksnejše poslovne logiko pa je postopek implementacije za razvijalce zelo zamuden

in nepregleden. V ta namen je na portalu Kinvey na voljo tudi implementacija lastne

poslovne logike na strežniku. Na voljo so naslednji načini prenosa poslovne logike na

strežnik:

Kljuke zbirk (angl. »Collection hooks«) – implementacija omogoča spreminjanje

zahtevkov podatkov na strežniku. Način je primeren, kadar zahtevek vsebuje zapis

podatkov s sklici zapisov iz drugih tabel (relacije ena proti mnogo). V tem primeru

lahko razvijalci izdelajo specifično logiko, kako se ti zapisi shranijo ali uredijo

znotraj podatkovne baze.

Končne točke po meri (angl. »Custom endpoints«) – implementacija omogoča

izdelavo programske kode ali celotnih funkcij, ki se v celoti izvedejo na strežniku. S

tem lahko razvijalci znotraj mobilne aplikacije izdelano proceduro uporabijo preko

programskega vmesnika API.

Skupna koda (angl. »Common Code«) – omogoča uporabo končnih točk po meri

ali kljuke zbirk, ki so implementirali drugi razvijalci in so te posredovali v javno

skupno rabo.

Urnik (angl. »Scheduled Code«) – omogoča zagon ali izvrševanje posamezno

implementirane procedure po vnaprej določenem urniku ali na podlagi

specifičnega dogodka.


72

Slika 6.28: Programska koda, iz katere je razvidna uporaba poslušalcev pri klicu zalednih

storitev Kinvey.


73

Ponudnik storitev Kinvey omogoča uporabo aplikacije v načinu brez povezave. Pri

implementaciji moramo upoštevati naslednje politike medpomnjenja (angl. »caching

policy«) in politike načina brez povezave (angl. »offline policy«), preko katerih razvijalci

nastavijo razreševanje sinhronizacije po naslednjih načinih:

OfflinePolicy.ONLINE_FIRST – po pridobitvi povezave se najprej prenesejo

podatki iz strežnika in se prepišejo z obstoječimi znotraj mobilne aplikacije;

OfflinePolicy.LOCAL_FIRST – po pridobitvi povezave se najprej lokalni podatki,

nastali v času brez povezave, prenesejo podatki na strežnik in po potrebi prepišejo

z obstoječimi;

OfflinePolicy.ALWAS_ONLINE – omenjen način ne omogoča uporabe mobilne

aplikacije v času brez povezave.

Za uporabo mobilne aplikacije pri povezovanju do storitev ponudnika Kinvey je pri tem treba

omenjene politike implementirati znotraj izdelave poslušalcev. Na Slika 6.29 vidimo del

programske kode, ki prikazuje prenos podatkov v načinu brez povezave, pri upoštevanju

politike, da se ob vzpostavitvi povezave najprej prenesejo in posodobijo podatki nastali na

napravi mobilne aplikacije.

Slika 6.29: Del programske kode za delo v načinu brez povezave.




74

7 KOMPARATIVNA ANALIZA PONUDNIKOV STORITEV BAAS

V tem poglavju smo na podlagi zastavljenih raziskovalnih vprašanj in pridobljenih podatkov

iz implementacije uporabe zalednih storitev različnih ponudnikov v izdelano mobilno

aplikacijo, podrobneje opisanih v predhodnem poglavju, predstavili rezultate merjenj,

izdelali primerjavo in podali končne ugotovitve. V sklopu analize obravnavanih ponudnikov

smo izvedli naslednje primerjave:

primerjavo po hitrosti dostopa do podatkov;

primerjavo po kompleksnosti implementacije;

primerjavo po možnosti izdelave poslovne logike po meri;

primerjavo po možnosti uporabe brez povezave;

primerjavo po velikosti zapisov v podatkovni bazi;

primerjavo po zajetih storitvah po cenovnem modelu.

7.1 Rezultati merjenja implementacije zalednih storitev

V podpoglavju so navedeni rezultati meritev, pridobljenih z integracijo zalednih storitev

posameznega ponudnika v namensko mobilno aplikacijo. Na podlagi merjenja smo pridobili

podatke, s katerimi smo lahko storitve izbranih ponudnikov pozneje primerjali po prvem

podanem kriteriju hitrosti dostopa do podatkov. Enako smo med izvedbo primerjalnih

procedur samih pridobili podatke o velikosti nastalih podatkov ter zasedenosti podatkovne

baze s strani izbranega ponudnika. Z namenom, da bi zagotovili relevantne rezultate, smo

za vsako meritev uporabili deset poskusov merjenja.

Microsoft Azure

Po končani integraciji storitev ponudnika Microsoft Azure smo na podlagi merjenja pridobili

podatke za vsak korak primerjalne procedur oziroma operacij. V naslednjih tabelah (Tabela

7.1, Tabela 7.2, Tabela 7.3) so prikazane meritve znotraj primerjalnih operacij na podlagi

integracije storitev ponudnika Microsoft Azure po posameznih korakih.


75

Tabela 7.1: Rezultati merjenja integracije storitev Microsoft Azure po korakih za primerjalno

proceduro 1.

Zaporedna številka poskusa

Korak 1 Korak 2 Korak 3 Skupen čas

1. 2315 ms 1021 ms 15601 ms 18937 ms

2. 2178 ms 997 ms 18875 ms 22050 ms

3. 2549 ms 1085 ms 17008 ms 20642 ms

4. 2612 ms 1121 ms 18905 ms 22638 ms

5. 2438 ms 1047 ms 17606 ms 21091 ms

6. 2269 ms 987 ms 19963 ms 23219 ms

7. 2413 ms 929 ms 19480 ms 22822 ms

8. 2681 ms 1048 ms 16843 ms 20572 ms

9. 2369 ms 1036 ms 17828 ms 21233 ms

10. 2741 ms 1011 ms 17286 ms 21038 ms


proceduro 2.



1. 572 ms 307 ms 203 ms 1082 ms

2. 591 ms 298 ms 166 ms 1055 ms

3. 596 ms 287 ms 140 ms 1023 ms

4. 576 ms 301 ms 200 ms 1077 ms

5. 548 ms 295 ms 137 ms 980 ms

6. 612 ms 287 ms 119 ms 1018 ms

7. 637 ms 293 ms 176 ms 1106 ms

8. 587 ms 263 ms 138 ms 988 ms

9. 599 ms 286 ms 154 ms 1039 ms

10. 583 ms 278 ms 138 ms 999 ms


proceduro 3.


Korak 1 Korak 2 Korak 3 Korak 4 Korak 5 Korak 6 Skupen čas

1. 458 ms 691 ms 44 ms 125 ms 15 ms 39 ms 1372 ms

2. 441 ms 721 ms 38 ms 137 ms 12 ms 46 ms 1395 ms

3. 471 ms 711 ms 47 ms 148 ms 19 ms 50 ms 1446 ms

4. 469 ms 702 ms 43 ms 143 ms 7 ms 41 ms 1405 ms

5. 478 ms 699 ms 39 ms 154 ms 18 ms 75 ms 1463 ms


76

6. 471 ms 692 ms 48 ms 134 ms 12 ms 47 ms 1404 ms

7. 477 ms 673 ms 47 ms 152 ms 18 ms 42 ms 1409 ms

8. 475 ms 688 ms 51 ms 149 ms 12 ms 22 ms 1397 ms

9. 466 ms 698 ms 43 ms 144 ms 19 ms 28 ms 1398 ms

10. 512 ms 691 ms 58 ms 159 ms 15 ms 56 ms 1491 ms

V Tabela 7.4 so ponazorjeni skupni rezultati merjenja vseh primerjalnih operacij po desetih

preizkusih.

Tabela 7.4: Rezultati merjenja posameznih operacij pri integraciji Microsoft Azure.

Zaporedna številka

poizkusa

Operacija 1 Operacija 2 Operacija 3

1. 18937 ms 1082 ms 1372 ms

2. 22050 ms 1055 ms 1395 ms

3. 20642 ms 1023 ms 1446 ms

4. 22638 ms 1077 ms 1405 ms

5. 21091 ms 980 ms 1463 ms

6. 23219 ms 1018 ms 1404 ms

7. 22822 ms 1106 ms 1409 ms

8. 20572 ms 988 ms 1397 ms

9. 21233 ms 1039 ms 1398 ms

10. 21038 ms 999 ms 1491 ms

21424, 2ms 1036,7 ms 1418 ms

Na Slika 7.1 je grafičen prikaz skupnih rezultatov, predstavljenih v zgornji tabeli.


77

Slika 7.1: Graf rezultata za merjenje posameznih operacij pri integraciji Microsoft Azure.

Iz rezultatov je razvidno, da je uporaba relacijske podatkovne baze preko zalednih storitev

Azure za vstavljanje in branje podatkov precej hitra in zahteva zelo malo časa, medtem ko

se čas izvedbe posamezne operacije pri posodabljanju ali branju večje količine podatkov

upočasni. Iz zgornje tabele je tudi razvidno, da s testiranjem nismo zasedli velike količine

prostora, za izvedbo primerjalnih operacij smo porabili 6 MB prostora. Med procesom

integracije dostopa do storitev Azure smo ugotovili, da ponudnik omenjenih storitev

omogoča delno selitev poslovne logike mobilne aplikacije na sam strežnik. Operacije na

strežniku so v tem primeru omejene na operacije vstavljanja, brisanja, branja ali urejanja

podatkov, prav tako pa lahko razvijalci kreirane operacije zaganjajo z urnikom v določenem

časovnem intervalu ali na zahtevo, znotraj klica kreiranega opravila v mobilni aplikaciji.

Google Firebase

Po končani integraciji storitev ponudnika Google Firebase smo na podlagi merjenja pridobili


7.5, Tabela 7.6, Tabela 7.7) so prikazane meritve znotraj primerjalnih operacij na podlagi

integracije storitev ponudnika Google Firebase po posameznih korakih.

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Hit

rost

(m

s)

Zaporedna ševilka poskusa

Operacija 1

Operacija 2

Operacija 3


78

Tabela 7.5: Rezultati merjenja integracije storitev Google Firebase po korakih za primerjalno

proceduro 1.

Zaporedna številka

poskusa


1. 80 ms 92 ms 197 ms 369 ms

2. 104 ms 102 ms 201 ms 407 ms

3. 108 ms 99 ms 207 ms 414 ms

4. 83 ms 95 ms 199 ms 377 ms

5. 92 ms 97 ms 192 ms 381 ms

6. 144 ms 143 ms 231 ms 518 ms

7. 97 ms 81 ms 189 ms 367 ms

8. 89 ms 78 ms 181 ms 348 ms

9. 92 ms 80 ms 192 ms 364 ms

10. 97 ms 89 ms 200 ms 386 ms


proceduro 2.



1. 94 ms 429 ms 326 ms 849 ms

2. 107 ms 406 ms 335 ms 848 ms

3. 112 ms 443 ms 300 ms 855 ms

4. 106 ms 469 ms 306 ms 881 ms

5. 102 ms 407 ms 320 ms 829 ms

6. 98 ms 381 ms 330 ms 809 ms

7. 111 ms 426 ms 284 ms 821 ms

8. 104 ms 406 ms 328 ms 838 ms

9. 108 ms 374 ms 352 ms 834 ms

10. 80 ms 466 ms 322 ms 868 ms


proceduro 3.



1. 229 ms 372 ms 1 ms 4 ms 5 ms 12 ms 623 ms

2. 239 ms 362 ms 2 ms 7 ms 2 ms 4 ms 616 ms


79

3. 254 ms 319 ms 2 ms 4 ms 6 ms 7 ms 592 ms

4. 291 ms 288 ms 1 ms 10 ms 7 ms 11 ms 608 ms

5. 264 ms 314 ms 1 ms 6 ms 3 ms 11 ms 599 ms

6. 303 ms 281 ms 1 ms 10 ms 8 ms 10 ms 613 ms

7. 341 ms 252 ms 3 ms 14 ms 7 ms 3 ms 620 ms

8. 248 ms 297 ms 2 ms 14 ms 5 ms 16 ms 582 ms

9. 285 ms 261 ms 3 ms 12 ms 5 ms 6 ms 572 ms

10. 299 ms 257 ms 2 ms 4 ms 9 ms 4 ms 575 ms

V Tabela 7.8 so skupni rezultati merjenja vseh primerjalnih operacij po desetih preizkusih.

Tabela 7.8: Rezultati merjenja posameznih operacij pri integraciji Firebase.

Zaporedna številka

poizkusa


1. 369 ms 849 ms 623 ms

2. 407 ms 848 ms 616 ms

3. 414 ms 855 ms 592 ms

4. 377 ms 881 ms 608 ms

5. 381 ms 829 ms 599 ms

6. 518 ms 809 ms 613 ms

7. 367 ms 821 ms 620 ms

8. 348 ms 838 ms 582 ms

9. 364 ms 834 ms 572 ms

10. 386 ms 868 ms 575 ms

393,1 ms 843,1 ms 600 ms

Na Slika 7.2 lahko vidimo grafičen prikaz skupnih rezultatov, predstavljenih v zgornji tabeli.


80

Slika 7.2: Graf rezultata merjenja posameznih operacij pri integraciji Google Firebase.

Iz zgornjih rezultatov je razvidno, da je uporaba podatkovne baze znotraj zalednih storitev

Firebase zelo zmogljiva pri branju podatkov in vnosu podatkov. Pri iskanju po indeksiranih

ključih iz podatkovne baze pa se čas izvedbe poveča. Uporaba podatkovne baze nakazuje

na dobre zmogljivosti tudi pri uporabi kompleksnejše logike in dela s kompleksnejšimi

objekti. Za trajno shranjevanje podatkov nismo uporabili veliko prostora, za izvedbo

primerjalnih operacij smo porabili 6,3 KB prostora, kar nakazuje na izredno prostorsko

učinkovitost podatkovne baze znotraj storitev Firebase.

Amazon AWS

Po končani integraciji storitev ponudnika Amazon AWS smo na podlagi merjenja pridobili

podatke za vsak korak primerjalne procedure oziroma operacije. V naslednjih tabelah

(Tabela 7.9, Tabela 7.10, Tabela 7.11) so prikazane meritve znotraj primerjalnih operacij

na podlagi integracije storitev ponudnika Amazon AWS po posameznih korakih.

Tabela 7.9: Rezultati merjenja integracije storitev Amazon AWS po korakih za primerjalno

proceduro 1.



1. 181 ms 10602 ms 5245 ms 16028 ms

2. 792 ms 7618 ms 6479 ms 14889 ms

3. 790 ms 7423 ms 6991 ms 15204 ms

4. 576 ms 7681 ms 7102 ms 15359 ms

5. 464 ms 7926 ms 6971 ms 15361 ms

6. 439 ms 7129 ms 7321 ms 14889 ms

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Hit

rost

(m

s)


Operacija 1

Operacija 2

Operacija 3


81

7. 693 ms 7345 ms 6496 ms 14534 ms

8. 742 ms 7925 ms 6247 ms 14914 ms

9. 712 ms 7685 ms 7562 ms 14959 ms

10. 526 ms 7309 ms 7199 ms 15034 ms


proceduro 2.



1. 248 ms 101 ms 95 ms 444 ms

2. 257 ms 107 ms 109 ms 473 ms

3. 194 ms 110 ms 108 ms 412 ms

4. 224 ms 103 ms 108 ms 435 ms

5. 245 ms 98 ms 101 ms 444 ms

6. 240 ms 109 ms 105 ms 454 ms

7. 220 ms 104 ms 113 ms 437 ms

8. 236 ms 105 ms 109 ms 450 ms

9. 258 ms 102 ms 124 ms 484 ms

10. 201 ms 118 ms 89 ms 408 ms


proceduro 3.



1. 735 ms 1282 ms 243 ms 170 ms 7 ms 139 ms 2576 ms

2. 481 ms 1304 ms 140 ms 195 ms 2 ms 125 ms 2247 ms

3. 662 ms 1358 ms 104 ms 114 ms 6 ms 146 ms 2390 ms

4. 619 ms 1262 ms 142 ms 138 ms 5 ms 137 ms 2303 ms

5. 549 ms 1192 ms 141 ms 178 ms 6 ms 142 ms 2208 ms

6. 623 ms 1351 ms 147 ms 169 ms 5 ms 146 ms 2441 ms

7. 584 ms 1303 ms 161 ms 141 ms 6 ms 151 ms 2346 ms

8. 525 ms 1307 ms 153 ms 160 ms 2 ms 121 ms 2268 ms

9. 592 ms 1370 ms 192 ms 145 ms 4 ms 141 ms 2444 ms

10. 517 ms 1269 ms 140 ms 205 ms 5 ms 136 ms 2272 ms

V Tabela 7.12 so prikazani skupni rezultati merjenja vseh primerjalnih operacij po desetih

preizkusih.


82

Tabela 7.12: Rezultati merjenja posameznih operacij pri integraciji AWS Mobile.

Zaporedna številka

poizkusa


1. 16028 ms 444 ms 2576 ms

2. 14889 ms 473 ms 2247 ms

3. 15204 ms 412 ms 2390 ms

4. 15359 ms 435 ms 2303 ms

5. 15361 ms 444 ms 2208 ms

6. 14889 ms 454 ms 2441 ms

7. 14534 ms 437 ms 2346 ms

8. 14914 ms 450 ms 2268 ms

9. 14959 ms 484 ms 2444 ms

10. 15034 ms 408 ms 2272 ms

15117,1 ms 444,1 ms 2349,5 ms

Na Slika 7.3 je grafičen prikaz skupnih rezultatov predstavljenih v zgornji tabeli.

Slika 7.3: Graf rezultata merjenja posameznih operacij pri integraciji Amazon AWS.

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Hit

rost

(m

s)


Operacija 1

Operacija 2

Operacija 3


83

Iz zgornjih rezultatov je razvidno, da je uporaba podatkovne baze Amazon DynamoDB zelo

zmogljiva pri branju podatkov in iskanju po indeksiranih ključih. Pri večjem številu vstavljanj

in branj iz podatkovne baze pa se čas izvedbe poveča. Uporaba podatkovne baze nakazuje

na dobre zmogljivosti tudi pri uporabi kompleksnejše logike in dela s kompleksnejšimi

objekti. Znotraj analitičnih storitev Amazon Mobile Analytics nismo uspeli pridobiti podatka

o velikosti same podatkovne baze.

Backendless

Po končani integraciji storitev ponudnika Backendless smo na podlagi merjenja pridobili


7.13, Tabela 7.14, Tabela 7.15) so prikazane meritve znotraj primerjalnih operacij na

podlagi integracije storitev ponudnika Backendless po posameznih korakih.

Tabela 7.13: Rezultati merjenja integracije storitev Backendless po korakih za primerjalno

proceduro 1.



1. 2758 ms 15052 ms 64941 ms 82751 ms

2. 2363 ms 41513 ms 43012 ms 86888 ms

3. 2482 ms 35018 ms 51787 ms 89287 ms

4. 2630 ms 41017 ms 36967 ms 80614 ms

5. 2904 ms 30333 ms 49059 ms 82296 ms

6. 2884 ms 41186 ms 41993 ms 86063 ms

7. 2845 ms 30090 ms 49234 ms 82169 ms

8. 2798 ms 41271 ms 39381 ms 83450 ms

9. 2812 ms 36071 ms 50685 ms 89568 ms

10. 2945 ms 37905 ms 45887 ms 86737 ms


proceduro 2.



1. 1190 ms 877 ms 895 ms 2962 ms

2. 1122 ms 1119 ms 886 ms 3127 ms

3. 1005 ms 884 ms 840 ms 2729 ms

4. 894 ms 862 ms 762 ms 2518 ms

5. 1007 ms 927 ms 947 ms 2881 ms

6. 1026 ms 931 ms 749 ms 2706 ms


84

7. 1623 ms 1440 ms 981 ms 4044 ms

8. 1038 ms 902 ms 665 ms 2605 ms

9. 962 ms 853 ms 738 ms 2553 ms

10. 991 ms 867 ms 742 ms 2600 ms


proceduro 3.



1. 1457 ms 1323 ms 1291 ms 2 ms 4 ms 1344 ms 5421 ms

2. 1330 ms 1287 ms 1397 ms 5 ms 4 ms 1240 ms 5263 ms

3. 1384 ms 1197 ms 1265 ms 2 ms 3 ms 1134 ms 4985 ms

4. 1889 ms 1278 ms 1106 ms 1 ms 3 ms 1040 ms 5317 ms

5. 1578 ms 1359 ms 1275 ms 4 ms 2 ms 1192 ms 5410 ms

6. 869 ms 998 ms 1283 ms 4 ms 3 ms 1159 ms 4316 ms

7. 908 ms 983 ms 998 ms 2 ms 3 ms 1033 ms 3927 ms

8. 1734 ms 1836 ms 1447 ms 2 ms 4 ms 1574 ms 6597 ms

9. 875 ms 901 ms 1019 ms 4 ms 5 ms 1135 ms 3939 ms

10. 989 ms 1059 ms 1025 ms 2 ms 3 ms 1215 ms 4293 ms

V Tabela 7.16 lahko vidimo skupne rezultate merjenja vseh primerjalnih operacij po desetih

preizkusih.

Tabela 7.16: Rezultati merjenja posameznih operacij pri integraciji Backendless.

Zaporedna številka

poizkusa


1. 82751 ms 2962 ms 5421 ms

2. 86888 ms 3127 ms 5263 ms

3. 89287 ms 2729 ms 4985 ms

4. 80614 ms 2518 ms 5317 ms

5. 82296 ms 2881 ms 5410 ms

6. 86063 ms 2706 ms 4316 ms

7. 82169 ms 4044 ms 3927 ms

8. 83450 ms 2605 ms 6597 ms

9. 89568 ms 2553 ms 3939 ms

10. 86737 ms 2600 ms 4293 ms


85

84982,3 ms 2872,5 ms 4946,8 ms

Na Slika 7.4 je grafičen prikaz skupnih rezultatov, predstavljenih v zgornji tabeli.

Slika 7.4: Graf rezultata merjenja posameznih operacij pri integraciji Backendless.

Iz zgornje tabele in grafikona je razvidno, da je uporaba storitev shranjevanja podatkov

ponudnika Backendless pri nalaganju in vnosu podatkov časovno zelo potratna. Iz

prikazanih podatkov predvidevamo, da je to posledica uporabe podatkovnih virov na

oddaljeni lokaciji, saj ponudnik zalednih storitev Backendless ne omogoča ročne izbire

lokacije uporabe podatkovnih virov. Pri iskanju posameznega zapisa po zahtevanem ključu

v podatkovni bazi pri meritvah nismo zasledili večjih časovnih vrednosti. Uporaba zalednih

storitev se je časovno učinkovito izvedla tudi pri izvrševanju zahtevnejših operacij, prav tako

smo za potrebe našega raziskovalnega dela in testiranja porabili 1 MB prostora v

podatkovni bazi.

Kinvey

Po končani integraciji storitev ponudnika Kinvey smo na podlagi merjenja pridobili podatke

za vsak korak primerjalne procedur oziroma operacij. V naslednjih tabelah (Tabela 7.17,

Tabela 7.18, Tabela 7.19) so prikazane meritve znotraj primerjalnih operacij na podlagi

integracije storitev ponudnika Kinvey po posameznih korakih.

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Hit

rost

(m

s)


Operacija 1

Operacija 2

Operacija 3


86

Tabela 7.17: Rezultati merjenja integracije storitev Kinvey po korakih za primerjalno proceduro 1.



1. 1236 ms 278 ms 13723 ms 15237 ms

2. 1040 ms 234 ms 14605 ms 15879 ms

3. 1277 ms 295 ms 14694 ms 16266 ms

4. 1174 ms 286 ms 14919 ms 16379 ms

5. 1282 ms 305 ms 14052 ms 15639 ms

6. 1172 ms 219 ms 14459 ms 15850 ms

7. 1063 ms 251 ms 14032 ms 15346 ms

8. 1063 ms 231 ms 13964 ms 15258 ms

9. 1060 ms 260 ms 13712 ms 15032 ms

10. 1137 ms 214 ms 14294 ms 15645 ms




1. 849 ms 293 ms 174 ms 1316 ms

2. 458 ms 274 ms 186 ms 918 ms

3. 498 ms 201 ms 131 ms 830 ms

4. 524 ms 209 ms 123 ms 856 ms

5. 593 ms 227 ms 180 ms 1000 ms

6. 517 ms 286 ms 186 ms 989 ms

7. 402 ms 203 ms 159 ms 764 ms

8. 514 ms 276 ms 172 ms 962 ms

9. 457 ms 204 ms 193 ms 854 ms

10. 532 ms 210 ms 168 ms 910 ms




1. 760 ms 316 ms 59 ms 634 ms 46 ms 786 ms 2601 ms

2. 698 ms 405 ms 87 ms 797 ms 68 ms 819 ms 2874 ms

3. 362 ms 427 ms 36 ms 657 ms 31 ms 735 ms 2248 ms

4. 325 ms 287 ms 59 ms 687 ms 69 ms 768 ms 2195 ms

5. 212 ms 395 ms 32 ms 652 ms 37 ms 921 ms 2249 ms

6. 288 ms 334 ms 59 ms 744 ms 69 ms 724 ms 2218 ms


87

7. 266 ms 337 ms 51 ms 631 ms 34 ms 753 ms 2072 ms

8. 345 ms 313 ms 34 ms 533 ms 11 ms 687 ms 1923 ms

9. 278 ms 257 ms 11 ms 689 ms 23 ms 767 ms 2025 ms

10. 300 ms 459 ms 32 ms 728 ms 32 ms 747 ms 2298 ms

V Tabela 7.20 vidimo skupne rezultate merjenja vseh primerjalnih operacij po desetih

preizkusih.

Tabela 7.20: Rezultati merjenja posameznih operacij pri integraciji Kinvey.

Zaporedna številka

poizkusa


1. 15237 ms 1316 ms 2601 ms

2. 15879 ms 918 ms 2874 ms

3. 16266 ms 830 ms 2248 ms

4. 16379 ms 856 ms 2195 ms

5. 15639 ms 1000 ms 2249 ms

6. 15850 ms 989 ms 2218 ms

7. 15346 ms 764 ms 2072 ms

8. 15258 ms 962 ms 1923 ms

9. 15032 ms 854 ms 2025 ms

10. 15645 ms 910 ms 2298 ms

15653,1 ms 939,9 ms 2270,3 ms

Na naslednji sliki (Slika 7.5) je grafičen prikaz skupnih rezultatov, predstavljenih v zgornji

tabeli.


88

Slika 7.5: Graf rezultata merjenja posameznih operacij pri integraciji Backendless.

Iz zgornjih rezultatov je razvidno, da je uporaba podatkovne baze v sklopu zalednih storitev

ponudnika Kinvey zelo zmogljiva in prostorsko učinkovita, saj smo za izvedbo operacij

porabili zgolj 34,3 KB prostora. Čeprav ponudnik ne omogoča ročne nastavitve lokacije

uporabe podatkovnih virov, smo dosegli zelo dobre rezultate. Rezultati nakazujejo, da je

uporaba storitev časovno zelo učinkovita pri iskanju podatkov po določenem kriteriju, prav

tako je zadovoljiva pri kompleksnejših operacijah in vnosu ter ažuriranju zapisov iz

podatkovne baze. Slabše zmogljivosti so bile ugotovljene zgolj pri večji količini vstavljanja

ali brisanja zapisov iz podatkovne baze.

7.2 Primerjalna analiza ponudnikov

Na podlagi izvedenih primerjav ponudnikov zalednih storitev BaaS smo zgoraj omenjene

primerjave podrobneje opisali in jih ločili po podpoglavjih. Primerjave so bile sestavljene in

opisane kot pomoč pri izbiri ponudnika zalednih storitev BaaS razvijalcem na podlagi

preferenc pri izdelavi mobilne aplikacije.

Primerjava po hitrosti dostopa do podatkov

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Hit

rost

(m

s)


Operacija 1

Operacija 2

Operacija 3


89

Na podlagi merjenja posameznega časa dostopa do storitev znotraj primerjalnih procedur

v naši mobilni aplikaciji smo za vse ponudnike zalednih storitev pridobili končne rezultate.

V Tabela 7.21 vidimo povprečni čas merjenja hitrosti dostopa do podatkov obravnavanih

ponudnikov zalednih storitev, po končani integraciji v razviti mobilni aplikaciji.

Tabela 7.21: Rezultati merjenja hitrosti dostopa do podatkov.

Ponudnik Operacija 1 Operacija 2 Operacija 3

Azure Mobile 21424,2 ms 1036,7 ms 1418 ms

Google Firebase 391,1 ms 843,2 ms 600 ms

Amazon AWS 15117,1 ms 444,1 ms 2349,5 ms

Backendless 84982,3 ms 2872,5 ms 4946,8 ms

Kinvey 15653,1 ms 939,9 ms 2270,3 ms

Slika 7.6: Graf rezultatov merjenja hitrosti dostopa do podatkov.

Na podlagi pridobljenih rezultatov smo glede na posamezno operacijo izvedli deskriptivno

statistko s stopnjo zaupanja 95 % in pridobili naslednje rezultate:

Operacija 1:

o najmanjša vrednost: 391,1 ms;

o največja vrednost: 84982,3 ms;

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

Azure Mobile Google Firebase Amazon AWS Backendless Kinvey

Hit

rost

(m

s)



90

o razpon: 84591,2 ms;

o srednja vrednost: 27513,58 ms;

o mediana: 15653,1 ms;

o standardna deviacija: 33051,88 ms.

Operacija 2:

o najmanjša vrednost: 444,1 ms;






Operacija 3:

o najmanjša vrednost: 600 ms;






Iz pridobljenih rezultatov deskriptivne statistike, zgornje tabele končnih rezultatov merjenja

(Tabela 7.21) in grafikona (Slika 7.6) je razvidno, da je po kriteriju hitrosti dostopa do

storitev, ki operirajo s shranjevanjem ali nalaganjem podatkov, najhitrejši ponudnik Google

Firebase. Prav tako je pri ponudniku Google Firebase moč razbrati največje odstopanje od

srednje vrednosti po posameznih operacijah napram ostalim ponudnikom. Menimo, da je

dostop do podatkov pri ponudniku Firebase časovno učinkovit zaradi možnosti ročne izbire

geografske lokacije uporabljenih podatkovnih virov, tako kot tudi zaradi strukture

shranjevanja podatkov v dokumentno orientirani podatkovni bazi NoSQL. Drugi po časovni

učinkovitosti na podlagi odstopanja od srednje vrednosti iz rezultatov deskriptivne statistike

je ponudnik storitev Amazon AWS, ki se zadovoljivo obnese pri iskanju podatkov kakor tudi

vstavljanju in ažuriranju. Po kriteriju časovne učinkovitosti sledita ponudnika zalednih

storitev Kinvey in Microsoft Azure. Kot je razvidno iz zgornje tabele, je po kriteriju hitrosti

dostopa do podatkov ponudnik Backendless za razvijalce mobilnih aplikacij najmanj

primeren. Enako smo na podlagi pridobljenih rezultatov izmerjenih časov statistično

preverili, ali obstajajo signifikantne razlike med ponudniki vezane na hitrost dostopa do

storitev. Kot statistično metodo smo uporabili statistični test One-Way Anova po stopnji


91

značilnosti 5 %. Nad podatki smo najprej izvedli Levanov test homogenosti varianc in na

podlagi rezultatov ugotovili, da je homogenost varianc kršena (Sig. < 0,05), zato smo za

preverjanje, ali med ponudniki obstajajo razlike v hitrosti, uporabili robustne teste enakosti

(Welchov test in Brown-Forsythe test). V Tabela 7.22 so rezultati obravnavanih testov.

Tabela 7.22: Rezultati statističnih testov na podlagi hitrosti.

Test Statistika Df1 Df2 Sig.

Levanov test 10,812 4 4 0,001

Welchov test 0,876 4 4,004 0,549

Brown-Forsythe test 0,854 4 2,501 0,587

Kot je bilo razvidno že iz pridobljenih rezultatov (Tabela 7.21, Slika 7.6), lahko tudi na

podlagi opravljenih testov (Welchov test in Brow-Forsythe test), s statističnega stališča

potrdimo, da med ponudniki obstajajo signifikantne razlike po kriteriju hitrosti dostopa do

storitev, ki operirajo s shranjevanjem ali nalaganjem podatkov.

Primerjava po kompleksnosti implementacije

Med procesom implementacije uporabe zalednih storitev obravnavanih ponudnikov znotraj

projekta naše mobilne aplikacije smo pridobili potrebno dokumentacijo in navodila, vendar

se sama implementacija od ponudnika do ponudnika razlikuje. Kot je bilo zapisano v

poglavju procesa integracije v mobilno aplikacijo, sta zaradi uporabe poslušalcev za razvoj

kompleksnejših opravil najmanj ugodna ponudnika Google Firebase in Kinvey. Če gre zgolj

za enostavno nalaganje podatkov v seznam mobilne aplikacije in urejanje posameznega

zapisa, je uporaba poslušalcev primerna. V primeru kompleksnejših operacij, zlasti kadar

ponudnik ne omogoča implementacije poslovne logike na strežniku storitev, pa razvijalcem

predstavlja dodatno kompleksnost in zahtevnost pri implementaciji; prav te prvine so v

nasprotju s samim namenom uporabe mobilnih zalednih storitev, ki naj bi razvijalcem

omogočile enostavno interakcijo pri uporabi zalednih storitev.

Kot je bilo povedano, lahko razvijalci pri preostalih ponudnikih za dostop do storitev

uporabljajo asinhrona opravila, kar omogoča izdelavo kompleksnejših procedur, katerih

implementacija je v reševanju dejanskih primerov potrebna dlje časa. Pri implementaciji in

interakciji storitev pri ponudniku Azure smo velikokrat naleteli na težave zlasti pri

transformaciji podatkov iz kompleksnejših podatkovnih tabel. Te težave so se pojavile pri

prenosu podatkov iz tabele, ki vsebujejo referenčni zapis iz druge tabele. Pri implementaciji


92

dostopa storitev ponudnika Azure morajo razvijalci implementirati namenske pretvornike za

uspešno transformacijo iz zapisov v podatkovni tabeli v podatkovne objekte znotraj mobilne

aplikacije. Pri implementaciji ponudnika zalednih storitev Amazon AWS je transformacija

podatkov rešena na strani ponudnika, vendar lahko zlasti manj izkušenim razvijalcem

povzročajo težave pri kompleksnemu uveljavljanju pravic dostopa do podatkovne baze,

izdelavi notacij in uporabi dostopa do storitev, vezanih na različno lokacijsko razkropljene

podatkovne vire. S stališča primerjave po kompleksnosti implementacije je tako priporočena

uporaba zalednih storitev ponudnika Backendless, pri katerem v procesu integracije v našo

mobilno aplikacijo nismo naleteli na tovrstne težave.

Primerjava po možnosti izdelave poslovne logike po meri

Zaradi raznolikosti v namenu uporabe mobilnih aplikacije so razvijalci primorani za izvedbo

posameznih opravil znotraj mobilne aplikacije razviti namensko poslovno logiko. Da bi

dosegli optimalno delovanje, je v specifičnih scenarijih potrebna izdelava poslovne logike

na nivoju strežnika storitev. Znotraj predstavitve in procesa implementacije posameznih

ponudnikov smo ugotovili, da ponudnika storitev Kinvey in Backendless podpirata različne

načine uporabe lastno razvite programske kode na strežniku. Omenjena ponudnika

podpirata izdelavo lastnih končnih točk z želeno poslovno logiko. Pri ponudniku zalednih

storitev Kinvey je prav tako možna uporaba končnih točk storitev drugih razvijalcev, pa tudi

uporaba samodejnih opravil na strežniku ob izvedbi specifične dogodka ali na podlagi

urnika. S stališča možnosti izdelave poslovne logike po meri je tako najprimernejši ponudnik

Kinvey, enako je na področju programske kode po meri ustrezen ponudnik Backendless.

Temu kriteriju sledita ponudnik Amazon AWS, ki prav tako preko nabora storitev AWS

Lambda omogoča izdelavo kompleksnejše poslovne logike na strežniku, vendar je

implementacija težavna, še posebej za manj vešče razvijalce. Ponudnik storitev Azure na

tem področju ponuja omejene operacije vstavljanja, brisanja, branja ali urejanja podatkov,

obenem pa lahko razvijalci kreirane operacije zaganjajo z urnikom v določenem časovnem

intervalu ali na zahtevo znotraj klica kreiranega opravila v mobilni aplikaciji. Razvijalci, ki za

implementacijo mobilnih aplikacij uporabljajo zaledne storitve ponudnika Azure, imajo

možnost izdelave namenskih vmesnikov API s poslovno logiko po meri, vendar je pri tem

za uporabo znotraj mobilne aplikacije potrebna registracija končnih točk z orodjem

Swagger. Ponudnik storitev Google Firebase za razvoj mobilnih aplikacij, ki za svoje

delovanje potrebujejo poslovno logiko po meri na nivoju strežnika, ni primeren, ker ne

omogoča lastne implementacije na nivoju strežnika.


93

Primerjava po možnosti uporabe brez povezave

Zaradi uporabe mobilnih aplikacij na različnih lokacijah s slabšim ali prekinjenim delovanjem

internetne povezave se razvijalci pogosto srečujejo s problemom sinhronizacije in delovanja

mobilne aplikacije, kadar je povezava do spletnih storitev motena ali onemogočena.

Ponudnik storitev Backendless ne ponuja možnosti uporabe mobilne aplikacije, ko je dostop

do storitev moten ali onemogočen. Preostali ponudniki zalednih storitev BaaS ponujajo

vključene možnosti uporabe mobilne aplikacije v načinu brez povezave. Pri tem je treba

poudariti ponudnika Firebase, ki ponuja razvijalcem širok nabor politik in možnosti

implementacije različnih poslušalcev, kadar povezava ni na voljo. Zaradi naprednih

možnosti uporabe v primeru motene povezave s storitvami je izbira ponudnika Firebase

najprimernejša.

Primerjava po velikosti zapisov v podatkovni bazi

Pri izbiri ponudnika zalednih mobilnih storitev je za razvijalce pomembna tudi velikost

posameznih zapisov v podatkovni bazi. Na podlagi izvedbe primerjalnih procedur znotraj

implementacije posameznih ponudnikov smo na podlagi enake količine vnesenih podatkov

pridobili končne velikosti podatkovnih baz, če je pri ponudniku to možno.

V Tabeli 7.2 so velikosti podatkovnih baz obravnavanih ponudnikov zalednih storitev po

končani integraciji v razviti mobilni aplikaciji. Zaradi lažje primerjave smo vse podatke

pretvorili v enako enoto za prikaz velikosti podatkov.

Tabela 7.23: Rezultati za velikosti podatkovnih baz.

Ponudnik Velikost podatkovne baze

Azure 6000 Kb

Google Firebase 6,3 kB

Amazon AWS Ni podatka

Backendless 1000 kB

Kinvey 34,3 kB

Iz zgornje tabele je razvidno, da je po kriteriju velikosti podatkovne baze po enaki količini

vstavljenih podatkov najbolj učinkovit ponudnik Google Firebase. Predvidevamo, da je

majhna velikost podatkov povezana s strukturo shranjevanja podatkov v dokumentno

orientirani podatkovni bazi NoSQL. Drugi po učinkovitosti velikosti zapisov v podatkovni

bazi je ponudnik Kinvey, ki kot preostali ponudniki, z izjemo Firebase, za trajno shranjevanje

podatkov uporablja relacijsko podatkovno bazo. Prav tako je prostorsko učinkovit ponudnik


94

Backendless, medtem ko je velikost enakega števila zapisov pri ponudniku Azure največja.

Na portalu za razvijalce ali znotraj analiz pri ponudniku Amazon nismo zasledili podatka o

velikosti podatkovne baze.

Primerjava po zajetih storitev po cenovnem modelu

Pri ponudbi nabora zalednih storitev in uporabljenih računalniških virov je za razvijalce

pomembna cena. Kakor je bilo omenjeno v predstavitvi, ima vsak ponudnik svoje osnovne

cenovne modele, med drugim pa ima večji del ponudnikov zalednih storitev BaaS možnosti

dodatnega zaupa virov oziroma izračun po porabi uporabljenih podatkovnih virov. Za

potrebe raziskovalnega dela in z namenom, da bi zagotovili konsistentno primerjavo, smo

primerjali količino zajetih storitev po brezplačnem cenovnem modelu za razvijalce. V Tabela

7.24 lahko vidimo primerjavo zajetih storitev obravnavanih ponudnikov po enakem

brezplačnem cenovnem razredu. Določeni ponudniki zalednih storitev imajo omejen

časovni rok uporabe brezplačnih storitev.

Tabela 7.24: Primerjava zajetih storitev obravnavanih ponudnikov zalednih storitev.

AZURE FIREBASE AMAZON

AWS

BACKENDLESS KINVEY

Število klicev

API

500.000 20.000 1.000.000 300 1.000

Število aktivnih

naprav

500 100 / 1 1.000

Število

notifikacij push

1.000.00

0

/ 1.000.000 100.000 /

Sinhronizacija

brez povezave

Omejeno Podprto Podprto Ni podprto Podprto

Izdelava

opravil po

urnikih

Omejeno / Podprto Podprto Podprto

Vključena

količina

podatkov v

podatkovni

bazi

20 MB 20 MB 10 GB 5 GB 1 GB


95

Varnostno

kopiranje

Ni

podprto

Ni podprto Podprto Ni podprto Ni

podprto

Iz zgornje tabele je razvidno, da glede na izbrani cenovni model, večji ponudniki, kot so

Azure, Firebase ter Amazon, ponujajo večjo število klicev programskih vmesnikov API, prav

tako, z izjemo ponudnika Firebase, ponujajo največje število poslanih notifikacij push.

Medtem pa manjša ponudnika, kot sta Backendless in Firebase, v svojem brezplačnem

cenovnem razredu ponujata precej večje količine pri shranjevanju podatkov. Kakor je

razvidno iz tabele, je pri večini ponudnikov že v brezplačnem načinu vključena možnost

uporabe aplikacije brez povezave. Da bi lahko izbrali najbolj primernega ponudnika, ki

ponuja v brezplačnem cenovnem modelu največji razpon zalednih storitev, smo

obravnavane ponudnike ovrednotili po točkah. V Tabela 7.25 je kriterij razporeditev točk po

posameznih podatkih, pri čemer 1 točka predstavlja najmanjšo vrednost ponudbe in število

petih točk predstavlja največjo vrednost ponudbe.

Tabela 7.25: Razporeditev točk glede na obravnavane kriterije.

Število točk 1 2 3 4 5

Število klicev API 0–1000 1000–5000 5000–

10000

10000–

50000

50000–

naprej

Število aktivnih

naprav

0–100 100 – 500 500–1000 1000–

5000

5000–

naprej

Število notifikacij

push

0–1000 1000–5000 5000–

10000

10000–

50000

50000–

naprej

Sinhronizacija brez

povezave

Ni podpro Ni podprto Ni podprto Omejeno Podprto

Izdelava opravil po

urnikih

Ni podprto Ni podprto Ni podprto Omejeno Podprto

Vključena količina

podatkov v

podatkovni bazi

0 MB–

100 MB

100 MB–

500 MB

500 MB–

1000 MB

1000 MB

–5000 MB

5000 MB

– naprej

Varnostno

kopiranje

Ni podprto Ni podprto Ni podprto Omejeno Podprto

Na podlagi točkovanja smo glede na posamezen kriterij izvedli deskriptivno statistko s

stopnjo zaupanja 95 %. Tako smo pridobili naslednje rezultate:


96

Število klicev API:

o srednja vrednost: 3,4;

o mediana: 4;

o standardna deviacija: 1,82.

Število aktivnih naprav:


o mediana: 2;


Število notifikacij push:


o mediana: 4;


Sinhronizacija brez povezave:

o srednja vrednost: 4;

o mediana: 5;


Izdelava opravil po urnikih:

o srednja vrednost: 4;

o mediana: 5;


Vključena količina podatkov v podatkovni bazi:


o mediana: 4;


Varnostno kopiranje:


o mediana: 1;


Prav tako smo po enaki statistični metodi primerjali ponudnike glede na posamezen kriterij

in pridobili rezultate, ki so podrobneje predstavljeni v spodnji tabeli (Tabela 7.26) in

grafikonu (Slika 7.7).


97

Tabela 7.26: Rezultati točkovanja ponudbe obravnavanih ponudnikov.

AZURE FIREBASE AMAZON

AWS

BACKENDLESS KINVEY

Seštevek 23 15 31 18 22

Srednja vrednost 3,29 2,14 4,43 2,57 3,14

Mediana 4 1 5 1 4

Standardna

deviacija

1,70 1,68 1,51 1,99 1,77

Slika 7.7: Graf rezultatov točkovanja ponudbe obravnavanih ponudnikov.

Iz zgornjih rezultatov lahko razberemo, da glede na razpon ponudbe, največ storitev

razvijalcem tovrstnih storitev ponuja v brezplačnem cenovnem modelu, ponudnik Amazon

AWS. Srednja vrednost ponudnika 4,43 je prav tako večja od vseh srednjih vrednosti v

primerjavi po posameznih kriterijih, s čimer lahko z gotovostjo potrdimo zgornjo ugotovitev.

Po kriteriju točkovanja, kateri ponudnik ponuja največ, sledita ponudnika Microsoft Azure

ter Kinvey, medtem ko imata ponudnika Backendless in Google Firebase najslabše

vrednosti. Z namenom, da bi ugotovili, ali na podlagi razpona ponudbe obstajajo

signifikantne razlike med obravnavanimi ponudniki, smo izvedli statistično analizo s t-

testom parnih vzorcev s stopnjo zaupanja 95 % in pridobili naslednje rezultate:

t: -0,294;

df: 34;

Sig: 0,770.

0

5

10

15

20

25

30

35

AZURE FIREBASE AMAZON AWS BACKENDLESS KINVEY

Seštevek Srednja vrednost Mediana Standardna deviacija


98

Na podlagi pridobljenih statističnih rezultatov, kjer je absolutna vrednost razlike (vrednost t)

manjša od stopinj svobode (vrednost df), lahko statistično potrdimo, da so obstajajo

signifikantne razlike po kriteriju razpona ponudbe posameznih ponudnikov.

7.3 Rezultati in analiza primerjave

Pri izbiri ponudnika zalednih storitev BaaS se s stališča razvijalcev mobilnih aplikacij

pojavljajo naslednje spremenljivke: hitrost, velikost shranjenih podatkov, težavnost

implementacije, dostopnost, dosegljivost in cena. Kot smo statistično potrdili v prejšnjem

podpoglavju, med ponudniki zalednih storitev obstajajo signifikantne razlike. Na podlagi

predstavitve in primerjave obravnavanih ponudnikov po različnih kriterijih z vidika uporabe

razvijalcev smo ugotovili, da je v primeru potrebe po hitrem dostopu do podatkov najbolj

primerna izbira storitev Firebase. To je najbolj primerna izbira tudi takrat, kadar razvijalci

želijo popoln nadzor nad operacijami ažuriranja podatkov, kadar je dostop do storitev moten

ali prekinjen. Druga izbira glede na hitrost in delo v primeru brez povezave so storitve

ponudnika Kinvey. Vendar sta Kinvey in Firebase primerna zgolj za mobilne aplikacije, ki

ne vsebujejo zahtevne programske logike. Za uporabo spreminjanja posameznih

podatkovnih zapisov in prikazovanja teh na zaslonu mobilne aplikacije je uporaba storitev

ponudnikov Firebase in Kinvey povsem zadovoljiva; v primeru uporabe kompleksnejše

programske logike pa je razvijalcem mobilnih aplikacij priporočena uporaba zalednih

storitev ponudnikov Azure ali Amazon AWS. Navedena ponudnika zraven dostopa do

storitev ponujata širok nabor drugih funkcionalnosti, kot so analize delovanja, analize

porabe, nadzor nad tokom mobilne aplikacije, operiranje z uporabniki in drugo. V primeru

izdelave kompleksnejše aplikacije z večjim naborom funkcionalnosti, ki jo po možnosti

razvija večja skupina razvijalcev, je izbira ponudnika Azure ali Amazon AWS edina pravilna

možnost. V primeru izdelave kompleksnejše mobilne aplikacije in potrebnega zakupa

dodatnih storitev ali računalniških virov bi priporočali izbiro Amazon AWS, ki znotraj

enakega cenovnega razreda ponuja večji nabor storitev. Pri tem pa je treba upoštevati tudi

vidik težavnosti implementacije. Vsak ponudnik zalednih storitev ima na voljo nemoteno

tehnično pomoč in ustrezno referenčno dokumentacijo, ki omogoča razvijalcem lažjo in

hitrejšo integracijo zalednih storitev v želeno mobilno aplikacijo. Pri sami implementaciji

dostopa storitev večje razlike, v primeru najlažje in posledično najhitrejše izdelave končne

različice mobilne aplikacije, bi zlasti razvijalcem ali začetnikom brez izkušenj z uporabo

zalednih mobilnih storitev svetovali uporabo zalednih storitev ponudnika Backendless.


99

8 SKLEP

V magistrskem delu smo se osredinili na koncepte delovanja zalednih storitev za mobilne

aplikacije in pri tem poudarili opaznejše ponudnike. Z vidika razvijalca smo analitično

predstavili njihove lastnosti skozi proces implementacije uporabe storitev v mobilno

aplikacijo. Pri obravnavi ponudnikov smo ugotovili, da je računalništvo v oblaku, zlasti

uporaba mobilnih zalednih storitev, postalo ena najbolj vplivnih tehnologij v industriji

informacijskih tehnologij. Uporaba zalednih storitev računalništva v oblaku je

revolucionarno spremenila način upravljanja in porabe računalniških sredstev. Pametna

uporaba tehnologij virtualizacije na strani ponudnikov storitev omogoča kupcem oziroma

razvijalcem možnost zagon podjetja in realizacijo ideje brez večjih stroškov.

Ugotovili smo, da se obravnavani ponudniki razlikujejo po cenovnih modelih, naboru

ponujenih storitev, načinu implementacije, hitrosti dostopa do storitev in podobno. Prav tako

smo med izdelavo poiskali odgovore na zastavljena raziskovalna vprašanja, predstavljena

v uvodu dela. Odgovore smo pridobili na podlagi pregleda literature ali znotraj

eksperimentalnega dela magistrske naloge.

RV1: Kako se razlikuje arhitektura mobilnih aplikacij, ki uporabljajo zaledne storitve BaaS?

Odgovor: Na podlagi pregledanih virov skozi proces sistematičnega pregleda literature in

analize ponudnikov smo ugotovili, da se arhitektura mobilnih aplikacij, ki uporabljajo dostop

do zalednih storitev, razlikuje od možnosti implementacije dostopa do storitev

posameznega ponudnika. V večini primerov poslovnih aplikacij, ne glede na način

shranjevanja ali branja podatkov, implementacija sledi arhitekturnemu konceptu po pristopu

arhitekture treh slojev [3] [27]. Kot je opisano pri integraciji storitev ponudnika Kinvey, ti

zaradi lažjega vzdrževanja pri večjih projektih priporočajo izdelavo aplikacije po arhitekturi

štirih slojev [64].

RV2: Kateri poslovni model uporabe zalednih storitev BaaS je najbolj razširjen?

Odgovor: Poslovno cenovni model uporabe zalednih storitev je pogojen z zahtevami same

aplikacije. Pri analizi izbranih ponudnikov zalednih storitev smo prikazali različne poslovne

modele. Vsi proizvajalci ponujajo zraven brezplačnega modela tudi napredne modele z

naprej zakupljenimi količinami virov ali storitev, kljub temu pa je glede na potrebe

posamezne aplikacije razvijalcem najbolj ugodna uporaba cenovnega modela »freemium«,

kar vključuje uporabo brezplačnega nabora dostopa do storitev in računalniških virov kot

tudi dodatnega zakupa v primeru porabe zakupljenih virov ali količine storitev.


100

RV3: Kateri ponudnik zalednih storitev BaaS ponuja največji nabor funkcionalnosti?

Odgovor: Iz podanih predstavitev ponudnikov smo dognali, da ponudniki zalednih storitev

glede na cenovne modele ponujajo različne nabore funkcionalnosti. V primeru uporabe

brezplačnih storitev smo na podlagi analize ponudnikov, ki so podrobneje predstavljeni v

prejšnjem poglavju, ugotovili, da največji nabor funkcionalnosti in storitev ponuja ponudnik

storitev Amazon AWS.

RV4: Kateri ponudnik zalednih storitev BaaS je najugodnejši?

Odgovor: Stroški uporabe so pogojeni s kompleksnostjo razvite mobilne aplikacije, pri

čemer večina predstavljenih ponudnikov ponuja možnost dodatnega zakupa količine

računalniških virov ali storitev glede na porabo mobilne aplikacije. Vendar smo na podlagi

vnaprej pripravljenih cenovnih modelov, predstavljenih pri opisu posameznih ponudnikov,

prišli do zaključka, da je glede na količino storitev in ceno za razvijalce najbolj ugoden

ponudnik Amazon AWS.

RV5: Kateri ponudniki zalednih storitev BaaS omogočajo delo brez povezave?

Odgovor: Na podlagi predstavitev posameznih ponudnikov in v procesu integracije

obravnavanih ponudnikov v mobilno aplikacijo smo uvideli, da vsi ponudniki, z izjemo

ponudnika Backendless, omogočajo delo na mobilnih aplikacijah tudi v primeru, ko je

dostop do storitev moten ali prekinjen.

RV6: Kateri ponudnik zalednih storitev BaaS ponuja najhitrejši dostop in procesiranje

podatkov?

Odgovor: Na podlagi pridobljenih rezultatov iz implementacije primerjalnih procedur smo

ugotovili, da je časovno najbolj učinkovita uporaba ponudnika Firebase. Zaradi načina

shranjevanja oblike podatkov so storitve ponudnika Firebase zelo učinkovite tudi zaradi

velikosti podatkov.

Na podlagi podanih odgovorov na raziskovalna vprašanja in analitični primerjavi

ponudnikov smo v okviru raziskovalnega dela želeli z vidika razvijalca najbolje predstaviti

obravnavane ponudnike zalednih storitev, da bi se lahko na podlagi pridobljenih rezultatov

in ugotovitev lažje odločili za ustreznega ponudnika. Za konec naj poudarimo, da je

ustrezna izbira ponudnika odvisna od kompleksnosti mobilne aplikacije, kompetenc in

ustreznega znanja, pa tudi osebnih preferenc razvijalca ali skupine razvijalcev.


101

8.1 Omejitve magistrskega dela

Pri izdelavi eksperimentalnega dela magistrske dela smo se pri predstavitvi ponudnikov

omejili zgolj na storitve ponudnikov, ki si lastijo največji tržni delež ali se najpogosteje

uporabljajo. Pri tem tako s tem namenom nismo zajeli storitev drugih oziroma manj

prepoznavnih ponudnikov s tega področja. Prav tako je uporaba storitev obravnavanih

ponudnikov v večji meri plačljiva, zato smo znotraj raziskovalnega dela imeli na voljo

funkcionalno kot tudi časovno omejene različice razvojnih ogrodij. Pri tem smo se zavedali

tveganja, da rezultati našega raziskovalnega dela tako najverjetneje ne bodo ustrezni za

razvijalce ali skupine z večjimi sredstvi, ki težijo k napredni uporabi celovitega nabora

zalednih storitev posameznega ponudnika. V procesu analize in izvedbe primerjalnih

procedur smo se tudi osredotočili zgolj na delo z eno napravo.

8.2 Predlogi za prihodnje delo

Opravljena obravnava posameznih ponudnikov je v večji meri vezana na količino ponujenih

storitev znotraj brezplačne različice za razvijalce. Zaradi omejitev, omenjenih v predhodnem

podpoglavju, smo predstavili zgolj funkcionalnosti ter nabor predstavitev, ki smo jih lahko

uporabili znotraj omenjenega brezplačnega načina. Znotraj procesa implementacije smo se

v večji meri osredotočili predvsem na uporabo storitev, ki so vezane na shranjevanje,

ažuriranje, nalaganje ali brisanje podatkov, pri tem pa je napredna uporaba same mobilne

aplikacije v načinu brez povezave ostala neizrazita. Za prihodnje delo predlagamo

primerjalno analizo in eksperiment napredne uporabe poslovne logike po meri na strani

strežnika ali z drugo izbrano simulacijo realnega okolja.

Literatura in viri

[1] Y. Z. Yuping Xing, „Future Wireless Networks and Information Systems,“

Virtualization and Cloud Computing, Izv. 143, pp. 305-312, 2012.

[2] LeeGarber, „The Lowly API Is Ready to Step Front and Center,“ Computer, Izv.

46, št. 8, pp. 14-17, 2013.

[3] M. Ott, „Develop and Scale Mobile Services in Cloud Computing Scenarios,“

2013.

[4] W. Kohl, „Backend As A Service - Using the Example of Enginio a Cloud Service

for Qt,“ WS 2013/14, Institute of Distributed Systems, University of Ulm, Ulm,

2013.

[5] D. Rowinski, „Mobile Backend As A Service Parse Raises $5.5 Million in Series A

Funding,“ readwrite, 9 11 2011. [Elektronski]. Available:

http://readwrite.com/2011/11/09/mobile-backend-as-a-service-pa/. [Poskus

dostopa 10 6 2017].

[6] Gartner, „Gartner Says Worldwide Cloud Infrastructure-as-a-Service Spending to

Grow 32.8 Percent in 2015,“ Gartner, [Elektronski]. Available:

http://www.gartner.com/newsroom/id/3055225. [Poskus dostopa 1 9 2016].

[7] V. L. B. J. W. Richard Marshall, „Market Guide for Cloud Mobile Back-End

Services,“ Gartner, 5 3 2015. [Elektronski]. Available:

https://www.gartner.com/document/2999121?ref=solrAll&refval=185830802&qid=

2320e7231e1a9900b24391903341a8ad. [Poskus dostopa 10 6 2017].

[8] J. T. K. G. Elizabeth Golluscio, „Market Guide for Hybrid Integration Platform-

Enabling Technologies,“ Gartner, 25 4 2016. [Elektronski]. Available:

https://www.gartner.com/document/3291720?ref=solrAll&refval=185830802&qid=

2320e7231e1a9900b24391903341a8ad. [Poskus dostopa 10 6 2017].

[9] Amazon, „What is Cloud Computing?,“ Amazon, [Elektronski]. Available:

https://aws.amazon.com/what-is-cloud-computing/. [Poskus dostopa 1 9 2016].

[10] R. Baburajan, „The Rising Cloud Storage Market Opportunity Strengthens

Vendors,“ TMCnet.com, [Elektronski]. Available:

http://technews.tmcnet.com/viewette.aspx?u=http%3a%2f%2ftechnews.tmcnet.co

m%2fchannels%2fcloud-storage%2farticles%2f211183-rising-cloud-storage-

market-opportunity-strengthens-vendors.htm. [Poskus dostopa 24 8 2016].

[11] J. Wray, „Where's The Rub: Cloud Computing's Hidden Costs,“ Forbes,

[Elektronski]. Available: Where's The Rub: Cloud Computing's Hidden Costs.

[Poskus dostopa 25 8 20016].

[12] Y. Luo, „Network I/O Virtualization for Cloud Computing in Plastics,“ IT

Professional, Izv. 12, pp. 536-541, 2010.

[13] G. Čehovin, „Računalništvo v oblaku: fleksibilnejši dostop do računalniških

storitev,“ mladipodjetnik.si, 20 2 2011. [Elektronski]. Available:

http://mladipodjetnik.si/podjetniski-koticek/poslovanje/racunalnistvo-v-oblaku-

fleksibilnejsi-dostop-do-racunalniskih-storitev. [Poskus dostopa 24 8 2016].

[14] A. Mohamed, „A history of cloud computing,“ CcomputerWeekly, [Elektronski].

Available: http://www.computerweekly.com/feature/A-history-of-cloud-computing.


[15] CloudBuzz, „History of Cloud Computing,“ CloudTweaks, 9 2011. [Elektronski].

Available: http://cloudtweaks.com/2011/02/a-history-of-cloud-computing/. [Poskus

dostopa 25 8 2016].

[16] M. Crnkovič, „Analiza slovenskega trga ponudnikov storitev v oblaku za podjetja,“

2014.

[17] GeminiStyle.si, „Storitve in ponudniki računalništva v oblaku,“ GeminiStyle.si,

[Elektronski]. Available:

http://www.geministyle.si/print/racunalnistvo/splosno/racunalnistvo-v-oblaku-

6.html. [Poskus dostopa 27 8 2016].

[18] S. Angels, „Virtualization vs. Cloud Computing: What's the Difference?,“ Business

News Daily, [Elektronski]. Available: http://www.businessnewsdaily.com/5791-

virtualization-vs-cloud-computing.html. [Poskus dostopa 27 8 2016].

[19] T. Navarro, „The Difference Between Cloud Computing And Virtualization,“ 7 maj

2014. [Elektronski]. Available: https://www.computenext.com/blog/the-difference-

between-cloud-computing-and-virtualization/. [Poskus dostopa 27 8 2016].

[20] N. Martin, „Virtualization vs. cloud: Let's get this straight,“ TechTarget,


http://searchservervirtualization.techtarget.com/feature/Virtualization-vs-cloud-

Lets-get-this-straight. [Poskus dostopa 27 8 2016].

[21] B. Consulting, „Cloud Computing,“ [Elektronski]. Available:

http://www.barkatconsulting.com/consolidation-and-virtualization/. [Poskus

dostopa 4 6 2017].

[22] A. Shields, „Overview: Cloud computing services and deployment models,“ 23 7

2014. [Elektronski]. Available: http://marketrealist.com/2014/07/must-know-cloud-

computing-services-and-models/. [Poskus dostopa 4 6 2017].

[23] S. Sridhar, „Mobile Cloud Backend as a Service Ecosystem Map – All roads lead

to BaaS,“ 9 2 2012. [Elektronski]. Available: https://www.kinvey.com/mobile-cloud-

backend-as-a-service-ecosystem-map-all-roads-lead-to-baas/. [Poskus dostopa

15 8 2016].

[24] S. Sridhar, „Welcome to the World of Backend as a Service,“ Kinvey, 25 5 2011.

[Elektronski]. Available: https://www.kinvey.com/welcome-to-the-world-of-

backend-as-a-service/. [Poskus dostopa 27 8 2016].

[25] M. Panhale, Beginning Hybrid Mobile Application Development, Apress, 2015.

[26] „Solving the Cloud Computing Impasse with MBaaS,“ SIGCSE '16, pp. 721-721,

2016.

[27] J. A. J. D. E. C. F. A. S. P. M. Igor Costa, „Availability Evaluation and Sensitivity

Analysis of a Mobile Backend-as-a-service Platform,“ Quality and Realiability

Engineering International, Izv. 32, št. 7, pp. 2191-2205, 2015.

[28] A. Soinu, „Cloud Solutions for Mobile Applications,“ Tampere University of Applied

Sciences, 2014.

[29] A. Tan, „FatFractal ups the ante in backend-as-a-service market,“ Techgoondu,

30 9 2012. [Elektronski]. Available:

http://www.techgoondu.com/2012/09/30/fatfractal-ups-the-ante-in-backend-as-a-

service/. [Poskus dostopa 28 7 2016].

[30] M. Rouse, „mobile backend as a service (mobile BaaS),“ TechTarget,


http://searchmobilecomputing.techtarget.com/definition/mobile-Backend-as-a-

Service-mobile-BaaS. [Poskus dostopa 28 7 2016].

[31] backendless, „WHAT IS BACKEND AS A SERVICE?,“ backendless, [Elektronski].

Available: https://backendless.com/what-is-backend-as-a-service/. [Poskus

dostopa 28 7 2016].

[32] AndroidNames, „List of the Best Mobile Backend as a Service (mBaaS)

Providers,“ AndroidNames, 15 6 2016. [Elektronski]. Available:

http://www.androidnames.com/development/list-of-the-best-mobile-backend-as-a-

service-mbaas-providers/. [Poskus dostopa 28 7 2016].

[33] AndroidBegin, „List of the best Android Backend as a Service (BaaS) provider,“ 1

4 2014. [Elektronski]. Available: http://www.androidbegin.com/blog/list-best-

android-backend-service-baas-provider/. [Poskus dostopa 20 9 2016].

[34] B. D. S. Siripathi, „Back-End as a Service for Mobile Apps,“ envatotuts+, 5 3

2017. [Elektronski]. Available: https://code.tutsplus.com/articles/back-end-as-a-

service-for-mobile-apps--cms-28154. [Poskus dostopa 31 5 2017].

[35] M. Azure, „What is Azure?,“ [Elektronski]. Available:

https://azure.microsoft.com/en-us/overview/what-is-azure/. [Poskus dostopa 10 9

2016].

[36] S. Martin, „Upcoming Name Change for Windows Azure,“ Microsoft, 24 3 2014.

[Elektronski]. Available: https://azure.microsoft.com/en-us/blog/upcoming-name-

change-for-windows-azure/. [Poskus dostopa 10 9 2016].

[37] Microsoft, „Azure,“ [Elektronski]. Available: https://azure.microsoft.com/en-

us/?v=17.23h. [Poskus dostopa 10 9 2016].

[38] L. Welicki, „Announcing Azure Portal general availability,“ Microsoft, 2 12 2015.

[Elektronski]. Available: https://azure.microsoft.com/en-us/blog/announcing-azure-

portal-general-availability/. [Poskus dostopa 10 9 2016].

[39] Microsoft, „Mobile Services Pricing,“ Microsoft, [Elektronski]. Available:

https://azure.microsoft.com/en-us/pricing/details/mobile-services/. [Poskus

dostopa 10 9 2016].

[40] F. Lardinois, „Google turns Firebase into its unified platform for mobile

developers,“ TechCrunch, [Elektronski]. Available:

https://techcrunch.com/2016/05/18/google-turns-firebase-into-its-unified-platform-

for-mobile-developers/. [Poskus dostopa 12 9 2016].

[41] G. C. Platform, „Mobile Solutions - The Mobile Cloud Era,“ [Elektronski]. Available:

https://cloud.google.com/solutions/mobile/. [Poskus dostopa 11 9 2016].

[42] G. Fireabase, „Firebase - Pricing Plans,“ [Elektronski]. Available:

https://firebase.google.com/pricing/. [Poskus dostopa 24 5 2017].

[43] S. J. Vaughan-Nichols, „PCMAG - Google Cloud Platform,“ [Elektronski].

Available: http://www.pcmag.com/article2/0,2817,2496296,00.asp. [Poskus

dostopa 15 02 2017].

[44] Amazon, „Amazon Web Services - About AWS,“ [Elektronski]. Available:

https://aws.amazon.com/about-aws/. [Poskus dostopa 27 8 2016].

[45] B. Black, „http://blog.b3k.us/,“ [Elektronski]. Available:

http://blog.b3k.us/2009/01/25/ec2-origins.html. [Poskus dostopa 27 8 2016].

[46] Amazon, „AWS Mobile Services,“ Amazon, [Elektronski]. Available:

https://aws.amazon.com/mobile/. [Poskus dostopa 12 9 2016].

[47] J. Varia, „Build Your Mobile App Faster with AWS Mobile Services,“ [Elektronski].

Available: http://www.slideshare.net/AmazonWebServices/build-your-mobile-app-

faster-with-aws-mobile-services. [Poskus dostopa 1 9 2016].

[48] T. Hoff, „Amazon Architecture,“ [Elektronski]. Available:

http://highscalability.com/amazon-architecture. [Poskus dostopa 10 3 2017].

[49] Amazon, „Amazon Free Tier,“ [Elektronski]. Available:

https://aws.amazon.com/free/. [Poskus dostopa 12 9 2016].

[50] Backendless, „Backendless platform,“ [Elektronski]. Available:

https://backendless.com/products/. [Poskus dostopa 5 3 2017].

[51] J. Novet, „15 alternatives to Facebook’s Parse,“ 29 1 2016. [Elektronski].

Available: http://venturebeat.com/2016/01/29/15-alternatives-to-facebooks-parse/.


[52] Backendless, „BACKENDLESS CLOUD FUNCTIONAL LIMITS,“ [Elektronski].

Available: https://backendless.com/pricing/backendless-cloud-functional-limits/.


[53] Backendless, „API Engine Documentation,“ [Elektronski]. Available:

https://backendless.com/documentation/api-engine/apieng_overview.htm. [Poskus

dostopa 5 3 2017].

[54] M. Gienow, „Backendless is a Badass MBaaS,“ 7 10 2016. [Elektronski].

Available: https://thenewstack.io/backendless-badass-baas/. [Poskus dostopa 5 3

2017].

[55] I. Widjaya, „Backend as a Service (BaaS): Kinvey Review,“ CLOUD BIZ

REVIEWS, [Elektronski]. Available: http://www.cbrdigital.com/2012/02/13/what-is-

backend-as-a-service-baas.html. [Poskus dostopa 12 3 2017].

[56] Crunchbase, „Kinvey,“ [Elektronski]. Available:

https://www.crunchbase.com/organization/kinvey#/entity. [Poskus dostopa 12 3

2017].

[57] Kinvey, „Backend as a Service vs. API Management,“ [Elektronski]. Available:

http://d1cqpkecg5rwnz.cloudfront.net/docs/API+Management+vs.+BaaS+-

+A+Kinvey+Whitepaper.pdf. [Poskus dostopa 15 3 2017].

[58] Kinvey, „Mobile Cloud Reference Architecture for Enterprise,“ [Elektronski].

Available: https://d1cqpkecg5rwnz.cloudfront.net/docs/kinvey-mobile-reference-

architecture.pdf. [Poskus dostopa 15 3 2017].

[59] Kinvey, „Kinvey Pricing,“ [Elektronski]. Available: https://www.kinvey.com/pricing/.


[60] Microsoft, „Why Mobile Apps?,“ [Elektronski]. Available:

https://docs.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-

value-prop. [Poskus dostopa 12 3 2017].

[61] Amazon, „Java Annotations for DynamoDB,“ [Elektronski]. Available:

http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDB

Mapper.Annotations.html#DynamoDBMapper.Annotations.DynamoDBDocument.


[62] Kinvey, „Kinvey Platform,“ [Elektronski]. Available:

https://www.kinvey.com/platform/. [Poskus dostopa 12 3 2017].

[63] Kinvey, „Why you need a new mobile architecture,“ [Elektronski]. Available:

https://www.kinvey.com/platform/. [Poskus dostopa 15 3 2017].

[64] R. O'Connor, „Mobile Development Platform: The 4-Tier Architecture for

Success,“ Kinvey, 26 1 2017. [Elektronski]. Available:

https://www.kinvey.com/mobile-development-platform-4-tier-architecture-success/.


ANALIZA IN PRIMERJAVA OBLAČNIH STORITEV ZA RAZVOJ …

Documents

Transcript of ANALIZA IN PRIMERJAVA OBLAČNIH STORITEV ZA RAZVOJ …