Razvoj informacijskih rešitev v oblaĊni arhitekturi · SOA Storitveno-usmerjena arhitektura...

Martin Potočnik

RAZVOJ INFORMACIJSKIH REŠITEV V OBLAČNI ARHITEKTURI

Diplomsko delo

Maribor, februar 2010

I

Diplomsko delo univerzitetnega študijskega programa


Študent: Martin Potočnik

Študijski program: UN ŠP – računalništvo in informatika

Smer: Informatika

Mentor: red. prof. dr. Matjaţ B. Jurič

Lektorica: Joţica Lorenci, prof.

Maribor, februar 2010

III

ZAHVALA

Zahvaljujem se mentorju - red. prof. dr. Matjaţu B.

Juriču - za pomoč in vodenje pri pisanju diplomskega

dela. Prav tako se zahvaljujem vsem kolegom iz

laboratorija za računalniško posredovano

komunikacijo, posebej Gregorju Srdiću in Marcelu

Kriţevniku.

Posebna zahvala velja staršem Manji in Mitji, ki so mi

omogočili študij, bratu Jerneju in dekletu Tini za

podporo pri študiju in pri pisanju naloge. Hvala tudi

Joţici Lorenci, prof., ki je diplomsko delo lektorirala.

IV


Ključne besede: Računalništvo v oblaku, IBM WebSphere, SOA, SCA, SaaS

UDK: 004.777:005(043.2)

Povzetek

Diplomsko delo predstavlja računalništvo v oblaku in celovit pristop k razvoju informacijskih

rešitev, ki so primerne za izvajanje v oblaku. Predstavili smo koncepte, razvoj, vrste,

ponudnike, prednosti, slabosti, izzive in arhitekturo računalniškega oblaka ter opisali vse

vrste storitev, ki nam jih ponuja. Na kratko smo opisali in umestili storitveno-usmerjeno

arhitekturo (SOA) in storitveno komponentno arhitekturo (SCA), ki predstavljata optimalen

arhitekturni pristop za razvoj sodobnih informacijskih rešitev. Raziskali in opisali smo celovit

razvojni cikel in metodologijo razvoja novodobnih poslovnih rešitev, ki izkoriščajo vse

prednosti računalniškega oblaka. Podrobno smo predstavili platformo IBM WebSphere (IBM

WebSphere CloudBurst Appliance in IBM WebSphere Application Server Hypervisor Edition)

ter opisali namestitveni cikel v virtualnem IBM oblaku. Zadnji del diplomskega dela obsega

praktični primer razvoja arhitekture in delne implementacije aplikacije SkyInfo z uporabo

orodij IBM WebSphere.

V

DEVELOPMENT OF IT SOLUTIONS USING CLOUD ARCHITECTURE

Key words: Cloud computing, IBM WebSphere, SOA, SCA, SaaS

UDK: 004.777:005(043.2)

Abstract

The following final work presents cloud computing and comprehensive approach to

developing modern information systems, which can run in the »cloud«. We describe concepts

of cloud computing, its history, types, providers, advantages and disadvantages, challenges,

architecture and all types of cloud computing services. We also briefly we describe concepts

of service-oriented architecture (SOA) and service component architecture (SCA), which offer

an optimal architectural approach to development of cloud solutions. We also define their

role in cloud computing model. Furthermore we study and present a methodology which

defines a comprehensive development cycle that constantly supports and guides software

architects and developers in the right direction so their newly developed applications can

exploit the full potential of cloud infrastructure. We take a more detailed look at IBM

WebSphere platform (mainly IBM WebSphere CloudBurst Appliance and IBM WebSphere

Application Server Hypervisor Edition). We also present IBM deployment cycle, which covers

establishment of a virtual cloud environment and deployment of IT solutions into the newly

formed cloud. We use the obtained theoretical knowledge on a design of innovative cloud

application SkyInfo and on implementation of some SkyInfo services that run on IBM

WebSphere platform.

VI

VSEBINA

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

1.1 Pomen informacijskih rešitev in računalništva v oblaku ............................................. 1

1.2 Cilji diplomskega dela ................................................................................................. 2

1.3 Opis poglavij in strukture diplomskega dela ............................................................... 2

2 Računalništvo v oblaku ...................................................................................................... 3

2.1 Definiranje in umestitev računalništva v oblaku ......................................................... 3

2.2 Zgodovina in nastanek računalništva v oblaku ............................................................ 6

2.3 Oblačna arhitektura ...................................................................................................... 8

2.3.1 Moţni prehodi v oblačno arhitekturo ................................................................... 8

2.3.2 Topologija računalniškega oblaka ...................................................................... 10

2.3.3 Tehnologije računalniškega oblaka .................................................................... 11

2.3.4 Storitve in modeli oblačne infrastrukture ........................................................... 13

2.3.4.1 SaaS - programska oprema kot storitev....................................................... 13

2.3.4.2 PaaS – platforma kot storitev ...................................................................... 15

2.3.4.3 IaaS – Infrastruktura kot storitev ................................................................. 16

2.3.4.4 CaaS in MaaS .............................................................................................. 18

2.3.5 Podatkovne shrambe v oblaku ............................................................................ 19

2.3.6 Tipi oblakov ........................................................................................................ 22

2.3.6.1 Javni oblaki ................................................................................................. 22

2.3.6.2 Zasebni oblaki ............................................................................................. 22

2.3.6.3 Hibridni oblaki ............................................................................................ 23

2.4 Lastnosti računalništva v oblaku ................................................................................ 24

2.5 Varnost računalništva v oblaku .................................................................................. 26

2.5.1 Varnostni izzivi .................................................................................................. 26

VII

2.5.2 Varnostni mehanizmi .......................................................................................... 29

2.6 Primerjava velikih ...................................................................................................... 31

2.6.1 Google ................................................................................................................ 31

2.6.2 EMC ................................................................................................................... 31

2.6.3 Microsoft ............................................................................................................ 32

2.6.4 Amazon ............................................................................................................... 33

2.6.5 Salesforce.com .................................................................................................... 33

2.6.6 IBM ..................................................................................................................... 34

2.6.7 Primerjava ........................................................................................................... 35

3 Storitveno usmerjena arhitektura ...................................................................................... 36

3.1 Kaj je SOA? ............................................................................................................... 36

3.1.1 Tehnologije SOA ................................................................................................ 37

3.1.1.1 Skupno storitveno vodilo ............................................................................ 37

3.1.1.2 Kompozicija poslovnih storitev in BPEL.................................................... 38

3.1.2 SCA .................................................................................................................... 39

3.2 SOA in računalništvo v oblaku .................................................................................. 42

4 Razvoj aplikacij za oblak .................................................................................................. 44

4.1 Nivo podatkov ............................................................................................................ 44

4.1.1 Definiranje problemske domene ......................................................................... 45

4.1.2 Definiranje informacijskega modela .................................................................. 45

4.2 Nivo storitev .............................................................................................................. 47

4.2.1 Definiranje storitev ............................................................................................. 48

4.2.2 Pomen šibke sklopljenosti storitev ..................................................................... 49

4.2.3 Metastoritve in imenik storitev ........................................................................... 50

4.3 Nivo procesov ............................................................................................................ 51

4.3.1 Definiranje procesov........................................................................................... 51

VIII

4.3.2 BPM .................................................................................................................... 52

4.4 Nivo vodenja oz. upravljanja ..................................................................................... 52

4.5 Pogled na testiranje .................................................................................................... 53

4.6 Spletne aplikacije v oblaku ........................................................................................ 54

4.7 Problem stanj in zagotavljanje podatkovne integritete .............................................. 55

4.8 Načrtovanje strojne slike ........................................................................................... 57

5 Platforma IBM za razvoj oblačnih rešitev ........................................................................ 58

5.1 IBM WebSphere CloudBurst Appliance ................................................................... 58

5.2 IBM WebSphere Application Server Hypervisor Edition ......................................... 61

5.3 IBM WebSphere Process Server ................................................................................ 62

5.4 IBM WebSphere Enterprise Service Bus ................................................................... 62

6 Razvoj arhitekture SkyInfo in implementacija storitve TrustService na platformi IBM . 64

6.1 Predstavitev problema ................................................................................................ 64

6.2 Ideja ........................................................................................................................... 65

6.2.1 Dodatne razširitve ............................................................................................... 66

6.2.2 Opis delovanja sistema SkyInfo ......................................................................... 67

6.3 SkyInfo arhitektura .................................................................................................... 68

6.3.1 Podatkovni model ............................................................................................... 69

6.3.2 Model storitev ..................................................................................................... 73

6.3.2.1 DatabaseService .......................................................................................... 74

6.3.2.2 SkyInfoService ............................................................................................ 74

6.3.2.3 LoginService ............................................................................................... 74

6.3.2.4 ProcessorService ......................................................................................... 75

6.3.2.5 AnalyzerService in TrustService ................................................................. 75

6.3.2.6 SMSService in RuleApplierService ............................................................ 75

6.3.3 Preslikava podatkovnega modela v poslovni objektni model ............................ 75

IX

6.3.4 Definiranje vmesnikov in operacij ..................................................................... 77

6.3.5 Vmesnik TrustService ........................................................................................ 78

6.3.5.1 Operacija calculateTrust .............................................................................. 78

6.3.5.2 Operacija updateTrust ................................................................................. 79

6.4 Implementacija TrustService ..................................................................................... 81

6.5 Povzetek razvoja arhitekture in delne implementacije aplikacije SkyInfo ................ 83

7 SKLEP .............................................................................................................................. 84

8 VIRI .................................................................................................................................. 86

9 PRILOGE ......................................................................................................................... 88

9.1 Seznam slik ................................................................................................................ 88

9.2 Seznam tabel .............................................................................................................. 89

9.3 Seznam izvorne kode ................................................................................................. 90

9.4 TrustFactorByTimeCalculator.java ........................................................................... 90

9.5 TrustFactorByFeedbackCalculator.java..................................................................... 91

9.6 TrustService.calculateTrust ....................................................................................... 92

9.7 TrustService.updateTrust ........................................................................................... 93

9.8 Rezultati simulacije vpliva povratne informacije ...................................................... 94

9.9 Naslov študenta .......................................................................................................... 96

9.10 Kratek ţivljenjepis.................................................................................................. 96

X

UPORABLJENE KRATICE

ISP Ponudnik internetnih storitev (angl. Internet Service Provider)

VM Navidezni oz.virtualni stroj (angl. Virtual Machine)

P2P Omreţje enakovrednih gostiteljev (angl. Peer-To-Peer)

SaaS Programska oprema kot storitev (angl. Software as a Service)

PaaS Platforma oprema kot storitev (angl. Platform as a Service)

IaaS Infrastruktura kot storitev (angl. Infrastructure as a Service)

CaaS Komunikacija kot storitev (angl. Communications as a Service)

MaaS Nadzor kot storitev (angl. Monitoring as a service)

CMS Upravljavec programske opreme v oblaku (angl. Cloud Management Software)

SMB Streţniški blok sporočila (angl. Server Message Block )

NFS Omreţni datotečni sistem (angl. Network File System)

SUPB Sistem za upravljanje s podatkovno bazo

QoS Lastnosti in upravljavci, ki zagotavljajo določen nivo storitev (angl. Quality of Service)

SOA Storitveno-usmerjena arhitektura (angl. Service-Oriented Architecture)

SCA Storitvena kompontna arhitektura (angl. Service Component Architecture)

SLA Del pogodbe, kjer so definirani nivoji storitev (angl. Service Level Agreement)

SDLC Razvojni cikel (angl. Systems Development Life Cycle)

DMZ Strogo nadzorovano omreţje z natančno definirano politiko (angl. Demilitarized Zone)

ESB Skupno storitveno vodilo (anlg. Enterprise Service Bus)

SRR Rregister in repozitorij storitev (angl. Service Registry and Reposirtory)

BPM Upravljanje poslovnih procesov (angl. Business Process Management)

BPMN Jezik za modeliranje procesov (angl. Business Process Modeling Notation)

BPEL Izvajalni jezik za poslovne procese (angl. Business Process Execution Language)

BAM Nadzor poslovnih procesov(angl. Business Activity Monitoring)

UDDI Javni imenik poslovnih storitev (angl. Universal Description, Discovery and Integration)

SDLC Razvojni cikel (angl. Systems Development Life Cycle)

WAS Aplikacijski streţnik – (angl. IBM WebSphere Application Server)

WPS Procesni streţnik – (angl. IBM WebSphere Process Server)

WID razvojno orodje – (angl. IBM WebSphere Integration Developer)

WCBA Strojni upravljavec virtualnih oblakov - (angl. IBM WS CloudBurst Appliance)

WAS-HE Prirejen IBM-ov aplikacijski streţnik - (angl. IBM WS Application Server Hypervisor Edition)

WAS-HE Prirejen IBM-ov aplikacijski streţnik - (angl. IBM WS Application Server Hypervisor Edition)

BO Poslovni objekt - (angl. Business Object)

KT Faktor zaupanja (angl. trust factor)

Razvoj informacijskih rešitev v oblačni arhitekturi Stran 1

1 UVOD

1.1 Pomen informacijskih rešitev in računalništva v oblaku

V razvoju modernih informacijskih rešitev je danes veliko govora o konceptu storitveno

usmerjene arhitekture, ki elegantno povezuje poslovni svet z informacijsko tehnologijo.

Vrzeli med poslovnimi procesi in njihovimi informacijskimi rešitvami koncept SOA1

zapolnjuje tako, da predstavlja poslovne procese v obliki povezanih, čim bolj neodvisnih

storitev, ki realizirajo posamezne dele procesa in v osnovi operirajo nad informacijami.

Danes, imajo informacije veliko vrednost, a za uspešno poslovanje potrebujemo veliko več

kot le pomembne informacije.

V dobi nenehne povezljivosti ţelimo, da so nam točne informacije dostopne vedno in povsod.

Poleg tega mora biti dostop do njih varen in nadzorovan. Ključnega pomena je tudi deljenje

informacij, kar lahko v realnem času predstavlja problem. Če se postavimo v vlogo

informacijskega sistema in te zahteve oz. ideje preslikamo nase, se pojavijo teţave

(dostopnost, zanesljivost, povezljivost, varnost, shranjevanje podatkov). V zgodovini so se

takšni problemi reševali z mnogimi tipi arhitektur, kot so streţnik-odjemalec, P2P2,

distribuirani sistemi ipd.

Tehnologija nam danes omogoča elegantno rešitev v obliki oblačne arhitekture, kjer storitve

oz. poslovne procese preslikamo nivo višje – v oblak. Poleg skalabilne tehnološke

infrastrukture nam oblak nudi tudi podlago za realizacijo informacijskih rešitev, ki so lahko

na varen način dostopne vedno in povsod. Tako doseţemo tudi povezljivost z drugimi

storitvami in informacijskimi sistemi, kar predstavlja moţnost za enostavno sodelovanje,

1 storitveno usmerjena arhitektura

2 Peer-to-peer pomeni omreţje enakovrednih gostiteljev.


integracijo in nadzorovano deljenje informacij. Računalništvo v oblaku nam torej ponuja nov

način in novo ogrodje za razvijanje informacijskih rešitev. Kako razviti inovativne

informacijske sisteme v oblaku in kakšen tip oblačne arhitekture uporabiti? Kakšne so

prednosti in slabosti računalništva v oblaku? Rešitev v oblaku ne reši vseh omenjenih

problemov, lahko pa jih na inteligenten način minimizira in včasih odpravi.

1.2 Cilji diplomskega dela

Osnovna cilja diplomske naloge sta: prvič – definirati, predstaviti in umestiti računalništvo v

oblaku ter drugič – razloţiti razvoj storitveno usmerjenih informacijskih rešitev v oblačni

arhitekturi. Namen je, podrobno predstaviti oblačno arhitekturo (njene koncepti, lastnosti,

prednosti in slabosti), razvoj informacijskih rešitev na platformi IBM (IBM WAS Hypervisor

Edition in IBM WebSphere CloudBurst Appliance) ter prikazati celoten cikel razvoja na

praktičnem primeru aplikacije SkyInfo. Diplomska naloga bo prispevala k razumevanju

računalništva v oblaku in razvoju informacijskih rešitev v oblačni arhitekturi.

1.3 Opis poglavij in strukture diplomskega dela

Prvo poglavje diplomskega dela predstavlja uvod, v katerem so opisani cilji in splošno

področje raziskav. V drugem poglavju prikazujemo zgodovino, arhitekturo, tipe storitev,

podatkovne shrambe, topologije, lastnosti in varnost računalništva v oblaku. V tretjem

poglavju sta predstavljena modela SOA in SCA, razloţena pa je tudi povezava med

računalništvom v oblaku in SOA. Četrto poglavje predstavlja celovit pristop k razvoju

sodobnih aplikacij, ki se lahko izvajajo v računalniškem oblaku. Opisani so podatkovni,

storitveni in procesni nivo ter nivo vodenja oz. upravljanja. Obravnavana sta tudi model

sodobnih spletnih aplikacij in problem stanja oz. zagotavljanja podatkovne integritete. V

petem poglavju je predstavljena platforma IBM za razvoj oblačnih storitev, posebej IBM

WebSphere CloudBurst Appliance in IBM WebSphere Application Server Hypervisor

Edition. Šesto poglavje obravnava praktični primer – razvoj aplikacije SkyInfo, ki zajema

predstavitev problema, idejno rešitev, postopen razvoj arhitekture (podatkovni model,

poslovni objekti, vmesniki, storitve, rešitev) in delno implementacijo. Sledijo zaključek,

seznami slik, tabel, izvorna koda, uporabljenih virov in literature.


2 RAČUNALNIŠTVO V OBLAKU

V tem poglavju bomo skušali razloţiti in definirati pojem računalništva v oblaku. Razloţili

bomo vse glavne njegove koncepte, lastnosti, prednosti in slabosti. Opisali bomo tudi

zgodovino nastanka oblačnega računalništva ter predstavili njegovo arhitekturno zasnovo.

Razloţili bomo problematiko varnosti in opisali nekaj največjih današnjih ponudnikov

storitev v oblaku.

2.1 Definiranje in umestitev računalništva v oblaku

V svetu nenehnega razvoja, kjer nove tehnologije prihajajo in odhajajo iz dneva v dan, se v

računalništvu uveljavlja nov trend, ki pa namesto hitrega vzpona in zatona obljublja

dolgoţivost. Ta trend je tako imenovano računalništvo v oblaku (angl. cloud computing), ki

bo najverjetneje spremenil način uporabe računalnika in medmreţja (1). Besedo računalništvo

v oblaku smo v zadnjih dveh letih lahko slišali ali prebrali skorajda povsod. Kaj točno

računalništvo v oblaku torej pomeni?

Beseda »oblak« je po eni strani mišljena kot metafora za medmreţje, ki se ţe dolgo uporablja

v diagramih omreţij, kjer ikona oblaka predstavlja neko delujočo celoto, ki vsebuje vse

potrebno za svoje delovanje. Kot to prikazuje leva stran slike 2.1, običajno oblak pomeni tudi

del diagrama, za katerega sami ne odgovarjamo, smo pa z njim povezani, saj se oblak

uporablja za prenos podatkov od nas in do nas (2).

Po drugi strani pa beseda »oblak« pomeni več kot le priročno metaforo za medmreţje. Res je,

da je medmreţje potreben pogoj oz. temelj za računalništvo v oblaku, ni pa tudi zadosten

pogoj. Kot prikazuje desna stran slike 2.1, oblak v kontekstu računalništva v oblaku pomeni

več kot le medmreţje – pomeni virtualen prostor, kjer uporabnik uporablja tehnologijo, kadar


jo potrebuje in kolikor dolgo jo potrebuje. To tehnologijo (programsko in/ali strojno opremo)

zagotavljajo ISP oz. ponudnik internetnih storitev in podjetja, ki ponujajo oblačno

infrastrukturo3 in oz. ali oblačne storitve

4. Medmreţje se torej uporablja za povezljivost med

uporabniki in storitvami v oblaku, vse ostalo upravlja računalniški oblak.

Slika 2.1: Primerjava kontekstov »oblaka«

Kot smo ţe omenili, lahko računalništvo v oblaku pomeni programsko ali strojno opremo –

prvič lahko gre za aplikacije, do katerih dostopamo preko medmreţja, drugič pa pomeni

streţnike, ki jih uporabljamo, kadar jih potrebujemo. V obeh primerih storitev (programskih

ali strojnih) gre za oblačno storitev, ko lahko do storitve dostopamo iz vsakega računalnika, ki

ima dostop v medmreţje, neodvisno od nameščenega operacijskega sistema in brskalnika (3).

Koncept oblaka uvaja korenite spremembe v načinu shranjevanja in upravljanja s podatki in

aplikacijami, ki niso več nameščene na uporabnikovi strojni opremi, ampak so na voljo v

oblaku, do katerega uporabnik dostopa preko medmreţja. Takšen način uporabe programske

opreme omogoča laţje sodelovanje in nadzor nad podatki. Spreminjata se tudi način uporabe

in upravljanje z računalniškimi viri, ki jih lahko uporabljamo, kadar ţelimo (na zahtevo).

3 Oblačna infrastruktura pomeni strojno opremo, ki jo lahko najamemo in uporabljamo.

4 Oblačna storitev je storitev, ki upošteva vsa načela računalništva v oblaku in jo lahko uporabljamo.

Medmrežje

Zunanji strežniki

Storitve, podatki, varnost

Povezljivost

Usmerjevalnik

Stikalo

Odjemalci

Lokalni strežniki

Podatki, varnost

Medmrežje

Odjemalci

Povezljivost

Varnost, storitve, aplikacije, podatki in infrastruktura

Računalniški oblak


Če povzamemo, je računalništvo v oblaku v osnovi vse, kar vključuje medmreţno dostavo

storitev, ki se v celoti nahajajo v oblaku in ne pri uporabniku. Fizično to predstavlja skupino

med seboj povezanih računalnikov, ki so lahko osebni računalniki ali streţniki. V večini

primerov za uporabnike niti ni pomembno, kje natančno oblak (podatki in aplikacije) je.

Za primer si lahko pogledamo Googlov oblak, ki ga sestavljajo majhni osebni računalniki in

veliki streţniki. Oblak je privaten (v lasti Googla), je pa javno dostopen, kar pomeni, da lahko

vsi Googlovi uporabniki do njega dostopajo in ga uporabljajo. Google opiše šest glavnih

lastnosti računalništva v oblaku tako:

Računalništvo v oblaku je uporabniško usmerjeno (angl. user-centric) – ko se

uporabnik poveţe v oblak in začne upravljati s podatki (dokumenti, slike, sporočila,

aplikacije ipd.), postanejo ti podatki njegovi. Poleg tega je omogočeno deljenje

podatkov z drugimi uporabniki in napravami, ki imajo dostop do oblaka.

Računalništvo v oblaku je opravilno usmerjeno (angl. task-centric) – v ospredju niso

aplikacije in njihove funkcionalnosti, ampak problemi oz. opravila, ki morajo biti

izvedena in način, kako lahko aplikacije ta opravila uspešno izvedejo.

Računalništvo v oblaku pomeni veliko računsko moč – ko poveţemo stotine ali tisoče

računalnikov v oblak pridobimo veliko računsko moč, ki ni primerljiva z močjo nekaj

streţnikov ali osebnih računalnikov.

Računalništvo v oblaku pomeni dostopnost – če imamo podatke shranjene v oblaku

pomeni, da lahko do njih dostopamo povsod (pogoj je le dostop do medmreţja).

Računalništvo v oblaku je inteligentno – zaradi velike količine podatkov, ki so

shranjeni v oblaku, so podatkovno rudarjenje in podobne analize nujne, da lahko

inteligentno dostopamo do informacij, ki nas zanimajo. Inteligentne operacije, ki so v

večini primerov časovno zahtevne, se zaradi velike računske moči lahko izvajajo

hitreje in učinkoviteje.

Računalništvo v oblaku je programirljivo – veliko opravil za upravljanje oblaka je

avtomatiziranih (varnostni mehanizmi, zagotavljanje podatkovne integritete,

distribucija podatkov ipd.) – te avtomatizirane rutine so seveda programirljive,

nekatere celo avto-programirljive5.

5 Avto-programirljive rutine so rutine, ki se ob napaki znajo same ustrezno reprogramirati.


Našteli smo šest lastnosti, ki jih Google postavlja v ospredje (1), vendar lahko dodamo še

nekaj pomembnih lastnosti, ki so opisane v razdelku 2.4.

2.2 Zgodovina in nastanek računalništva v oblaku

Da lahko dobro razumemo koncepte računalništva v oblaku, je pomembno spoznati njihovo

zgodovino. Če pogledamo predhodne koncepte in probleme, s katerimi so se ti soočali, bomo

laţje razumeli teţave in izzive, s katerimi so se ukvarjali pionirji računalništva v oblaku.

Hkrati bomo bolje razumeli koncepte in lastnosti, ki oblake definirajo. Vsi predhodniki

računalništva v oblaku imajo skupno točko – gre za centraliziranje podatkov, ki olajša

sodelovanje in uporabo podatkov, in za način, kako več računalnikov povezati tako, da

delujejo kot celota z veliko računsko močjo.

V osemdesetih letih je bil popularen model odjemalec-streţnik (angl. client-server), ki je

prikazan na sliki 2.2. Vse aplikacije in vsi podatki ter kontrola oz. upravljanje z njimi so bili

na streţnikih. Kadar je uporabnik hotel dostopati do podatkov ali uporabljati aplikacijo, se je

moral najprej povezati s streţnikom (večinoma terminalski dostop), nato pa je moral pridobiti

ustrezna dovoljenja, ki so mu omogočila izvajanje svojih opravil. Podatke ali aplikacije si je

odjemalec v bistvu izposojal od streţnika, zato takšnemu modelu pravimo tudi gospodar-

suţenj (angl. master-slave). Prednost takšnega koncepta je centraliziranost v smislu podatkov,

aplikacij in varnosti oz. nadzora dostopa. Slabosti so netakojšni dostop, nezmoţnost hkratne

uporabe istih podatkov, počasno delovanje (zlasti, če je streţnik uporabljalo veliko število

odjemalcev), pomanjkanje robustnosti (če pride do napake na streţniku, je delo onemogočeno

za vse odjemalce) in nezmoţnost prilagajanja; odjemalec ima na voljo podatke in aplikacije,

ki jih streţnik ponuja, in nič več. Čeprav je model na prvi pogled podoben modelu

računalništva v oblaku glede na centralizacijo podatkov, aplikacij in načina dostopa, model

odjemalec-streţnik ni bil uporabniško usmerjen, ampak je vse uporabne storitve upravljal

streţnik, kar pomeni, da uporabnik ni mogel spreminjati streţniškega okolja ali aplikacij.

Ţelja po vsaki spremembi je bila posredovana do nadzornikov streţnika, ki so jo obravnavali,

sami implementirali, testirali in šele nato ponudili odjemalcem. Kmalu je postalo jasno, da

takšen način povezovanja računalnikov ni najboljši, saj mora vsa komunikacija med

odjemalci potekati preko streţnika.


Slika 2.2: Shema modela odjemalec-streţnik

Očitno rešitev je predstavljala arhitektura omreţja, prikazana na sliki 2.3, v kateri so vsi

računalniki (odjemalci) med seboj neposredno povezani. Tako je nastalo omreţje P2P, ki je

uvedlo koncept enakovrednosti, saj so bili vsi odjemalci v omreţju enakovredni. Vsak

računalnik je bil hkrati streţnik in odjemalec. Kot posledica je nastalo decentralizirano

omreţje odjemalcev, ki so lahko med seboj neposredno komunicirali in si izmenjevali

podatke. Pomembna podmnoţica modela P2P je koncept distribuiranega računalništva,

katerega namen je uporaba računalnikov, ki so povezani v omreţje, a jih trenutno nihče ne

uporablja ali potrebuje. Takšne računalnike lahko uporabimo za procesno intenzivne projekte

in operacije (1).

Slika 2.3: Shema modela enakovrednih gostiteljev oz. P2P

Strežnik (podatki in aplikacije)

Zvezdišče

Odjemalci (terminali)

Enakovredni gostitelji (hkratni odjemalci in strežniki)


Zaradi zmoţnosti učinkovitega komuniciranja se je porodila ideja o zdruţevanju računalnikov

v gručo (tako imenovano grozdenje), ki bi tvorila celovito računalniško enoto z veliko

računsko močjo. Računalniki so med seboj komunicirali in si s posebnimi protokoli

uravnavali procesno oz. računsko breme. V zgodnjih devetdesetih letih pa sta Ian Foster in

Carl Kesselman vpeljala nov koncept - mreţo računalnikov (angl. the grid), ki ga lahko

razumemo kot električno omreţje, kamor se odjemalec priklopi in merjeno črpa energijo.

Takšna računalniška mreţa razširi koncept grozdenja, kjer velike in neodvisne gruče tvorijo

mreţo, ker niso na isti lokaciji oz. v isti domeni. Pomemben faktor učinkovitosti je

predstavljala lokacija podatkov, nad katerimi se je izvajalo procesiranje. Dalje kot so bili

podatki, večja je bila latenca oz. čas med pridobivanjem podatkov in izvajanjem operacij nad

njimi. Upravljanje s podatki (varnost in premikanje podatkov) v konceptu mreţnega

računalništva je v zgodnjih devetdesetih letih postalo velik izziv, posebej zaradi preslabe

tehnologije, ki ni bila dovolj zanesljiva za velik korak naprej – za migracijo poslovnih in

industrijskih aplikacij ter podatkov v mreţo. V zadnjih letih pa je postala tehnologija dovolj

zrela, da so vodilne IT-korporacije in drugi investitorji začeli vlagati veliko kapitala v razvoj

računalništva v oblaku, ki razširja koncept mreţnega računalništva z več vrstami storitev (4).

Oblak kot na zunaj atomarna enota ponuja celotno in agilno infrastrukturo za deljenje

podatkov, vzpostavitev aplikacijskih ogrodij, v katerih se izvajajo aplikacije, in paralelno ter

distribuirano procesiranje.

2.3 Oblačna arhitektura

V tem razdelku bomo pogledali moţne načine prehoda v oblačno arhitekturo, ugotovili kaj

sestavlja računalniški oblak, in opisali njegove glavne značilnosti, lastnosti, prednosti in

slabosti.

2.3.1 Možni prehodi v oblačno arhitekturo

Če pred opisom oblačne arhitekture na hitro pogledamo, kaj nas čaka v bliţnji prihodnosti,

lahko iz slike 2.4 razberemo, da vsi moderni koncepti poslovnih računalniških arhitektur

konvergirajo k modelu oblaka. Temeljni razlogi za to so zdruţevanje dobrih lastnosti sedanjih

modelov, niţanje stroškov, agilnost in dostopnost. Poti, po katerih lahko prestopimo v


koncept oblaka, je več; od modela odjemalec-streţnik obstajajo tri moţnosti:

Od VM k oblaku: uporabniki oz. organizacije, ki uporabljajo navidezne oz. virtualne

stroje za izvajanje svojih aplikacij, lahko zdruţijo streţnike in ustvarijo virtualno

gručo streţnikov (angl. virtual cluster). Z rastjo te gruče, z avtomatskim

dodeljevanjem računalniških virov in z dinamičnim uravnavanjem računskega

bremena se virtualna gruča spremeni v privatni oblak, ki je pod okriljem organizacije

(5).

Od distribuiranih mreţ k oblaku: organizacije, ki uporabljajo distribuirane mreţe,

imajo pred seboj večje izzive, ker tehnologije navideznih strojev niso namenjene

mreţam, kjer lahko ena aplikacija zasede vse razpoloţljive vire. Teţave se pojavljajo

tudi zaradi moţnega paralelnega delovanja aplikacij. Za prestop je potreben CMS

(angl. Cloud Management Software) 6

, ki generalizira mreţo in s tem podpre več tipov

aplikacij, ter produkti za avtomatizacijo podatkovnih centrov, ki zagotavljajo celovito

integriteto, ki je v oblaku nujna (5).

Od namiznih računalnikov k oblaku: uporabniki oz. organizacije se lahko odločijo, da

ne bodo uporabljali lastne infrastrukture, ampak bodo za svoje aplikacije, podatke in

procesiranje le-teh najeli del oblaka, ki ga ponudniki oblačnih storitev ponujajo. S tem

se izognejo slabim lastnostim lastne statične infrastrukture – stroškom vzdrţevanja,

varovanja in ozkih grl (5). To omogoča virtualizacija, ki je opisana kasneje.

Slika 2.4: Konvergenca smernic razvoja računalniških arhitektur (5)

6 CMS je programska oprema za upravljanje z oblakom.


Za uspešen prehod v oblačno arhitekturo je potrebnih veliko korakov, ki so rezultati zahtev po

agilnosti, skalabilnosti, minimizaciji stroškov, avtomatizaciji poslovnih procesov ipd. S

stališča strojne opreme je tehnologija sicer na voljo, manjkajo samo še dobre CMS-rešitve za

učinkovito upravljanje z oblaki; mnogo jih je še v razvojnih fazah, nekatere pa se ţe

uporabljajo.

2.3.2 Topologija računalniškega oblaka

Kot prikazuje slika 2.4, topologijo računalniškega oblaka sestavljajo:

odjemalci,

podatkovni center (angl. datacenter) in

distribuirani streţniki.

Odjemalci so v oblačni arhitekturi enaki odjemalcem v lokalnem omreţju. Strojno gledano je

odjemalec lahko namizni ali prenosni računalnik, mobilni telefon, PDA ipd. Odjemalci so

naprave s katerimi uporabniki dostopajo in uporabljajo oblak. Razdelimo jih lahko tako:

mobilni odjemalci – mobilni telefon, PDA, pametni telefon;

tanki ali lahki odjemalci (angl. thin clients) – računalniki, ki nimajo internih

podatkovnih diskov in prepuščajo vsa opravila streţnikom;

debeli ali teţki odjemalci (angl. thick clients) – normalni računalniki, ki za dostop do

oblaka uporabljajo medmreţne brskalnike.

Vedno popularnejši postajajo tanki odjemalci, ki zagotavljajo niţje stroške strojne opreme,

niţje stroške vzdrţevanja, varnost aplikacij in podatkov, manjšo električno porabo, laţjo

zamenljivost itd.

Podatkovni center pomeni mnoţico streţnikov, kamor se podatki in aplikacije odjemalcev

namestijo. Današnji trend je virtualizacija, kar pomeni, da lahko namestimo več neodvisnih

instanc virtualnih streţnikov na en fizični streţnik. Oblačni podatkovni center mora poskrbeti

za varnost, integriteto in dajanje informacij, dinamično prilagajanje potrebnih računalniških

virov za učinkovito izvajanje opravil ipd.

Distribuirani streţniki predstavljajo streţnike, ki so sicer na različnih geografskih lokacijah, a


za uporabnika delujejo uniformno in celovito. Koncept distribucije podatkov je pomemben

del računalništva v oblaku, saj tako zagotovimo optimalne čase izvajanja aplikacij in

posledično razbremenimo tudi omreţje, poleg tega pa ta koncept predstavlja tudi osnovo za

varnost podatkov (kopije istih podatkov na več lokacijah) in dostopnost (2).

2.3.3 Tehnologije računalniškega oblaka

Obstaja več načinov, kako lahko strukturiramo računalniški oblak. Tehnološka infrastruktura

je v veliki meri odvisna od namena uporabe. Če torej vnaprej poznamo namen uporabe

oblaka, si ga lahko v veliki meri prilagodimo tako, da nam čim bolj ustreza. To je tudi

pomembna prednost uporabe oblaka za njegovega lastnika in za končne uporabnike.

Kot smo ţe omenili, je mreţno računalništvo obetavna tehnologija, saj podpira deljenje dela

na manjše enote, ki se na več računalnikih procesirajo ločeno. Takšen model je učinkovit, če

potrebujemo veliko računsko moč za majhno število projektov, a je v nasprotju s konceptom

računalništva v oblaku, ki podpira veliko število majhnih aplikacij, ki se izvajajo istočasno.

Za računalništvo v oblaku je najprimernejša tehnologija navideznih strojev ali virtualizacija.

Prva moţnost je tehnika popolno navideznih streţnikov (angl. full virtualization) ali popolna

virtualizacija, kar predstavlja sistem, v katerem se vsa programska oprema izvaja v streţniških

okoljih, ki so nameščena na navidezni streţnik. Takšna infrastruktura ne podpira samo

izvajanja več aplikacij, ampak tudi različne operacijske sisteme. Virtualizacija je v

računalništvu v oblaku pomembna, ker je eden od načinov dostopa do oblačnih storitev;

oddaljen podatkovni center nam lahko dostavlja oblačne storitve v popolnoma navideznem

formatu. Za popolno virtualizacijo potrebujemo specifično strojno opremo, kot sta AMD-V7

in IVT8. Najbolj primerna je:

za deljenje računalniških virov med več uporabnikov in

za izoliranje uporabnikov in posnemanje strojne opreme (angl. hardware emulation).

7 AMD-V je okrajšava za AMD-Virtualization

8 IVT je okrajšava za Intel Virtualization Technology


Druga moţnost je tehnika delne navideznosti (angl. paravirtualization) ali delna

virtualizacija, ki omogoča istočasno izvajanje več operacijskih sistemov na enem kosu strojne

opreme. Od popolne virtualizacije, kjer se posnema celoten sistem (BIOS, pogoni itd.), se

delna virtualizacija razlikuje pri upravljanju operacijskih sistemov. Za upravljanje se

uporablja poseben upravljalni modul (angl. management module), ki optimizira uporabo

računalniških virov. Delna virtualizacija je tudi hitrejša, ker se ne posnema celotnega sistema,

ampak samo višji del operacijskega sistema. Hitrost se pridobi na račun manjše fleksibilnosti

(moţno je, da nekateri operacijski sistemi ne delujejo) in manjše varnosti (gostujoči

operacijski sistem ima večjo kontrolo nad strojno opremo, od katere so odvisni vsi

odjemalčevi operacijski sistemi in s tem tudi njihovi podatki in aplikacije). Kot lahko vidimo

v tabeli 2.1, je delna virtualizacija učinkovitejša, ker ima sistem samo 2 % reţije. Pri popolni

virtualizaciji isti sistem potrebuje 10 % procesorske moči samo za reţijo, kar pri petih

instancah nanese kar 50 %. V primeru, ki ga je prikazan v tabeli, lahko v istem oblaku

gostimo 3 instance več, če uporabljamo delno virtualizacijo, preden začne učinkovitost oblaka

padati.

Tabela 2.1: Poraba procesne moči pri popolni in delni virtualizaciji (2)

Tip virtualizacije Gostujoče

instance

Režija

virtualizacije

Potrebe po

računalniških virih

Skupaj

Popolna virtualizacija 5 10 % (skupaj 50 %) 10 % (skupaj 50 %) 100 %

Delna virtualizacija 8 2 % (skupaj 16 %) 10 % (skupaj 50 %) 96 % (80 % + 16 %)

Delna virtualizacija deluje najbolje, kadar potrebujemo:

učinkovito ponovno vzpostavitev sistema (aplikacije in podatki) ob odpovedi sistema

ali ob naravnih katastrofah;

enostavno migracijo – premik odjemalčevih instanc na drugo strojno opremo;

enostavno upravljanje s kapacitetami – laţje dodajanje procesne moči ali podatkovnih

enot zaradi enostavne migracije.

Ugotovili smo, da je virtualizacija temelj za učinkovito uporabo strojne opreme v oblaku, ki

odjemalcem ponuja oblačne storitve, ki jih bomo opisali v naslednjem razdelku.


2.3.4 Storitve in modeli oblačne infrastrukture

Preden lahko razumemo razvoj informacijskih rešitev v oblaku, moramo razumeti, da

obstajajo različni infrastrukturni modeli računalništva v oblaku, ki ponujajo različne oblačne

storitve. Na začetku je oblak nudil aplikacije (npr. Saleforce.com – CRM), kasneje se je

izoblikovala ponudba infrastrukture v oblaku (npr. Amazon AWS – Infrastructure service

through web service interface), sedaj pa obstajajo tudi platforme v oblaku (npr. Windows

Azure). Vsi trije aspekti se med seboj razlikujejo, vendar imajo tudi skupno točko –

plačljivost storitev je neposredno povezana z učinkovito in realno uporabo najetih storitev.

Beseda storitev v računalništvu v oblaku je dejansko koncept, ki pomeni zmoţnost ponovne

uporabe neke komponente preko omreţja. Ta koncept (imenovan »kot storitev« ali angl. »as a

service«) ima definirane lastnosti, kot so visoka skalabilnost, strojna neodvisnost in enostavno

vključevanje in uporaba. Kot je prikazano na sliki 2.5, osnovni sklad današnjega računalništva

v oblaku sestavljajo trije tipi storitev: SaaS, PaaS in IaaS (6).

Slika 2.5: Sklad, ki predstavlja računalništvo v oblaku (6)

2.3.4.1 SaaS - programska oprema kot storitev

SaaS ali programska oprema kot storitev predstavlja aplikacijski nivo, kjer so aplikacije

nameščene v oblaku in odjemalci do njih dostopajo preko omreţja. Če je aplikacija

nameščena v oddaljenem oblaku, to za odjemalca pomeni, da mu ni treba skrbeti za aplikacijo

SaaS(programska oprema kot storitev)

PaaS(platforma kot storitev)

IaaS(infrastruktura kot storitev)


in njeno vzdrţevanje. Tudi za strojno opremo in njeno vzdrţevanje skrbi ponudnik SaaS.

Odjemalec ne plača lastništva aplikacije, ampak plačuje njeno uporabo, zato odjemalcu

pravimo tudi najemnik (angl. tenant). Modelu, pri katerem več odjemalcev uporablja isto

instanco aplikacije pravimo, večkratno-najemna arhitektura (angl. multitenant architecture)

(1). Aplikacije SaaS se od prejšnjih distribuiranih informacijskih rešitev najbolj razlikujejo po

tem, da so aplikacije razvite za specifično spletno uporabo, za npr. medmreţni brskalnik, kar

pomeni, da so spletne »narave« (angl. web-native). Aplikacije so prav tako zgrajene tako, da

podpirajo sočasno večkratno uporabo (2). SaaS postaja vedno bolj popularen zaradi

dozorevanja tehnologij, kot so spletne storitve in SOA, o kateri bom tudi pisal v naslednjih

poglavjih. V tabeli 2.2 je prikazan Microsoftov zrelostni model štirih vrst arhitektur SaaS.

Tabela 2.2: Microsoftova zrelostna klasifikacija SaaS arhitektur (7)

Nivo Opis

Nivo 1: ad-hoc To je nedozorel nivo, kjer ima vsak uporabnik unikatno verzijo gostujoče

aplikacije. Za prenos tradicionalne oz. običajne aplikacije na ta nivo ni

potrebno vloţiti veliko truda.

Nivo 2: konfigurabilnost Nivo konfigurabilnosti daje večjo fleksibilnost s pomočjo metapodatkov.

Odjemalci lahko uporabljajo ločene instance iste aplikacije. Ponudniki

lahko za vsakega odjemalca podrobno konfigurirajo aplikacijo. Tudi

posodobitve se lahko izvajajo ločeno in neodvisno od drugih instanc iste

aplikacije.

Nivo 3: večkratno najemanje Večkratno najemanje pomeni, da lahko ponudnik SaaS eno instanco

aplikacije uporablja za vse odjemalce. S tem se optimizira poraba

računalniških virov. Zunanji odjemalec ne opazi razlike med drugim in

tem nivojem, ima pa ta nivo pomanjkljivost – arhitektura ima omejeno

rast oz. skalabilnost.

Nivo 4: skalabilnost Skalabilnost je dodana z uporabo večslojne arhitekture, ki podpira

uravnavanje procesorskega bremena na distribuiranih streţnikih, kjer se

lahko izvajajo identične instance aplikacije. Potrebne kapacitete se lahko

odvisno od procesnega bremena dinamično povečajo ali zmanjšajo.

Glavne karakteristike oz. lastnosti SaaS so:

mreţni način upravljanja in dostopanja do programske opreme,

dostava aplikacij po modelu ena-proti-mnogo (1 instanca, večkratno-najemna

arhitektura) in

centralizirano posodabljanje nadgrajevanja brez posega odjemalca (7).


2.3.4.2 PaaS – platforma kot storitev

Platforma kot storitev je, tako kot SaaS, model za dostavo storitev, ki pa niso v obliki

aplikacij, ampak razvojnega okolja, ki ga ponudniki ponudijo za razvoj aplikacij. Razvoj

informacijskih rešitev je tako olajšan, ker pridobimo ţe definirane module ali kose, ki jih pri

razvoju lahko uporabimo. PaaS torej nudi vse, kar potrebujemo za razvoj aplikacij ali storitev

preko medmreţja – razvijalec na svoji strani ne potrebuje ničesar. Takšen model omogoča

hitrejši in cenejši razvoj aplikacij. Odjemalec tudi pri PaaS plača to, kar uporablja in nič več.

Model lahko najdemo v štirih vrstah sistemov (2):

Dodatni razvojni pripomočki (angl. add-on development facilities) – gre za razširitev

modela SaaS z moţnostjo prilagajanja. Velikokrat razvijalci PaaS zakupijo dodatke

aplikacij SaaS, s katerimi pridobijo moţnost prilagajanja.

Samostojna okolja – okolja, ki ne vključujejo nikakršnih licenc, tehničnih ali finančnih

odvisnosti od aplikacij SaaS. Uporabna so za splošen razvoj in testiranja.

Izključno gostujoča okolja – okolja, ki so namenjena izključno gostovanju aplikacij in

vključujejo posebne storitve za varnost, skalabilnost na zahtevo.

Odprta platforma – razvijalec ni omejen s programskimi jeziki, podatkovnimi bazami,

operacijskimi sistemi ipd.

Slika 2.6 prikazuje vse elemente storitve PaaS, ki poleg celotnega cikla razvoja podpira tudi

storitve SaaS, kot so virtualna pisarna, storitve za sodelovanje ipd.

Slika 2.6: Elementi, ki sestavljajo storitev tipa PaaS

PaaS

RazvojNačrtovanje

Modeliranje

Razvoj

Testiranje

Gostovanje

SaaS

Virtualna pisarna

Storitve za sodelovanje

Storitve za integracijo podatkov

Storitve za zagotavljanje

varnosti

Storitve za upravljanje

stanj


Glavne značilnosti PaaS torej vključujejo storitve za načrtovanje, modeliranje, razvoj,

testiranje in gostovanje aplikacije. Ponudniki PaaS običajno ponudijo tudi orodja za razvoj

spletnih grafičnih vmesnikov. Razvijalcu ni treba skrbeti za sinhronizacijo in upravljanje

aplikacije ob sočasni uporabi več odjemalcev. Pomembna značilnost je podpora integraciji s

spletnimi storitvami in podatkovnimi bazami. Kot pomoč pri razvoju se uporabljajo tudi

nekatere storitve SaaS, ki pa so odvisne od ponudnika (7).

K slabostim, ki jih prinaša model SaaS, bi tukaj dodal še večjo odvisnost od ponudnika oz.

»vendor lock-in«, saj ponudniki uporabljajo lastniške storitve ali programske tehnike. Tudi če

ponudnik odobrava migracijo, so lahko stroški visoki. Nivo prenosljivosti podatkov je zelo

pomemben faktor pogodbe SLA.

2.3.4.3 IaaS – Infrastruktura kot storitev

Najniţji nivo storitev, ki ga obravnava računalništvo v oblaku, je IaaS oz. storitve v obliki

infrastrukture, nekateri mu pravijo tudi HaaS (2). Wikipedia definira IaaS kot dostavo

računalniške infrastrukture, kot storitev, pri kateri gre običajno za najem virtualnega okolja

(8). Medtem ko SaaS in PaaS ponujata aplikacijske storitve, IaaS ne ponuja aplikacij ali

oblačne platforme, ampak strojno opremo, ki podpira vse koncepte računalništva v oblaku. Za

razliko od tradicionalnega najemanja strojne opreme, ki zahteva veliko skrbnosti in pogajanj,

ob spremembah in premajhni agilnosti pa prihaja tudi do zapletov se IaaS raje osredotoča na

model, v katerem se standardna infrastruktura priredi posebnim zahtevam odjemalca, kar

minimizira potencialne zaplete (7). Ponudniki IaaS torej poskrbijo za pravilno in učinkovito

delovanje infrastrukture.

Danes lahko na model IaaS gledamo iz dveh zornih kotov:

IaaS kot infrastrukturne storitve – storitve v obliki zagotavljanja učinkovite strojne

opreme in pripadajoče programske opreme. Infrastrukturo lahko uporabimo za več

aplikacij ali pa za opravila, ki so časovno zahtevna in potrebujejo veliko računalniških

virov. Ponudnik IaaS ponuja celotno infrastrukturo – aplikacijske streţnike, shrambe

podatkov, podatkovne streţnike, sporočilne vrste, streţnike za uravnavanje prometa,

strojno in programsko opremo za varnost ipd.


IaaS kot oblačni centri – tukaj gre za standardne podatkovne centre, kjer se

uporabljajo standardna tehnologija in protokoli, vendar se center obnaša kot oblak.

Podatkovne shrambe so dostopne preko protokolov SMB9 in NFS

10, za podatkovne

baze se uporabljajo standardni povpraševalni jeziki in SUPB. Poţarni zidovi in

upravljanje s procesorskimi bremeni so odvisni od strojne opreme in ne od posebne

programske opreme.

Kot odjemalec se moramo odločiti, ali bomo sprejeli drugačno infrastrukturo s svojimi

protokoli in standardi ali pa bomo uporabili storitve IaaS bolj tradicionalnega tipa, ki

prinašajo skoraj iste prednosti, vendar upoštevajo industrijske standarde (3). Slika 2.7

prikazuje vse elemente IaaS.

Slika 2.7: Elementi, ki sestavljajo storitve tipa IaaS

Glavne značilnosti IaaS so:

celovita infrastruktura za računalništvo v oblaku (slika 2.7),

dinamično povečanje oz. pomanjšanje infrastrukture v odvisnosti od potrebe po

računalniških virih,

spremenljivi stroški (strošek je odvisen od časa uporabe virov in količine uporabljanih

virov) in

sočasno večkratno najemanje na isti infrastrukturi.

9 SMB - streţniški blok sporočila.

10 NFS – omreţni datotečni sistem, ki ga je razvil Sun.

IaaSStrojna oprema

•Mreža strežnikov

•Velika horizontalna skalabilnost

Omrežje

•Usmerjevalniki

•Požarni zidovi

•Uravnavanje prometa

Medmrežje

•Običajno OC 192 (10 Gbps)

Okolje za virtualizacijo

•Nadzor in upravljanje virtualizacije

•Sočasno izvajanje več neodvisnih virtualnih strojev

SLA (angl. Service-Level Agreements) oz. pogodba med ponudnikom in odjemalcem

Sistem za obračunavanje storitev


Kot odjemalcu nam IaaS torej ponuja alternativo lastni infrastrukturi, pri kateri moramo samo

poskrbeti za varnost, nadgradnje, vzdrţevanje ipd.

Najeta infrastruktura v obliki IaaS ima kar nekaj prednosti (7):

dostop vnaprej nastavljenega okolja, ki je običajno skladen z ITIL11

,

uporaba najmodernejše tehnologije,

niţji stroški in manj potrebnega časa za dodajanje novih tehnologij ali funkcionalnosti,

varno okolje, ki je običajno nadzorovano,

centralizacija vseh podatkov in aplikacij,

zmoţnost obravnavanja velikega povečanja uporabe,

niţji stroški infrastrukture usmerijo sredstva v kvalitetnejše storitve in

plačevanje »po porabi«.

2.3.4.4 CaaS in MaaS

CaaS ali komunikacija kot storitev pomeni celovite komunikacijske storitve v oblaku, kot so

VoIP, IM in video konference. Celovite komunikacijske storitve so storitve, za katere v celoti

(strojna in programska oprema) poskrbi ponudnik CaaS, ki mora zagotavljati tudi

dogovorjeno kvaliteto storitev ali QoS, ki je v skladu s SLA. Odjemalec komunikacijske

storitve plača po uporabi, kar je zanj zelo ugodno (Gartner12

napoveduje 105-odstotno rast do

leta 2011). Razširjeni model CaaS vsebuje tudi multimedijske konference in integracijo

elektronskih sporočil. Glavne prednosti CaaS so manjši stroški, saj ne potrebujemo lastne

infrastrukture za komuniciranje, zanesljivost in kvaliteto delovanja.

MaaS ali nadzor kot storitev pomeni uporabo nadzornih storitev, ki imajo moţnost nadzora,

varovanja in opazovanja poslovnih procesov. Najpomembnejši faktor MaaS je celovita

varnost in zaščita, ki mora zagotavljati zaupnost, integriteto in nenehno razpoloţljivost IT

virov. Varovanje in zaščita sta danes zelo pomembna IT-faktorja, vendar zahtevata veliko

11

ITIL – ogrodje, ki vključuje dobre prakse, ki zagotavljajo kvaliteto storitev v IT sektorju.

12 Vir: Gartner Press Release, »Gartner Forecasts Worldwide Communications-as-a-Service Revenue to Total

$252 Million in 2007”, avgust 2007, obiskano 8. februarja 2010.


znanja, časa in discipline, kar pomeni tudi visoke stroške. Oblačna arhitektura ponuja odličen

način nadzora in varovanja, bodisi samo podatkov bodisi tudi aplikacij.

2.3.5 Podatkovne shrambe v oblaku

Shranjevanje podatkov v oblaku je zelo pomemben del računalništva v oblaku, saj predstavlja

temelj za uporabo SaaS in PaaS. Koncept shranjevanja podatkov v oblaku je sicer zapleten, a

ima mnogo prednosti pred običajnim, lokalnim shranjevanjem podatkov. Prva prednost je

dostopnost, saj so podatki v primerni obliki na voljo povsod, kjer imamo dostop do

medmreţja. Druga prednost je varnost, s katero se odjemalcu ni potrebno ukvarjati, saj za njo

poskrbijo varnostni mehanizmi oblaka. Tretja prednost sta enostavna razširljivost (kar za

odjemalca pomeni samo dodaten strošek pri obračunavanju storitve) in enostavnejše

nadzorovano deljenje podatkov, četrta pa predstavlja moţnost hitrega in laţjega izvajanja

analiz oz. poslovne inteligence, saj lahko oblak nudi veliko procesno moč, kadarkoli jo

potrebujemo. Za shranjevanje podatkov v oblaku obstaja veliko sistemov, ki se lahko med

seboj zelo razlikujejo. Po eni strani najdemo enostavne rešitve (angl. niche-oriented) za

shranjevanje elektronske pošte ali digitalnih fotografij, po drugi strani pa najdemo

kompleksne rešitve, ki so sposobne hraniti podatke vseh tipov. Prava shramba podatkov v

oblaku zagotavlja tudi redundanco, integriteto in ustrezno varnost podatkov. Primarna

redundanca podatkov je realizirana z več kopijami istih podatkov (avtomatizirana replikacija)

na več streţnikih, ki so med seboj neodvisni, hkrati pa so priključeni na neodvisne tipe

električnih napajanj. Sekundarna redundanca podatkov pa pomeni tudi geografsko ločitev

streţnikov, kar poleg varnosti izboljša učinkovitost (podatki so bliţje virom, ki jih

potrebujejo). Vse te lastnosti so razlog, da danes ţe večina velikih podjetij uporablja

»oblačno« tehnologijo vsaj za shranjevanje podatkov. Shranjevanju podatkov v oblaku lahko

rečemo tudi shramba podatkov kot storitev (angl. Storage as a Service), ker ponudniki

ponujajo prostor za shranjevanje in vso potrebno tehnologijo (2). Današnji popularni

ponudniki, ki omogočajo shranjevanje enostavnih podatkov v računalniškem oblaku, so:

Google Docs – shranjevanje in urejanje dokumentov, preglednic ipd.,

Gmail, Hotmail, Yahoo! – shranjevanje elektronske pošte in priponk,

Flickr, Picasa – shranjevanje digitalnih fotografij, generiranje albumov ipd.,

YouTube, Hostmonster, GoDaddy, Facebook, MySpace … (9)


Shranjevanje bolj kompleksnih podatkov in večji nadzor nad njimi pa nudijo:

Amazon - Amazon Simple Storage Service ali krajše Amazon S3,

Nirvanix – CloudNAS,

EMC – Cloud Optimized Storage,

Google – Gdrive in IBM – Smart Business Storage Cloud.

Zdruţene značilnost in lastnosti navedenih ponudnikov podatkovnih shramb v oblaku so:

visoka varnost podatkov, njihova decentralizacija, podpora asinhronemu delovanju,

avtonomija, lokalna odgovornost, podpora sočasnosti, odpornost na napake, vzporedno

delovanje, zmoţnost dekompozicije večjih opravil in enostaven uvoz oz. izvoz podatkov.

Kot vidimo, so prednosti, ki jih prinaša računalništvo v oblaku za shranjevanje podatkov,

velike, vendar je pomembno omeniti, da običajne podatkovne baze niso popolnoma zdruţljive

z vsemi načeli računalništva v oblaku. Velik problem predstavlja dinamično dodeljevanje

računalniških virov, česar danes ne podpira veliko podatkovnih streţnikov. Ker so podatkovne

baze osnova za vsako večjo aplikacijo ali informacijsko rešitev, bomo značilnosti

podatkovnih baz, ki so primerne za računalništvo v oblaku, predstavili.

Podatkovne baze lahko iz oblaka ponudimo podobno kot programsko opremo, platformo ali

infrastrukturo – kot storitev (DaaS ali podatkovna baza kot storitev). Ker moderne poslovne

aplikacije v oblaku uporabljajo modele transakcij, morajo podatkovne baze v celoti podpirati

ACID. Kot smo ţe omenili, morajo oblačne podatkovne baze podpirati dinamično

skalabilnost, za to pa veliko današnjih podatkovnih baz ni zmoţnih zaradi arhitekture (angl.

shared-nothing architecture), ki razdeli podatke na več delov. Zakaj predstavlja to problem,

naj pojasni preprost primer. Imamo dva podatkovna streţnika, na vsakem 50 % podatkov, in

ţelimo dodati še en podatkovni streţnik. V idealnem primeru bi predstavljali rezultat trije

podatkovni streţniki (na vsakem 33 % podatkov), vendar nastane problem, kadar so podatki

med seboj povezani in odvisni. Poizvedovanje po takšnem sistemu bi bilo daleč od

optimalnega, zato mora biti razdeljevanje podatkov realizirano na inteligenten način. Ker sta

delitev podatkov in koncept računalništva v oblaku neskladna, so Amazon, Facebook in

Google razvili lastne programske rešitve, ki niso skladne z ACID, ampak replicirajo tabele

podatkov, po katerih lahko poizvedujemo in ki podpirajo dinamično skalabilnost. Te rešitve

dejansko niso podatkovne baze in ne obvladujejo poslovnih zahtev računalništva v oblaku (9).


Idealna arhitekturna rešitev podatkovnih baz za računalništvo v oblaku je tako imenovana

arhitektura deljenih podatkovnih enot (angl. shared-disk architecture), ki dovoljuje uporabo

istih podatkov celi gruči streţnikov. Podatke običajno hrani SAN ali NAS13

in niso deljeni.

Glavna prednost takšne arhitekture je podpora dinamični skalabilnosti ali »elastičnost«, poleg

tega pa zagotavlja manjše število streţnikov (sploh za redundanco), boljšo izkoriščenost,

enostavnejši plačilni sistem, enostavnejše nadgrajevanje in vzdrţevanje, niţje stroške podpore

in višjo razpoloţljivost (vozlišča so med seboj neodvisna) (9). Za enostavno in učinkovito

uporabo vsake podatkovne baze potrebujemo dober SUPB. To velja tudi v računalništvu v

oblaku. Slika 2.8 prikazuje delitev podatkovnih baz glede na to, če spadajo med relacijske

podatkovne baze in če so razvite izključno za oblačno arhitekturo ali jo samo podpirajo.

Trenutno je podatkovna baza, ki podpira relacijski model in je razvita izključno za uporabo v

oblaku, le ena - Microsoft SQL Azure oz. SQL Services (10).

Slika 2.8: Delitev podatkovnih baz za uporabo v oblaku (10)

13

SAN – oddaljene podatkovne shrambe, do katerih dostopamo preko omreţja. NAS jih »razširi« s podporo

datotečnim sistemom


2.3.6 Tipi oblakov

Obstajajo tri vrste oblakov – javni, privatni in hibridni (kombinacija javnega in zasebnega tipa

oblaka). Izrazi javni, zasebni in hibridni niso vezani na lokacijo oblaka – zasebni oblaki so

lahko, tako kot javni, nameščeni »tam zunaj« v medmreţju. Tip oblaka, ki je primeren za

organizacijo, je odvisen od namena uporabe. Za začasne in testne aplikacije, pri katerih

količina potrebnih računalniških virov še ni dobro definirana, je primernejša uporaba javnega

oblaka, pri katerem je razširljivost cenejša in enostavnejša. Za trajne aplikacije, katerih

obnašanje poznamo ali imajo specifične zahteve ali pa morajo vedno zagotavljati konstanten

nivo QoS, pa je primernejši privatni oz. zasebni tip oblaka.

2.3.6.1 Javni oblaki

Javni oblaki so oblaki, ki so pod okriljem zunanje organizacije in v katerih se sočasno gostijo

aplikacije in podatki več odjemalcev. Večinoma niso na fizični lokaciji organizacije. Pri

pravilno implementiranem javnem oblaku, ki upošteva načela visoke učinkovitosti, varnosti in

lokalnosti podatkov, je sočasno izvajanje aplikacij različnih odjemalcev za odjemalce in oblak

transparentno. Glavna prednost javnega oblaka je njegova velikost – tipično so zasebni oz.

privatni oblaki veliko manjši. Velikost pomeni moţnost večje skalabilnosti in varnosti. Dele

javnega oblaka lahko uporabimo tudi izključno za enega odjemalca – temu pravimo privatni

virtualni podatkovni center. Tako ima odjemalec na voljo boljši vpogled v infrastrukturo in

nadzor nad streţniki, sistemi za shranjevanje podatkov, omreţnimi napravami in topologijo

omreţja. Če imamo privatne virtualne podatkovne centre, na fizični lokaciji povišamo

učinkovitost (manjši deleţ pasovne širine uporabimo za pretakanje podatkov) in hkrati

zniţamo varnost (naravne katastrofe ipd.).

2.3.6.2 Zasebni oblaki

Privatni oz. zasebni oblaki so namenjeni izključno enemu odjemalcu, kar zanj pomeni celovit

nadzor nad podatki, najvišji nivo varnosti in QoS. Odjemalec (običajno organizacija) je

lastnik oblaka in njegove infrastrukture, ki je fizično lahko del organizacije ali pa je na kakšni

drugi lokaciji. Razlogi za drugo lokacijo so običajno niţji stroški, višja varnost ipd.


Upravljanje oblaka je lahko interno (IT-oddelek organizacije sam upravlja z oblakom) ali pa

eksterno (upravljanje je prepuščeno ponudniku oblaka). Model gostujočega privatnega oblaka

pomeni, da je ponudnik odgovoren za namestitev oblaka in nastavitev ter delovanje strojne

opreme.

2.3.6.3 Hibridni oblaki

Hibridni oblaki zdruţujejo javni in zasebni model oblaka. Če model zasebnega oblaka (visok

nivo nadzora, varnosti in QoS) razširimo z računalniškimi viri javnega oblaka, dobimo

hibridni oblak, kar prispeva k skalabilnosti in zmogljivosti aplikacij. Velikokrat se takšen tip

oblaka uporablja za poslovne procese, ki občasno zahtevajo veliko računalniško moč. Takšna

opravila prevzame javni oblak. S hibridnimi oblaki se pojavi tudi kompleksnost distribuiranja

aplikacij med zasebnim in javnim oblakom. Razmerje med količino podatkov in procesno

močjo vpliva na učinkovitost oblaka. Če nimamo velike količine podatkov ali pa je naša

aplikacija brez stanja (anlg. stateless), bo hibridni tip oblaka veliko bolj učinkovit, kot če

moramo veliko količino podatkov prenašati v javni oblak za kratek čas obdelave (11).

Na sliki 2.9 lahko na levi strani vidimo model popolnoma zasebnega oblak, ki ima omejen

dostop in je v lasti organizacije, ki ga uporablja. Na desni strani pa lahko vidimo popolnoma

javni oblak, do katerega lahko dostopa vsak in je v lasti ponudnikov. Hibridni modeli oblaka

so nekje na sredini – dostop in lastništvo sta vedno odvisna od namena uporabe.

Slika 2.9: Dva pogleda na tipe oblakov (12)

DOSTOP DO STORITEV

NADZOR / LASTNIŠTVO

UPORABNIKI

PONUDNIKI

VSI LASTNIKI


2.4 Lastnosti računalništva v oblaku

Če povzamemo ţe napisano, lahko izluščimo lastnosti oz. značilnosti celotnega koncepta

računalništva v oblaku. V naslednjih tabelah bomo opisali te lastnosti s stališča odjemalca oz.

IT organizacije. Tabela 2.3 opisuje lastnosti, ki predstavljajo prednosti, tabela 2.4 pa slabosti

računalništva v oblaku (1), (3).

Tabela 2.3: Prednosti računalništva v oblaku

Prednost Opis

Nižji infrastrukturni stroški

Kot organizacija ne potrebujemo lastne

visokozmogljive strojne opreme in toliko IT osebja.

Za občasne, kratkotrajne viške zahtev običajno

potrebujemo še več strojne opreme, ki pa večino časa

»počiva«. Drastično se zniţajo tudi stroški za

varovanje strojne opreme in porabe električne

energije.

Centralizacija Centralizirana infrastruktura omogoča učinkovitejše

izvajanje aplikacij in zviša nivo varnosti.

Enostavnejše in cenejše vzdrževanje

Za vzdrţevanje programske in strojne opreme ne

skrbimo mi, ampak ponudnik, kar še dodatno zniţa

stroške.

Nižji stroški programske opreme

Načelo računalništva v oblaku »plačaš to, kar

uporabljaš« minimizira stroške programske opreme,

ker ni potrebno plačevati za programsko opremo, ki

je velikokrat ne uporabljamo v celoti. Poleg tega

lahko varno uporabljamo zastonjsko programsko

opremo, ki nam jo daje oblak.

Enostavnejše posodabljanje programske

opreme

Ker imamo vso programsko opremo na enem mestu,

jo laţje posodabljamo. Tako uporabniki uporabljajo

vedno najnovejšo verzijo aplikacij, kar odpravi

nevšečnosti zaradi uporabe napačnih verzij

programske opreme.

Višja računska moč

Na voljo imamo veliko strojne opreme, ki jo lahko

uporabimo, kadar to ţelimo in nismo omejeni z

zmogljivostjo lastne infrastrukture.

»Neskončne« shranjevalne kapacitete

Oblak nam nudi ogromno prostora za varno

shranjevanje podatkov. Omogočena je tudi

redundanco velikih količin podatkov.

Višja varnost podatkov

Za varnost poskrbi oblak, ki je odporen proti

električnim izpadom, okvaram strojne opreme ipd.

Zagotavlja celovito varnost in integriteto podatkov.

Zaradi velike računske moči lahko uporabljamo tudi

boljše šifrirne algoritme.


Dostopnost

Ker imamo v oblaku vse podatke in aplikacije, lahko

do njih preko medmreţja dostopamo vedno in povsod

(neodvisno od naprave). Poleg tega imamo zmeraj na

voljo zadnjo verzijo podatkov.

Boljša kompatibilnost

Koncept računalništva v oblaku zagotavlja

uporabniško neodvisnost od operacijskih sistemov,

kar pomeni, da uporaba aplikacij ni pogojena z

operacijskim sistemov odjemalca (enako velja za

dokumente).

Lažje sodelovanje

Oblak zagotavlja sodelovanje na vseh ţelenih nivojih

(podatki, aplikacije). Uporabniki lahko enostavneje

sodelujejo pri vseh vrstah projektov, saj potrebujejo

samo računalnik in dostop do interneta in niso

odvisni od aplikacij za sinhronizacijo (SVN, GIT

ipd.).

Večkratna sočasna uporaba

Oblak zagotavlja sočasno uporabo naše aplikacije in

optimizira porabo računalniških virov, ki jih

plačujemo.

Integriteta podatkov Oblak zagotavlja celovito integriteto vseh podatkov.

Dinamična skalabilnost

Temu pravimo tudi »elastičnost«, kar pomeni, da se

oblak prilagaja uporabi aplikacije tako, da dinamično

dodeljuje računalniške vire.

Enostaven začetek poslovanja

Preden lahko organizacija začne poslovati, mora

vzpostaviti celotno infrastrukturo, kar predstavlja

velik strošek. Z uporabo oblaka lahko ta korak

preskočimo, v enem dnevu namestimo aplikacije in

pričnemo s poslovanjem.

Tabela 2.4: Slabosti računalništva v oblaku

Slabost Opis

Popolna odvisnost od omrežja

Za dostop do podatkov in uporabo aplikacij moramo

biti povezani z oblakom. Če omreţje odpove, smo

nemočni.

Odzivnost aplikacij

Delovanje aplikacij v oblaku je v veliki meri odvisno

od pasovne širine oz. omreţne hitrosti med

uporabnikom in oblakom. Če je povezava počasna, so

z uporabnikovega stališča počasne tudi aplikacije

(sploh če se pošiljajo večje količine podatkov).

Omejenost ponujenih SaaS

Storitve, ki jih ponudniki SaaS ponujajo, so običajno

manj funkcionalne, kot aplikacije, ki jih danes

lokalno nameščamo (npr. Google Docs in Microsoft

Office). Čeprav število storitev SaaS raste, jih na trgu

še vedno primanjkuje.


Varnost je lahko vprašljiva

Vsi podatki so shranjeni v oblaku, kar pomeni, da je

njihova varnost odvisna od varnosti oblaka. Če do

podatkov lahko dostopa bodisi ponudnik oblačne

storitve bodisi druga nepooblaščena oseba, smo

nemočni. Zna se zgoditi, da za vdore v sistem niti ne

izvemo, če jih ponudnik zamolči. Hujši problem

lahko predstavlja izguba podatkov. Če oblak »izgubi«

podatke, jih izgubimo tudi mi (centralizacija problem

še dodatno poudari). Če ostanemo brez pomembnih

podatkov, nam tudi odškodnina ne pomaga veliko, saj

je informacije izredno teţko oceniti.

Realnočasovna opravila

Standardna oblačna arhitektura ne zagotavlja

realnočasovnih operacij. Ta problem je pogojen z

odvisnostjo od omreţja in ne popolnoma

predvidljivega obnašanja strojne opreme (realen čas

je z »elastičnostjo« praktično nemogoče zagotoviti).

Implementacija aplikacij

Implementacija aplikacij, ki so oz. bodo nameščene v

oblaku, mora biti skladna s koncepti razvoja oblačnih

aplikacij. Načrtovalci in razvijalci aplikacij morajo te

koncepte spoznati in jih razumeti.

2.5 Varnost računalništva v oblaku

2.5.1 Varnostni izzivi

Verjetno ni treba posebej poudarjati, kako pomembna je varnost za razvoj in učinkovito

uporabo računalništva v oblaku, kar kaţe tudi graf na sliki 2.10.

Glavni izziv računalništva je, po mnenju ljudi, zagotavljanje ustrezne varnosti. Centralizirana

in omreţno odvisna arhitektura, kot je računalništvo v oblaku, je izredno izpostavljena glede

na varnost, ki mora biti zagotovljena na vseh nivojih. Eno izmed glavnih načel varnosti pravi,

da je celovit sistem varen toliko, kot je varen njegov najšibkejši člen. Kot bomo kasneje

videli, je najšibkejši člen lahko ponudnik, odjemalec, razvijalec storitve ali strojna oprema.

Izvor problema varnosti oblačne arhitekture je, da izgubimo nadzor nad strojno opremo,

hkrati pa delimo računalniške vire z drugimi uporabniki oz. organizacijami. Izpostavljanje

občutljivih podatkov v deljeno okolje upravičeno vzbuja pomisleke.


Slika 2.10: Rezultati ankete o izzivih računalništva v oblaku 2010 (13)

Prvi izziv je zaščita podatkov pred vsiljivci oz. nadzor dostopa do podatkov v deljenem

okolju. Kaj se zgodi, če so vaši podatki na istih podatkovnih streţnikih kot podatki

organizacije, ki krši zakon, in ima vlada vso pravico, da zaseţe vso strojno opremo – zraven

pa tudi vaše zaupne podatke (7)?

Drugi izziv je upravljanje s šifriranjem, bolj natančno s ključi za šifriranje in dešifriranje. Za

varno uporaba oblaka potrebujemo varen prenos podatkov v obe smeri (odjemalec-oblak in

oblak-odjemalec) in ustrezno šifriranje podatkov, ki so shranjeni na streţnikih.

Tretji izziv predstavlja naša aplikacija; varnost oblaka nam nič ne pomaga, če naša aplikacija

ţe v osnovi ne uporablja varnostnih mehanizmov in ima skrite napake. Skrite varnostne

probleme predstavlja tudi hkratna uporaba več nedozorelih tehnologij (npr. kombinacija

različnih spletnih storitev). Zato je pomembno, da se med razvojem drţimo formalnega

razvojnega cikla, (angl. formal secure Software Development Life Cycle ali SDLC), ki

minimizira moţnost napak. Razvojna okolja, s katerimi razvijamo aplikacije za uporabo v

oblaku, morajo imeti vgrajen varnostni model, ki vodi razvoj v pravo smer (in ne po najkrajši

oz. najhitrejši poti) in ob produkciji zagotovi nadzor ter politiko dostopa do podatkov (7).

Varnost

Dostopnost

Učinkovitost

Model plačevanja

Pomanjkanje standardov

Prenosljivost

Težavnost integracije

Premajhna presonalizacija

87,5

83,3

82,9

81

80,2

79,8

76,8

76

Rezultati ankete - 3Q 2009

Ocenite izzive računalništva v oblaku med 1 in 5!


Četrti izziv predstavlja zaupanje odjemalca do ponudnika. Za realnočasovne analize

podatkov, varnostni nadzor in beleţenje dostopov potrebujejo ponudniki oblačnih storitev

dostop do podatkov, kar pa vsem odjemalcem ne ustreza. Zapisi dostopov so običajno na

voljo le administratorjem oblaka, kar pomeni, da je nadzor iz odjemalčeve perspektive

omejen. Ker so zapisi dostopov pogoj za varnostni standard plačevanja s kartico (angl.

Payment Card Industry Data Security Standard ali PCI DSS), mora biti odjemalec pri sestavi

pogodbe SLA previden (7).

Peti izziv, ki je velikokrat podcenjen, sta ustrezna tehnologija in protokol za ponovno

vzpostavitev. Organizacije, ki uporabljajo oblak za poslovanje, so odvisne od delovanja

oblaka, zato mora ponudnik zagotoviti mehanizme, ki zagotavljajo ustrezno redundanco

podatkov. Varnostnih problemov, ki lahko nastanejo pri ponovnem vzpostavljajo sistema je

lahko več. Podatke, ki niso šifrirani, zaradi »krize« lahko vidijo tudi nepooblaščene osebe.

Zaradi časovne stiske je velika verjetnost, da bo varnostna politika kršena pri premikanju oz.

migraciji podatkov. Takšne probleme lahko odpravimo z natančno definiranim protokolom, ki

ga je potrebno ob ponovni vzpostavitvi upoštevati.

Šesti izziv predstavlja dinamična narava virtualnih strojev, zaradi katere je teţje konsistentno

vzdrţevati ustrezen nivo varnosti, hkrati pa zahtevati moţnost revizije vseh podatkov.

Kloniranje in distribucija podatkov med fizičnimi streţniki lahko povzroči rast nastavitvenih

napak in drugih ranljivosti. Dokazati, v kakšnem varnostnem stanju sta neki virtualni sistem

in identifikacija neustrezno zavarovanih virtualnih strojev, danes predstavlja izziv (7).

Varnostne izzive so ţe leta 2008 obravnavali tudi pri Gartnerju. Objavili so sedem vprašanj,

ki bi jih moral vsak odjemalec postaviti potencialnemu ponudniku pred podpisom SLA (14) :

Kdo ima privilegiran dostop do podatkov?

Ali ponudnik odobrava zunanje varnostne preglede?

Ali ponudnik dopušča nadzor nad lokacijo podatkov?

Je šifriranje podprto na vseh nivojih in so šifrirne sheme potrdili profesionalni

strokovnjaki za varnost?

Kako ponudnik obravnava naravne katastrofe in kaj se zgodi, če ponudnik propade?

Ima ponudnik podporo za iskanje neprimernih aktivnosti?


S takšnimi vprašanji najlaţje in najhitreje odkrijemo nivo varnosti. Da bi ponudniki lahko na

čim več takšnih vprašanj odgovorili v prid odjemalcu, so razvili in izpopolnili varnostne

mehanizme, ki so opisani v naslednjem poglavju.

2.5.2 Varnostni mehanizmi

Današnji ponudniki storitev v oblaku uporabljajo veliko varnostnih mehanizmov, ki

izboljšujejo k varnost na podatkovnem nivoju, na nivoju komunikacije ter na nivoju izvajanja

storitev. Osnova za varnost storitev je varnost dostopa do teh storitev.

Varnost omreţja je ključna za doseganje visokega nivoja varnosti, zato se ponudniki strogo

drţijo načel dobrega varovanja omreţij. Dva različna streţnika iz dveh različnih dostopnih

točk lahko delujeta v isti varnostni skupini, en streţnik lahko pripada več varnostnim

skupinam, streţniki v isti varnostni skupini ne morejo komunicirati med seboj in streţniki v

istem omreţnem segmentu si ne smejo deliti nikakršnih IP-karakteristik14

. Ta štiri enostavna

pravila močno oteţijo vdor v omreţje in minimizirajo moţnost večje škode, če vseeno pride

do vdora. Izredno pomembna komponenta varnega omreţja je poţarni zid. Zunanji poţarni

zid ščiti najbolj zunanjo domeno, kjer so večinoma streţniki za uravnavanje prometa.

Tradicionalno varovanje streţnikov vsebuje tri nivoje poţarnih zidov – topologijo lahko

vidimo na levi strani slike 2.11. Prvi, zunanji poţarni zid dovoljuje izključno zahteve tipa

HTTP, HTTPS in FTP. Drugi poţarni zid varuje cono aplikacijskih streţnikov (DMZ cona)15

,

zadnji poţarni zid pa ščiti podatkovne streţnike. Zaradi virtualizacije se v oblaku uporablja

pristop, ki je prikazan na desni strani slike 2.11. Vsak virtualni streţnik ima v omreţju enak

nivo pravic, ki so odvisne od politike varnostne skupine. V takšnem modelu ni omreţnih

domen – pravice v isti varnostni skupini so med streţniki neodvisne, kar pomeni, da je

nepooblaščen dostop omejen samo na streţnik, ki je napaden. Za upravljanje skrbi

upravljavec virtualnih strojev (anlg. hypervisor) – npr. VMware ESX ali XEN.

14

IP-karakteristika je npr. isti naslovni prostor oz. razred.

15 DMZ-cona pomeni notranje, strogo nadzorovano omreţje z natančno definirano politiko.


Slika 2.11: Primerjava modelov za varovanje omreţja (3)

Za celovito varnost potrebujemo tudi ustrezno šifriranje, za katero moramo poskrbeti mi kot

odjemalci oz. razvijalci naših aplikacij in ponudniki oblačnih storitev. Šifriramo lahko:

podatke – odgovornost odjemalca/razvijalca IS

datotečne sisteme – odgovornost ponudnika

varnostne kopije – odgovornost ponudnika

omreţni promet – odgovornost ponudnika

Problem šifriranja virtualnih sistemov je nedozorelost standardov, ki se večinoma nanašajo na

splošne medmreţne aplikacije, zato je sistem šifriranja in shranjevanja šifrirnih ključev

odvisen od ponudnika.

Pomembna komponenta varovanja je inteligenten nadzor prometa oz. sistem za odkrivanje

vdorov (angl. Network Intrusion Detection Systems ali NIDS), ki ščiti pred omreţnim

prometom, kot so iskanje prostih vrat (anlg. port scans) in mreţni napadi onemogočitve

servisov (angl. Denial of Service ali DoS attacks). Vse zahteve najprej obravnava NIDS, šele

nato jih prevzamejo streţniki za uravnavanje prometa (3). Z dobrimi sistemi NDIS lahko

preprečimo večji del vdorov, če do vdora vseeno pride, pa imamo na voljo več podatkov, ki

vplivajo na čas identifikacije varnostne luknje.

Trinivojsko domensko varovanje

Podatkovni strežniki

Aplikacijski strežniki

Uravnavanje prometa

Brezdomensko varovanje oblaka

Medmrežje

Upravljavec virtualnih strojev

Skupinska pravila

Skupinska pravila

Skupinska pravila

Strežnik za uravnavanje prometa

Aplikacijski strežnik

Podatkovni strežnik

DMZ


2.6 Primerjava velikih

V tem poglavju bomo na kratko opisali glavne ponudnike storitev v oblaku. Google, EMC,

Microsoft, Amazon, Salesforce.com (15) in IBM so trenutno vodilni ponudniki, ki pa se med

seboj razlikujejo po tipih storitev, ki jih ponujajo, in po uporabljenih tehnologijah.

2.6.1 Google

Google App Engine omogoča razvijalcem, da razvijejo in namestijo svoje aplikacije na isti

infrastrukturi, ki jo uporablja Google. Razvoj je relativno enostaven, saj so razvijalci

odgovorni le za svojo kodo, za vse ostalo poskrbi oblak. Podprti programski okolji sta Java in

Phyton. Zaradi velike količine strojne opreme je Google App Engine sposoben absorbirati oz.

obravnavati veliko število zahtev v zelo kratkem času. Omogočena je tudi enostavna

integracija z Googleovimi storitvami. Zastonjski paket vsebuje 500Mb prostora in dovolj

procesne moči in pasovne širine, da zagotovi okoli 5 milijonov zahtev na mesec (16). Google

sam ţe kar nekaj časa uporablja oblačno arhitekturo za elektronsko pošto (GMail), dokumente

(GoogleDocs) ipd.

2.6.2 EMC

EMC Corporation je vodilo svetovno podjetje za shranjevanje in upravljanje s podatki.

Njihova infrastruktura podpira veliko število različnih storitev. Aprila 2009 so predstavili nov

sistem za upravljanje virtualnih podatkovnih centrov z imenom Symmetric V-Max, ki močno

olajšuje upravljanje velikih količin podatkov na distribuiranih sistemih. EMC ponuja

arhiviranje, avtomatizirano ponovno vzpostavitev, storitve za upravljanje poslovnih vsebin,

inteligentno upravljanje s podatki, virtualizacijo ipd. Odjemalcem ponujajo tudi VMware za

tehnologijo virtualizacije (17).


2.6.3 Microsoft

Microsoft ponuja oblačne storitve za organizacije in individualne odjemalce. Windows Azure

platforma podpira aplikacije, podatke in infrastrukturo oblaka. Kot prikazuje slika 2.12, je

platforma razdeljena na tri komponente:

Windows Azure, ki nudi okolje Windows za izvajanje aplikacij in shranjevanje

podatkov

SQL Azure, ki nudi podatkovne storitve, ki temeljijo na SQL streţniku

Windows Azure platform AppFabric, ki nudi storitve za povezovanje aplikacij (med

oblakom in lokalnimi aplikacijami)

Slika 2.12: Komponente odjemalcev in Windws Azure (18)

Microsoft vsebuje tudi SharePoint Services, ki omogočajo laţje sodelovanje in Microsoft

Dynamics CRM (angl. Customer Relationship Management), ki je sistem za upravljanje s

strankami. V razvoju je so tudi Live Services, ki omogočajo skupinsko delo. Kot primer lahko

navedemo Microsoft Office Live, ki je alternativa Google Docs. Microsoft tudi uvaja koncept

S+S oz. Software plus Services, ki zdruţuje SaaS, SOA in Web 2.0 (18).

SQL Azure Windows Azure

Platform AppFabric

Aplikacije v oblaku

Windows Azure

Lokalne aplikacije

Windows Ostali OS


2.6.4 Amazon

Amazon ponuja najrazličnejše oblačne storitve oz. AWS (15), (19):

Amazon Elastic Compute Cloud (Amazon EC2) – storitev, ki ponuja skalabilno

računsko okolje v oblaku. EC2 ponuja enostaven spletni vmesnik za nastavitve in

nadzor računalniških virov. Podpira tudi Microsoft Windows Server 2003, ASP.NET,

ASP.NET AJAX, Silverlight, IIS in SQL Server.

Amazon Simple Storage Service (Amazon S3) – storitev, ki ponuja shranjevanje

podatkov v oblaku. S3 ima enostaven spletni vmesnik za upravljanje s podatki.

Amazon ponuja tudi relacijske podatkovne baze – Amazon RDS ali Amazon

Relational Database Service.

Amazon CloudFront – storitev, ki podpira dostavo najrazličnejših vsebin. Deluje

skupaj z drugimi Amazonovimi storitvami in jih razširi z enostavnim načinom dostave

vsebin odjemalcem.

Amazon Simple Queue Service (Amazon SQS) – storitev, ki nudi skalabilne

sporočilne vrste za shranjevanje sporočil, ki potujejo med računalniki. Razvijalci

lahko premikajo podatke med distribuiranimi komponentami in jim ni treba skrbeti za

integriteto sporočil ter nenehno dostopnost vsake komponente. SQS podpira tudi

generiranje delovnih tokov (angl. workflow), ki so povezani z EC2 in ostalimi

Amazonovimi stroitvami.

Ostale so storitve, kot so Amazon Elastic MapReduce za laţje procesiranje velikih

količin podatkov, AWS Premium Support, ki daje podporo, Amazon Virtual Private

Cloude (VPC), ki ponuja izolirane virtualne privatne oblake, Amazin Flexible

Payments Service (FPS) za podporo digitalnim denarnim transakcijam ipd.

2.6.5 Salesforce.com

Salesforce.com je podjetje, ki ima visoke doseţke na področju avtomatizacije poslovnih

procesov. Danes se podjetje osredotoča na tri primarne storitve:

The Sales Cloud – SaaS za prodajo

The Service Cloud – platforma, za odjemalčeve storitve

Custom Cloud – moţnost zasebnega oblaka; Force.com


Salesforce.com je bolj zaprt ponudnik, ki ponuja tudi svoje razvojno okolje Apex. Razvili so

tudi storitev PaaS z imenom Foce.com, ki vsebuje celovito platformo za poslovne aplikacije

in podpira storitve za podatkovni nivo, poslovno logiko, delovne tokove, integracijo in

uporabniški vmesnik. Force.com omogoča sočasno izvajanje več aplikacij v isti instanci

SalesForce.com, kar pomeni, da si lahko več aplikacij deli skupen varnostni in podatkovni

model ter uporabniški vmesnik (Visualforce). Salesforce.com nudi tudi popularen SaaS –

Salesforce CRM, ki podpira prodajo, marketing, različne odjemalčeve storitve, sodelovanje,

analize in zunanje aplikacije.

2.6.6 IBM

IBM daje poleg oblačnih storitev za podjetja vseh velikosti tudi svetovanja in pomoč pri

vpeljavi informacijskih rešitev za oblačno arhitekturo. V praksi se izkaţe, da ustrezna

svetovanja dvignejo varnostni nivo in učinkovitost storitev v javnih, zasebnih ali hibridnih

oblakih. IBM ima dva načina svetovanja – industrijsko-specifično svetovanje (varnost,

topologija oblaka) in tehnološko svetovanje (razvoj in implementacija storitev). Storitve, ki

jih ponuja IBM oz. IBM Smart Business services, so:

IBM Smart Business Development/Test Cloud – nudi podporo pri razvoju in testiranju

storitev v varnem okolju, ki je osnova za kvalitetno testiranje in visok QoS.

IBM Smarti Analytics Cloud – nudi dostop in analizo podatkov iz različnih virov, kar

olajša BI.

IBM Smartin Business Storage Cloud – nudi varno shranjevanje (arhiviranje,

varnostne kopije, redundanca) velikih količin podatkov.

IBM Smart Business Desktop Cloud – nudi varno in standardizirano namizno okolje

za vašim poţarnim zidom ali v IBM-ovem oblaku.

IBM Smart Business End User Support – nudi storitve za IT-pomoč v obliki portalov.

IBM LotusLive – nudi storitve za sodelovanje, deljenje datotek, spletne konference,

komuniciranje ipd.

IBM LotusLive iNotes – nudi storitve za urnike, elektronsko pošto in ostale kontakte.

IBM Comuting on Demand (CoD) – nudi strojno opremo z veliko računsko močjo.

Business Continuity and Resiliency Services (BCRS) – nudi storitve za odpornost in

neprekinjeno delovanje poslovnih procesov.


2.6.7 Primerjava

V tabeli 2.4 so prikazane osnovne značilnosti največjih ponudnikov računalništva v oblaku.

Tabela 2.5: Lastnosti ponudnikov računalništva v oblaku

Organizacija Glavni produkti Storitve

Google

Google App Engine

GMail

GoogleDocs

PaaS – App Engine za lastne aplikacije

SaaS – GMail, GoogleDocs

EMC Podpora za DB2, Oracle,

MSSQL, SAP, Sysbase…

IaaS – podpora VMware virtualizaciji

SaaS za shranjevanje podatkov, arhiviranje,

poslovno inteligenco…

Microsoft Windows Azure

OfficeLive Beta PaaS – Windows Azure, SQL Azure, AppFabric

Amazon Amazon Web Services IaaS – EC2, S3, CloudFront

Salesforce.com

Salesforce CRM

Force.com Platform

Chatter

IaaS – CRM, javna uprava, finance…

PaaS – The Service Cloud

Apex razvojno okolje

IBM

Smart Business

Development/Test Cloud

Smarti Analytics Cloud

Smartin Business Storage

Cloud

IaaS – CloudBurst Appliance

PaaS – IBM Websphere Platform


3 STORITVENO USMERJENA ARHITEKTURA

V tem poglavju bomo na kratko predstavili koncepte SOA in razloţili zakaj je SOA

najprimernejša za razvoj aplikacij, ki se bodo izvajale v računalniškem oblaku. Definirali

bomo storitve in BPEL ter predstavili skupno storitveno vodilo ali ESB in IBM-ovo

arhitekturo storitvenih komponent ali SCA (angl. Service Component Architecture).

3.1 Kaj je SOA?

Preden se lotimo opisovanja tehnologij SOA, bomo SOA na kratko definirali. Če povzamemo

ključne lastnosti več definicij, lahko SOA definiramo kot arhitekturni koncept, ki realizira

poslovne procese z mnoţico povezanih storitev. Storitve predstavljajo dobro definirane enote

procesa in implementirajo operacije (vmesnik storitve), ki opravljajo neko poslovno funkcijo.

Storitvena usmerjenost torej pomeni mnoţico vmesnikov, ki predstavljajo poslovne

funkcionalnosti. Idejo »implementiraj enkrat, uporabi večkrat« pogojuje okolje z dobro

definiranimi in enostavno dosegljivimi storitvami, ki jih lahko zdruţujemo v večje

komponente (20). Koncept SOA zmanjša tako imenovani »IT gap« ali semantični razkorak

oz. zdruţuje vidike poslovnega sveta z vidikom informacijske podpore poslovnim procesom.

Z razvojem SOA se je izoblikovala mnoţica tehnologij, kot so (21):

ESB (anlg. Enterprise Service Bus) – skupno storitveno vodilo,

SRR (angl. Service Registry and Reposirtory) oz. register in repozitorij storitev,

Rule engine – sistem za upravljanje s pravili poslovnih procesov in

BPM (angl. Business Process Management) in BAM (angl. Business Activity

Monitoring) oz. upravljanje in nadzor poslovnih procesov in aktivnosti.


3.1.1 Tehnologije SOA

Ker tema tega diplomskega dela ni SOA, ampak razvoj informacijskih rešitev v

računalniškem oblaku, bomo opisali samo tehnologije, ki so posebej pomembne v konceptu

računalniškega oblaka in katere bomo uporabili pri praktičnem delu diplomskega dela.

3.1.1.1 Skupno storitveno vodilo

ESB oz. skupno storitveno vodilo predstavlja programsko platformo, ki poenostavi integracijo

in ponovno uporabo poslovnih komponent z uporabo SOA. ESB omogoča dinamično

povezovanje in posredovanje storitev ter nadzor nad storitvami in njihovimi interakcijami,saj

odstrani direktne povezave med ponudniki in uporabniki storitev. Tako zagotavlja šibko

sklopljenost in povečano fleksibilnost. Glavni koncepti skupnega storitvenega vodila so (20):

zagotavljanje visokega QoS – platforma ESB je odgovorna za zanesljivost, obravnavo

napak in ustrezno komunikacijo med storitvami, kar je potrebno za visok QoS;

dostopnost storitev – storitve na ESB imajo moţnost interakcije z vsemi ostalimi

storitvami. Dostop in posredovanje storitev je pod nadzorom ESB, ki poleg spletnih

storitev podpira tudi veliko število drugih tehnologij (komponente JEE in .NET,

starejši sistemi MOM ipd.);

topologija vodila – ESB je implementiran tako, da omogoča visoko razpoloţljivost

storitev, kar je pogoj za nivo ponovne uporabe. To omogoča topologija vodila, ki

ustreza skalabilnim modelom distribuiranih sistemov, kjer zvezdna topologija s

centralnim nadzornim posrednikom ne ustreza večji platformi SOA.

ESB-ju pravijo tudi hrbtenica SOA, ker omogoča povezljivost, transport, usmerjanje, dostavo

in transformacijo sporočil med odjemalci in storitvami. Storitve in odjemalci SOA so

predstavljeni z naslovnimi identifikatorji oz. končanimi točkami (angl. endpoints). Končna

točka je logični naslov ali lokacija, kjer lahko pride do interakcije med odjemalcem in ESB-

jem oz. storitvami. ESB si lahko predstavljamo kot kroţnico, na kateri je več končnih točk,

med katerimi se lahko sočasno pretaka več sporočil. Rešitev SOA lahko implementira mnoge

kompleksne tehnologije, kot so MOM, sporočilne vrste, poslušalce dogodkov, lahko pa se

zanaša na enostavno izmenjavo sporočil preko protokola HTTP. Zaradi tega se tip ESB-ja

določi skladno z arhitekturo rešitve SOA.


3.1.1.2 Kompozicija poslovnih storitev in BPEL

Pravi potencial storitveno usmerjenih arhitektur se pokaţe na tako imenovanem nivoju

poslovnih procesov, ki podpira njihovo izvajanje. Ti so sestavljeni iz poslovnih storitev.

Procesno orientiran pristop zviša nivo integrabilnosti in zahteva nekaj arhitekturnih sprememb

pri razvoju informacijskih rešitev. Prvič potrebujemo natančno ločitev poslovnega procesa od

poslovne logike, saj izvajanje procesov opišemo s posebnimi jeziki. Drugič pa kompozicija

storitev v poslovne procese pomeni visoko fleksibilnost in agilnost, manj časa za razvoj in

enostavnejšo implementacijo sprememb. Procesno orientiran pristop predstavi nov razvojni

model – »programiranje na veliko« (angl. programming-in-the-large), ki pomeni kompozicijo

storitev v poslovne procese. Ta zagotavlja hitro in učinkovito prilaganje poslovnih procesov

razmeram na trgu in vodstveni strategiji.

Da realiziramo poslovni proces kot kompozicijo storitev, potrebujemo najprej vse poslovne

storitve, ki proces sestavljajo. Poslovne storitve morajo izpostaviti vmesnik, katerega

operacije se nanašajo na posel. Ko imamo poslovne storitve na voljo, moramo definirati

zaporedje proţenja teh storitev in uvesti mnoţico pravil, ki vplivajo na potek izvajanja

poslovnega procesa. Poskrbeti moramo tudi za sočasna izvajanja, podatkovne transformacije,

odvisnosti in korelacije. Pomemben del poslovnih procesov predstavlja tudi obravnava napak

in kompenzacijskih aktivnosti. Kompozicijo poslovnih storitev lahko realiziramo na dva

načina:

Orkestracija – imamo en krovni proces, ki ima absolutni nadzor nad poslovnimi

storitvami in koordinira njihovo izvajanje in proţenje vseh potrebnih operacij. Iz

vidika poslovnih storitev se ne da ugotoviti vključenosti v poslovne procese.

Koreografija – vsaka poslovna storitev ve, kdaj se mora izvesti in s katerimi storitvami

sodeluje. Gre za decentraliziran model, kjer se morajo vse poslovne storitve zavedati

poslovnega procesa.

Pri orkestraciji, kjer poslovni procesi postanejo izvajalna koda, potrebujemo jezik, s katerim

lahko celovito in natančno opišemo poslovni proces in njegova poslovna pravila. Danes je

najbolj uveljavljen BPEL (angl. Business Process Execution Language)16

(20).

16

BPEL – jezik za definiranje poslovnega procesa.


BPEL (tudi WS-BPEL ali BPEL4WS) je jezik za »programiranje na veliko« oz. za

orkestracijo kompozitnih poslovnih procesov. Najpomembnejši koncepti BPEL-a so (20):

logični opis poslovnega procesa s kompozicijo storitev,

kompozicija večjih poslovnih procesov iz manjših podprocesov in storitev,

podpora sinhronemu in asinhronemu proţenju storitev,

podpora zaporednemu in vzporednemu (sočasnemu) izvajanju operacij,

selektivna kompenzacija v primeru izjem in napak,

vzdrţevanje dolgo trajajočih transakcijskih aktivnosti,

usmerjanje vhodnih sporočil do primernih procesov ali storitev in

podpora korelaciji zahtev v poslovnih procesih in med njimi.

3.1.2 SCA

SCA (angl. Service Component Architecture) ali storitvena komponentna arhitektura je

mnoţica specifikacij, ki opisujejo model za razvoj aplikacij SOA. Temelji na ideji

kompozitnih aplikacij, ki so sestavljene iz storitev, razvitih posebej za našo aplikacijo in

storitev, ki so del ţe obstoječih sistemov in jih lahko ponovno uporabimo. Kot lahko vidimo

na sliki 3.1, model SCA vključuje kompozicijo obstoječih in razvoj novih storitev oz.

komponent, ki so lahko implementirane z različnimi programskimi jeziki in v različnih

ogrodjih (Java POJO, C++, BPEL, EJB, PHP…). Za povezovanje oz. komunikacijo med

komponentami se uporabljajo različne tehnologije, kot so spletne storitve, sporočilni sistemi

in RPC (angl. Remote Procedure Call). Za politiko delovanja pa se uporablja ogrodje, ki

definira obnašanje, omejitve, QoS, ipd.

Slika 3.1: Komponente modela SCA (22)

Sestavljanje storitev

Implementacija storitev

Povezovanje storitev

Politika delovanja

SCA


SCA torej ponuja odgovore na vprašanja:

Kako razviti komponente tako, da bodo ponovno uporabne?

Kako sestaviti komponente v delujočo celoto?

Kako omejiti dostop do komponent?

Arhitekturni model, ki ga specificira SCA, vsebuje dva pomembna nivoja. Na poslovnem

aplikacijskem nivoju imamo komponente, ki implementirajo poslovno logiko in storitve za

dostop do podatkov ter razne adapterje za povezavo z niţjim nivojem. Del tega nivoja

predstavlja tudi infrastruktura, ki dinamično zagotavlja varnost, zanesljivost in podporo

transakcijam, vsem komponentam ter njihovim povezavam. Na drugem, vmesnem nivoju

(angl. middleware), pa imamo vmesnike za dostop do podatkovnih baz, sporočilnih sistemov,

spletnih storitev ipd. Model SCA torej sestavljajo komponente oz. osnovni bloki (ki jih je

potrebno implementirati), kompoziti oz. sistemi (ki predstavljajo neko celoto, sestavljeno iz

komponent), povezave (ki vsebujejo reference na komponente) in storitve. Podrobneje si

bomo pogledali komponento SCA, ki je prikazana na sliki 3.2. Komponenta ponuja in

uporablja storitve. Ponujane operacije definira vmesnik komponente. Na drugi strani pa

imamo reference, ki omogočajo povezljivost oz. uporabo drugih storitev.

Slika 3.2: Komponenta SCA (23)

IBM model SOA grobo definira s tremi nivoji:

nivo kompozicije (angl. compostition) storitev – običajno BPEL

nivo proţenja (angl. invocation) storitev – SCA in

podatkovni nivo – SDO17

in BO18

17

SDO (angl. Service Data Object) ali storitveni podatkovni objekt poenoti pogled na podatkovni nivo.

18 BO (angl. Business Object) ali poslovni objekt omogoča abstrakcijo podatkov, ki jo uporablja model SCA.

KOMPONENTA SCA …

…

REFERENCE STORITVE

RAZLIČNE IMPLEMENTACIJE


IBM za kompozicijo uporablja module SCA, ki razširjajo koncept komponent SCA. Na sliki

3.4 je prikazan storitveni modul, ki ima na sredini storitveno (SCA) komponento, ki jo lahko

implementiramo na osem načinov: z Javo, kot poslovni proces (BPEL), kot avtomat stanj, kot

poslovno pravilo, kot človeško opravilo, kot preslikavo vmesnikov, kot mediacijski tok ali kot

selektor. Vmesnike in reference lahko definiramo z Javo ali z WSDL (Port Type). Izvozi

(angl. exports) in uvozi (angl. imports) pa zagotavljajo povezljivost na devet načinov: s

sporočilnimi vrstami (MQ, MQ JMS in Generic JMS), s spletnimi storitvami (JAX-WS Web

Service, JAX-RPC Web Service), s HTTP, s sejnimi zrni (Stateless Session Bean) in s

(privzeto) povezavo SCA.

Slika 3.3: Storitveni modul (24)

Če poveţemo več komponent, dobimo kompozitni sistem, ki je sestavljen iz enega ali več

modulov, nič ali več vstopnih točk in zunanjih storitev ter povezav. Za lepši pregled in

semantično ločitev storitev je dobra praksa, da razdelimo večje sisteme na več manjših

podsistemov, ki jih laţje obvladujemo.

Politika delovanja in infrastrukturnih zmoţnosti se v SCA definira na deklarativen način, kar

zagotovi strogo ločitev od poslovne logike. Politika delovanja je realizirana s pomočjo zbirk

atributov in nastavitev, ki jih SCA priredi komponentam, vhodnim točkam in zunanjim

storitvam (23).

STORITVENA KOMPONENTA I

R

R

I

UVOZ I

IZVOZ I

SAMOSTOJNA

REFERENCA R

STORITVENA

KOMPONENTA

STORITVENI MODUL

IMPLEMENTACIJA


3.2 SOA in računalništvo v oblaku

Če povzamemo, SOA uvaja principe, politiko, načela in ogrodja, ki nam omogočajo

povezovanje poslovnih storitev tako, da podpremo poslovne procese, ki zadovoljujejo

poslovne cilje. Gledano visokonivojsko, SOA omogoča učinkovitejše upravljanje in nadzor,

pregled in boljše metrike poslovnih procesov. Vse to pomeni celovit pogled na poslovne

procese. Razlika med SOA in računalništvom v oblaku je lahko zavajajoča, ker se koncepta

na nekaterih področjih prekrivata, vendar sta v osnovi različna:

SOA dostavlja poslovne storitve aplikacijam.

Računalništvo v oblaku dostavlja storitve (SaaS, Paas, IaaS) končnemu uporabniku.

SOA torej izpostavlja storitve aplikacijam in velikokrat te storitve izpostavljajo druge

aplikacije. Če v organizaciji uporabljamo npr. SAP19

, kjer lahko izpostavimo storitve SAP

drugim programskim rešitvam v organizaciji, gre za koncept SOA. Če takšen sistem

uporabljam v oblaku, gre še vedno za SOA.

Računalništvo v oblaku nudi platformo za drugačne tipe storitev. Če pogledamo SaaS, ki je

najbliţje konceptu SOA, gre za dostavo storitev v obliki delujoče programske rešitve

(običajno preko brskalnika) in ne »kosa aplikacije«, ki izvaja določene operacije. Drugo

razliko predstavlja tudi dejstvo, da v oblaku ne gre samo za dostavo storitev, ampak tudi za

izvajanje programske kode (25).

Model SOA je k razvoju računalništva prispeval veliko rešitev, če ne ţe razvitih, pa idejnih,

kot so npr. celovit arhitekturni pristop (angl. end-to-end architectural approach), upravljanje

(angl. governance), interoperabilnost in ponovno uporabo. Velika prednost računalništva v

oblaku pred mreţnim računalniškim modelom je tudi širok spekter uporabe virtualne

infrastrukture. Informacij, storitev in procesov brez dobre strategije in učinkovitega

upravljanja v oblaku ne moremo učinkovito uporabljati. Rešitev danes, kot del poslovne

arhitekture, predstavlja SOA, katere koncepti dajejo ogrodje za uporabo računalniških virov.

Rezultat so vmesniki, s katerimi povezujemo IT-infrastrukturo z oblakom in poslovnim

svetom. SOA ni evolucijski korak, preko katerega preidemo v računalništvo v oblaku in

19

SAP – najbolj razširjen ERP (angl. Enterprise Resource Planning) sistem.


računalništvo v oblaku ne zamenjuje SOA. SOA dejansko omogoča računalništvo v oblaku in

predstavlja »vmesno postajo«, ki vodi v oblake (7).

S stališča razvoja programske opreme, gre pri SOA za proces definiranja IT rešitve oz.

kompozitne arhitekture, katere najvišji nivo predstavljajo poslovni procesi. Pri računalništvu v

oblaku pa gre za infrastrukturo, platformo ali izvajalno okolje, ki omogoča razvoj, izvajanje in

obračunavanje razširjenih rešitev SOA. Na sliki 3.4 je prikazan razvojni cikel aplikacij, ki je

pri SOA in konceptu računalniškega oblaka enoten, saj kot bomo spoznali v naslednjem

poglavju, SOA predstavlja najboljšo arhitekturno rešitev za aplikacije, ki se bodo izvajale v

oblaku. V razvojem ciklu nismo vključili testiranja, ker je prisotno na več nivojih.

Slika 3.4: Razvojni cikel aplikacij SOA (20)

Identifikacija

Modeliranje

Implementacija

Kompozicija

Namestitev

Izvajanje

Nadzor

Analiza in optimizacija


4 RAZVOJ APLIKACIJ ZA OBLAK

V tem poglavju bomo predstavili celovit razvoj poslovnih aplikacij, ki se lahko izvajajo v

računalniškem oblaku. Opisali bomo osnovno metodologijo, ki razširi arhitekturo poslovnih

IT rešitev v arhitekturo, ki učinkovito izkorišča vse prednosti infrastrukture računalniškega

oblaka. Glavni koraki metodologije so prikazani na sliki 4.1. Vrstni red lahko tudi obrnemo,

vendar smo tukaj ubrali pot razvoja, ki je običajno laţja. Začeli bomo z definiranjem in

strukturiranjem podatkov. Nadaljevali bomo z definiranjem storitev in kasneje kompozitnih

procesov. Na koncu bomo pa opisali še vodenje oz. upravljanje v oblaku in razvoj manjših,

spletnih aplikacij.

Slika 4.1: Koraki metodologije razvoja »oblačnih« aplikacij (26)

4.1 Nivo podatkov

Z razvojem bomo začeli pri podatkih, ki so osnova za vsak informacijski sistem.

Razumevanje podatkov in informacij je ključnega pomena za razvoj učinkovite arhitekture.

Pri podatkih je dobro začeti tudi zato, ker ţe na začetku ugotovimo, kako bomo upravljali z

informacijami, kakšno platformo bomo potrebovali za podatkovni nivo in kakšna bo politika

dostopa do podatkov. Od vsega tega je namreč odvisna izbira pravega oblaka. Semantika

podatkov je izredno pomembna, če gre za razvoj novega ali za prenovo starega sistema.

Popravljanje neprimernih podatkovnih struktur je namreč v kasnejših fazah razvoja drago in

zapleteno. Pomembno je identificirati vso semantiko20

in metapodatke, ki obstajajo v naši

20

Semantika v smislu različnih pomenov podatkov v različnih aplikacijah.

Definiranje podatkov

Definiranje storitev

Definiranje procesov

Definiranje vodenja oz. upravljanja


domeni, ker to potrebujemo za vzpostavitev dobre arhitekturne osnove, s katero definiramo

podatkovni nivo.

4.1.1 Definiranje problemske domene

Razvoj se začne z natančnim definiranjem problemske domene oz. zaključenega območja, ki

ga bo naša prihodnja informacijska rešitev obravnavala. Paziti moramo, da definirana domena

ni prevelika, saj kompleksnost z velikostjo domene hitro narašča. Če prenavljamo ali

integriramo ţe obstoječe sisteme, moramo paziti, da v problemski domeni nimamo

organizacijskih problemov. Če pa problemi obstajajo, jih moramo pred naslednjim korakom

razrešiti (26).

4.1.2 Definiranje informacijskega modela

Ko imamo natančno definirano problemsko domeno, lahko pričnemo analizirati metapodatke.

Slika 4.2 prikazuje razvoj informacijskega modela in vmesne dokumente oz. rezultate.

Najprej moramo razumeti ontologije21

podatkov in podatke same (uporaba metapodatkov).

Ontologije so zelo uporabne, ker so dober način za organiziranje informacij in za definiranje

različnih podatkovnih kontekstov. Ko razumemo podatke, jih razporedimo v kataloge (urejena

mnoţica strukturiranih podatkov), iz katerih razvijemo končni informacijski model.

Slika 4.2: Razvoj informacijskega modela (26)

21

Ontologije v smislu pomenske povezanosti in odvisnosti podatkov

Razumevanje ontologij

Razumevanje podatkov

Strukturiranje podatkov

Izgradnja inf. modela

Ontologije Imenik podatkov in meta-

podatkov

Katalog podatkov

Informacijski model


Ontološka analiza je praktična, ker poleg razjasnitve pomena podatkov v različnih kontekstih

daje tudi osnovo za generalizacijo in korespondenco entitet. V distribuiranem okolju nudi

jasen model zdruţevanja podatkov iz več virov. Če imamo enostavno problemsko domeno,

lahko ontološko analizo tudi izpustimo.

Naslednji korak je razumevanje in identifikacija poslovnih podatkov. Če ţe obstajajo

podatkovne shrambe (datoteke ali podatkovne baze), jih moramo preučiti in razumeti. Namen

analize podatkov je, da pridobimo metapodatke in druge informacije o vseh podatkih.

Rezultat je podatkovni imenik, ki vsebuje (26):

razloge, da elementi podatkov obstajajo,

lastništvo podatkov,

formate podatkov,

varnostne parametre in

vlogo podatkov v logičnih in fizičnih podatkovnih strukturah.

Ko imamo podatkovni imenik, pričnemo s formalizacijo vseh do sedaj pridobljenih

informacij. Rezultat je katalog podatkov, ki se od podatkovnega imenika razlikuje po obsegu.

Imenik obsega en sistem ali aplikacijo, katalog pa se nanaša na več sistemov v naši domeni.

Dober katalog vsebuje opise, lastništvo, format in odvisnosti podatkov ter opise sistemov,

varnostne parametre in parametre za integriteto. Za uporabo v oblaku lahko dodatno opišemo

ali specificiramo mehanizme in protokole za povezovanje, varnostne nivoje ipd. Dober

katalog nam daje celovit pregled nad vsemi podatki, ki spadajo v našo problemsko domeno.

Ko imamo vse potrebne informacije o podatkih, se usmerimo na metapodatkovni poslovni

model oz. informacijski model. Na katalog podatkov lahko gledamo kot na mnoţico

potencialnih arhitekturnih rešitev, informacijski model pa predstavlja končno rešitev. Dobra

praksa pravi, da moramo narediti dva modela – logični in fizični model. Logični model

predstavlja arhitekturno rešitev (običajno ERD-diagram) za vse podatke, ki jih bomo

shranjevali. Nudi objektiven in integriran pregled nad poslovnimi podatki. Razlika med

takšnim in tradicionalnim pristopom je, da pri logičnem modelu izviramo iz podatkov, pri

tradicionalnem pristopu pa model nastane iz poslovnih zahtev. Fizični model je vezan na tip

podatkovne baze in zanj potrebujemo logični model in katalog podatkov (26).


4.2 Nivo storitev

Kaj so storitve, smo opisali ţe v tretjem poglavju. Če povzamemo, storitve definirajo

obnašanje in nekaj delajo oz. imajo neko funkcijo. Na storitve gledamo kot na mnoţico

funkcionalnih enot, ki jih lahko proţimo posamično ali pa kot skupino. Lahko jih mešamo in

zlagamo v kompozitne aplikacije, kar nam omogoča agilnost in učinkovito izkoriščanje

oblačne arhitekture. Takšno fleksibilno arhitekturo lahko po potrebi spreminjamo, če se

spremenijo poslovni procesi. Dobro definirane storitve so tudi platformsko in lokacijsko

neodvisne, kar pomeni, da se lahko izvajajo v oblaku ali izven njega in so dostopne iz obeh

sistemov.

Na arhitekturo informacijske rešitve običajno gledamo kot na mnoţico storitev, ker je takšen

pristop najlaţji – začetno arhitekturo razbijemo na logične in funkcionalne primitive, ki jih

sestavimo v storitve. Storitve običajno gradimo nad informacijskim modelom, ki ga ţe

imamo. Ko imamo to mnoţico storitev na voljo, lahko tudi ugotovimo, katere storitve so

primernejše za oblak, katere pa za lokalno uporabo, če gradimo sistem, ki ni v celoti v oblaku.

Slika 4.3 prikazuje prehod iz podatkovnega nivoja na nivo storitev. Na desni strani imamo

problemsko domeno, opisano s strukturo poslovnih podatkov, na levi pa domeno opišemo s

storitvami. V naslednjem razdelku bomo opisali, kako preidemo iz podatkovnega nivoja do

seznama storitev, ki podpirajo zahteve oz. specifikacije problemske domene (26).

Slika 4.3: Nivo podatkov in nivo storitev (26)

PODATKI

AP

LIK

AC

IJA

NIVO STORITEV NIVO PODATKOV


4.2.1 Definiranje storitev

Na sliki 4.4 je prikazan razvoj modela storitev. Najprej definiramo vse potrebne storitve, nato

jih poveţemo s podatki oz. informacijami, na koncu pa sestavimo še končen model storitev.

Slika 4.4: Razvoj modela storitev (26)

Vhod predstavljata informacijski model in katalog podatkov, saj temelj storitev predstavljajo

podatki. Ko razumemo problematiko s stališča storitev (upoštevani koncepti SOA), sestavimo

seznam potencialnih storitev, ki vsebuje imena storitev in opise njihovih funkcionalnosti. Tem

storitvam pravimo tudi kandidati storitev. Če nismo prepričani, da je storitev, o kateri

razmišljamo, pravilna ali upravičena, jo vseeno dodamo na seznam kandidatov – odstranimo

jo še vedno lahko kasneje. Sledi povezovanje kandidatnih storitev s podatki, ki so vezani na te

storitve. Storitev, kot je na primer rezervacija hotelske sobe, je povezana s podatki o stranki,

sobi in rezerviranih terminih. Ko imamo vse storitve povezane s pripadajočimi podatki,

izberemo končno mnoţico storitev, ki so relevantne našim zahtevam. Končnemu, običajno

hierarhično urejenemu seznamu storitev pravimo model storitev, ki definira arhitekturni

model na nivoju storitev (26).

Če ţe imamo aplikacijo ali večji del poslovnega informacijskega sistema razvitega s

storitveno arhitekturo, lahko postopoma storitve premaknemo v oblak. Če smo arhitekturo

dobro zasnovali, to ne bi smel biti problem. Migracije se lotimo postopoma, kot prikazuje

slika 4.5. Na levi strani je prikazan klasičen model SOA. Vse storitve imamo na »naši strani«

in ničesar ne gostimo v oblaku. V oblak lahko prestavimo samo nekatere storitve, kot je to

prikazano na sredini slike 4.5, če pa ţelimo premakniti celotno aplikacijo v oblak, najprej

Razumevanje storitev

Povezovanje informacij in

storitev

Izgradnja modela storitev

Kandidati storitev

Storitve +

informacije

Model storitev

Katalog podatkov

Informacijski model


prenesemo podatkovno bazo, nato po postopoma prenašamo storitve v oblak in jih obvezno

testiramo (posamični in integracijski testi). Rezultat je prikazan na desni strani slike 4.5. Za

izvajanje naših poslovnih procesov ne potrebujemo več lastne infrastrukture.

Slika 4.5: Postopni premik storitev v računalniški oblak

Da lahko storitve učinkovito logično in fizično premikamo, ne smejo biti močno sklopljene,

zato bomo v naslednjem razdelku predstavili pomen šibke sklopljenosti in opisali vrste

odvisnosti, ki jih je potrebno minimizirati.

4.2.2 Pomen šibke sklopljenosti storitev

Koncept sklopljenosti oz. nivoja medsebojne odvisnosti storitev je v oblačni arhitekturi zelo

pomemben. Tesna sklopljenost je nezaţelena ţe v SOA, v modelu računalništva v oblaku pa

še toliko bolj, ker se storitve lahko izvajajo ne samo na različnih streţnikih, ampak tudi pri

različnih ponudnikih storitev v oblaku. Čim višji je nivo sklopljenosti, oz. čim bolj

medsebojno odvisne storitve imamo, tem teţje je te storitve spreminjati, prilagajati in

posodabljati. Spremembe na eni storitvi zaradi odvisnosti vplivajo na delovanje drugih

storitev, česar ne ţelimo. Čim šibkeje sklopljene storitve imamo, tem agilnejša in

fleksibilnejša je naša arhitektura. Zato si prizadevamo za čim niţjo sklopljenost, na katero

najbolj vplivajo štirje faktorji:

Lokacijska neodvisnost – pomeni, da storitve lahko fizično in logično premikamo

Komunikacijska neodvisnost – pomeni, da lahko storitve med seboj komunicirajo

…

Naša infrastruktura (vse storitve)

Ponudnik računalniškega oblaka

…

…

Naša infrastruktura (del storitev)

Oblak – vse storitve

Oblak – del storitev


neodvisno od komunikacijskih protokolov, zato so to priročne spletne storitve.

Varnostna neodvisnost – pomeni razliko med varnostnimi modeli in med

komponentami. Za to potrebujemo federativni varnostni sistem, da lahko definiramo

območja zaupanja ne glede na varnostni model komponent.

Neodvisnost instanc – pomeni, da arhitektura podpira sinhrono in asinhrono

komunikacijo med komponentami, neodvisno od trenutnega stanja komponent.

4.2.3 Metastoritve in imenik storitev

Ko imamo storitve definirane, jih opišemo podobno kot podatke – dobimo metastoritve, ki

opišejo semantiko, validacijske omejitve in formate storitev ipd. Če kot primer pogledamo

spletne storitve, ki so opisane z WSDL, nam manjka kar nekaj informacij, kot so namen, opisi

vmesnikov, opisi parametrov, pravila, poslovna logika, lastništvo, semantika, vključene

storitve ipd. Vsi ti atributi se določijo v imeniku storitev, ki nam omogoča celovit pregled nad

mnoţico storitev, ki je lahko v zapletenih sistemih velika. Kaj vključuje dober imenik storitev,

je prikazano v tabeli 4.1 (26). Primer velikega imenika poslovnih storitev je UDDI.

Tabela 4.1: Atributi imenika storitev

Semantika Vključene storitve

Namen Lokacija vključenih storitev

Avtentikacija Funkcijske točke

Odvisnosti Diagrami toka podatkov

Nivo storitve Strukturni diagrami

Lastništvo Definicije vmesnikov

Tehnologija Revizije programske kode

Programski model Načrti testiranj

Atributi zmogljivosti Rezultati testiranj

Validacija podatkov Razvojna okolja

Imenik storitev vodi v repozitorij SOA in vsebuje osnovne informacije o storitvah, ki rešujejo

našo problemsko domeno. Arhitektom in programerjem nudi neprecenljiv vir informacij, brez

katerih bi razvoj potekal počasneje, saj minimizira potrebo po komunikaciji.


4.3 Nivo procesov

Ko imamo storitve natančno definirane, se lahko premaknemo na najvišji nivo – na nivo

poslovnih procesov. Pri procesih gre za natančno definirano zaporedje dogodkov, ki delno ali

popolnoma avtomatizira neko poslovno dejavnost. Koncept poslovnih procesov smo ţe

obravnavali v tretjem poglavju. Če na kratko povzamemo – pri procesih ne gre za

tradicionalno programsko logiko (kot sta npr. procesiranje ali izvajanje transakcij), ampak gre

za koordinacijo in upravljanje informacijskega toka in dinamičnega proţenja storitev, glede

na poslovna pravila. Če koncepte še poenostavimo, gre za dodaten nivo, ki je nad storitvami.

Na tem nivoju storitve povezujemo v kompozitne enote, ki so sposobne izvajati en del ali

celoten poslovni proces.

4.3.1 Definiranje procesov

Definiranje procesov je pomemben korak, za katerega imamo ţe dobro osnovo – podatkovni

in storitveni pogled na problemsko domeno. Na sliki 4.6 je prikazan razvoj procesnega

modela. Kot vhod dobimo katalog podatkov, informacijski model in model storitev.

Razumevanje procesov je ključnega pomena za uspešno realizacijo informacijske rešitve.

Razumeti moramo vse procese – avtomatizirane in neavtomatizirane. Ko procese razumemo

in visokonivojsko definiramo (ne podrobno), nastane seznam kandidatnih procesov (koncept

je podoben kot pri storitvah). V naslednjem koraku poveţemo storitve s procesi. Namen je

povezati storitve tako, da učinkovito podprejo poslovni proces, hkrati pa naredijo proces šibko

sklopljen. V zadnji fazi pa nastane procesni model. Ta vključuje samo procese, ki bodo

vključeni v končno arhitekturno rešitev.

Slika 4.6: Razvoj procesnega modela (26)

Razumevanje procesov

Povezovanje storitev in procesov

Izgradnja procesnega

modela

Informacijski model

Katalog podatkov

Model storitev

Kandidati procesov

Storitve +

procesi

Procesni model


4.3.2 BPM

Če modelov poslovnih procesov še nimamo, jih običajno modeliramo skupaj z naročniki.

Lahko jih pretvorimo v izvršljivo kodo, ki dejansko izvaja poslovni proces. Takšen koncept

definira BPM (angl. Business Process Management); običajno ga sestavljajo:

Orodje za grafično modeliranje – definiranje obnašanja (npr. BPMN).

Pogon za poslovne procese – omogoča izvajanje poslovnih procesov (definiranih z

npr. BPEL). Skrbi tudi za ohranjanje stanj in za interakcije med različnimi sistemi.

Vmesnik za nadzor poslovnih procesov – omogoča pregled in nadzor nad izvajanjem

poslovnih procesov v realnem času.

Vmesnik pogona za poslovne procese – omogoča, da zunanje aplikacije dostopajo do

poslovnih procesov.

Integracijska tehnologija – omogoča integracijo (komunikacijo) poslovnih storitev.

BPM je tehnologija in strategija, ki nam omogoči interakcijo z več sistemi (sistemi v lastni

organizaciji in sistemi izven nje). Proces se lahko razteza med nami in več organizacijami in

več oblaki. To je mogoče, ker BPM podpira veliko različnih tehnologij in platform, kar

zagotovi interoperabilnost. BPM se nanaša tudi na ljudi in ostale »ne IT« entitete, ki

sodelujejo pri procesih.

BPM za računalništvo v oblaku pomeni dodaten sloj, ki omogoča visokonivojsko integracijo

(B2B) različnih računalniških oblakov in lokalnih storitev. Ena BPM instanca se lahko razteza

čez več instanc sistemov in hkrati definira glavno aplikacijo (angl. master application), ki

daje vpogled v enkapsulirane storitve in informacije. Vodi tudi izvajanje procesov in je

neodvisen od storitev, kar pomeni laţjo migracijo določenih delov procesa v oblak ali laţje

vzdrţevanje, ponovno vzpostavitev ipd (26).

4.4 Nivo vodenja oz. upravljanja

Zadnji korak v naši metodologiji je vodenje oz. upravljanje procesov in računalniškega

oblaka. Problematiko upravljanja računalniškega oblaka dobro opiše citat Charles De Gaullea:

»Kako upravljati drţavo, ki pozna 246 vrst sira?« Računalništvo v oblaku je uporabno samo,


če imamo moţnost učinkovitega upravljanja. Na voljo imamo arhitekturo za celotno

informacijsko rešitev, ki vsebuje veliko podatkov, storitev in procesov. Definirati in nadzirati

moramo dostop, dodajanje, spreminjanje in brisanje le-teh. Za vse to potrebujemo pristop,

procedure in tehnologijo. Upravljanje pomeni načrtovanje, modeliranje, razvijanje, testiranje

in implementacijo politike za storitve in nadzor njihove uporabe. Upravljanje storitev je za

računalništvo v oblaku najpomembnejše, saj naša arhitektura temelji na storitvah. Politika

upravljanja je (v SOA in v konceptu računalništva v oblaku) definirana z deklarativnimi

pravili, ki določajo dostop do storitev. Ker ta način pozna ţe SOA, ga tukaj ne bomo

podrobneje opisali. Upravljanje in vodenje je pri velikem številu storitev zapleteno ţe v SOA,

v računalniškem oblaku pa se kompleksnost še poveča, zato je načrtovanje vodenja naše

arhitekture pomembno. Politiko vodenja moramo skrbno načrtovati in nato razviti ter

implementirati model vodenja, ki pokriva celotno problemsko domeno. Poskrbeti moramo za

učinkovito vodenje v času izvajanja in zagotoviti neprestano beleţenje, ki nam omogoča

povratno sledenje.

4.5 Pogled na testiranje

Kot vemo, je testiranje pomembno pri razvoju vseh vrst informacijskih sistemov. Za oblačne

rešitve je testiranje še toliko pomembnejše, saj običajno nimamo popolnega nadzora nad

našimi storitvami, ki se izvajajo v računalniškem oblaku. Pomembno je poudariti, da nam

omejen dostop in nadzor preprečujeta nekatere vrste testiranj (obremenitveni testi, testiranje z

belo škatlo ipd.). Ključno vprašanje je, kako testirati oblačno arhitekturo. Testiranje v oblaku

predstavlja zahteven distribuiran problem, ki ga rešimo podobno kot pri SOA. Testiranje v

SOA lahko razdelimo na štiri kategorije: testiranje na nivoju storitev, testiranje na nivoju

procesov, testiranje na nivoju vodenja oz. upravljanja in testiranje na nivoju informacij.

Koncept računalništva v oblaku vpeljuje še obvezno integracijsko testiranje in celovito

varnostno testiranje (testiranje varnostne politika in komunikacije). Našo arhitekturo

razgradimo na komponente, ki jih (izolirane) laţje testiramo. S komponentnim testiranjem

zagotovimo pravilno delovanje na nivoju storitev in manjših podprocesov. Šele po uspešnem

testiranju komponent se lotimo integracijskega testiranja, ki nam zagotovi pravilno delovanje

na nivoju poslovnih procesov.


4.6 Spletne aplikacije v oblaku

Ko razvijamo poslovne aplikacije, ki se bodo izvajale v oblaku, imamo v mislih novodobne

SOA aplikacije, ki izkoriščajo arhitekturne prednosti računalniškega oblaka. Del poslovne

rešitve, ki skrbi za komunikacijo med odjemalci in poslovnimi procesi (angl. front-end), je

običajno spletna aplikacija. Arhitektura spletnih aplikacij je običajno odvisna od uporabljene

tehnologije (ASP.NET, Java, Ruby, PHP itd.), vendar gre tipično za šest elementov, ki jih

lahko med seboj poveţemo na več načinov. Generični model arhitekture spletne aplikacije je

prikazan na sliki 4.7. Vsaka aplikacija vsebuje uporabniški vmesnik, ki podaja vsebino in

podatke, ki jih objektni poslovni model dostavi iz podatkovne baze (3). Uporabniškemu

vmesniku v takšnem modelu pravimo pogled (angl. view), modelu poslovnih objektov

pravimo kar model (angl. model), akcijam, ki proţijo spremembe, pa kontrolnik (angl.

controller). Če to zdruţimo, dobimo arhitekturni model iz 80' – MVC (angl- model-view-

controller), ki ločuje nivo poslovne (aplikacijske) logike od akcij (vhoda) in od

prezentacijskega nivoja.

Slika 4.7: Generičen model spletnih aplikacij (3)

Spletna aplikacija lahko uporablja tudi storitve, ki jih uporabljajo poslovni procesi, kar

pomeni, da poslovni objekti spletne aplikacije ne dostopajo do podatkovne baze, ampak do

storitev, ki predstavljajo vmesnik do podatkov.

Spletni

brskalnik

Uporabniški

vmesnik

Poslovni

objekti

Podatkovna

baza

Akcije

Vsebina


4.7 Problem stanj in zagotavljanje podatkovne integritete

Ko se premaknemo v oblak, postane upravljanje s stanjem izredno pomembno. Problematiko

bomo najlaţje razumeli, če si pogledamo primer. Recimo, da razvijamo storitev za rezervacijo

hotelske sobe in da imamo podatkovno bazo in poslovni objektni model ţe realiziran. Kako

aplikacija spremeni stanje med tem, ko uporabnik pošlje zahtevo, in med izvedbo transakcije

nad podatki? Osnovni proces lahko definiramo v takšnem zaporedju:

Zaklenemo podatke, ki so povezani s sobo.

Pogledamo, ali je soba prosta.

Če je soba prosta, jo rezerviramo.

Odklenemo podatke, ki so povezani s sobo.

Takšen proces lahko implementiramo na več načinov in vsi niso primerni za oblak. Običajen

»javanski« pristop, ki je prikazan v izvorni kodi 1, deluje pravilno v okolju z enim

streţnikom. Čim pa uporabimo več streţnikov, pride do problemov.

Izvorna koda 1: Sinhronizacijska implementacija rezervacije sobe (3)

Problem je, ker zaklenemo dostop (synchronized) do objekta »soba«, kar pomeni, da nobena

druga nit v procesu ne more spreminjati objekta. Če dva odjemalca pošljeta dve zahtevi na isti

streţnik, se izvedeta ena za drugo – ko prva zahteva zaklene objekt, druga čaka in se izvede,

ko se vsi viri sprostijo. Če pa odjemalca pošljeta zahtevi na dva različna streţnika (ali

uporabljata dva različna procesa na istem streţniku), se sinhronizacijski blok izvede pravilno

pri obeh zahtevah in pride do dvojne rezervacije. Druga rezervacija enostavno prepiše podatke

prve rezervacije. Aplikacije, ki so večnitne in uporabljajo zaklepanje pomnilnika za

sinhronizacijo, še vedno delujejo v oblaku, vendar jih ne smemo uporabljati na več

aplikacijskih streţnikih. Edino rešitev za takšne aplikacije predstavlja sistem zaklepanja z

public void rezervirajSobo(Stranka stranka, Soba soba, Date[] dnevi)

throws RezervacijaException {

synchronized(soba) {

if(!soba.jeProsta(dnevi) ) {

throw new RezervacijaException("Soba ni prosta!");

}

soba.rezerviraj(stranka, dnevi);

}

}


deljenim zaklepnim mehanizmom (angl. shared locking mechanism), ki ga običajno ţe

podpirajo streţniki za podatkovne baze.

Ko naša transakcijska logika za zagotavljanje integritete uporablja tehniko zaklepanja

pomnilnika, izgubimo vse moţnosti dinamične skalabilnosti in elastičnosti oblaka. Da se temu

izognemo, lahko uporabimo tehnologije gruč oz. tako imenovane večstreţniške deljene

pomnilne sisteme (angl. cross-server shared memory systems) ali pa kot avtoriteto postavimo

podatkovno bazo, ki sama upravlja s stanjem. V tem primeru za transakcije uporabimo

podatkovni streţnik (shranjene procedure) in zagotovimo integriteto podatkov tudi pri sočasni

uporabi več aplikacijskih streţnikov. Shranjene procedure sicer imajo performančno prednost,

a so tesno povezane s podatkovno bazo, kar onemogoči prenosljivost. Za dobro

implementacijo shranjenih procedur potrebujemo tudi veliko znanja in izkušenj. Če ţelimo

ohranjati vso logiko na aplikacijskih streţnikih, hkrati pa zagotavljati večstreţniško

transakcijsko integriteto, potrebujemo mehanizme, ki preprečujejo nevarne posege v podatke,

ali pa zaklenemo podatke na nivoju podatkovne baze. Učinkovit način je skupna uporaba

časovnih značk (angl. timestamp) in beleţenja uporabnikov zadnje posodobitve, kot je

prikazano v izvorni kodi 2. Če pogledamo naš primer z dvema odjemalcema, ki ţelita

rezervirati isto hotelsko sobo, se zgodi naslednje. Prvi odjemalec uspešno rezervira sobo (in

spremeni časovno značko in uporabnika zadnje posodobitve), pri drugem pa do posodobitve

ne pride, ker se časovna značka zadnje posodobitve in uporabnik zadnje posodobitve ne

ujemata.

Izvorna koda 2: Primer posodobitve z uporabo časovnih značk (3)

Takšen način je ustrezen za večstreţniško okolje, a moramo pri strukturiranju transakcij

izredno paziti, da ne omogočimo popolnega zastoja oz. zaklepa (angl. deadlock). Do

popolnega zaklepa pride med dvema transakcijama, ki medsebojno čakata na sprostitev virov.

V našem primeru to lahko ilustriramo tako, da oba odjemalca ţelita rezervirani isto sobo za

ponedeljek in torek. Če prvi odjemalec začne preverjati prostost sobe za ponedeljek, drugi pa

UPDATE rezervacija

SET stranka = ?, cas_zadnje_posodobitve = ?, uporabnik_zadnje_posodobitve = ?

WHERE rezervacija_id = ?

AND cas_zadnje_posodobitve = ?

AND uporabnik_zadnje_posodobitve = ?;


za torek (ali obratno), pride do popolnega zaklepa. Prvi odjemalec ne more nadaljevati, ker

čaka drugega, da potrdi rezervacijo za torek. Hkrati pa drugi odjemalec čaka na prvega, da

potrdi torek. Takšne probleme lahko rešimo z uvedbo dodatnih časovnih značk, ki povedo,

kdo in kdaj je zaklenil vir. Te nastavimo pred začetkom izvajanja transakcije za rezervacijo

sobe in jih spet sprostimo po končani transakciji (3).

Pri razvoju aplikacij, ki se bodo izvajale v računalniškem oblaku, je potrebno poudariti, da se

pri zagotavljanju integritete stanja aplikacije (angl. application state integrity) ne smemo

zanašati na zaklepanje pomnilnika.

4.8 Načrtovanje strojne slike

Dve posredni prednosti infrastrukture oblaka, katerih pomembnost velikokrat opazimo, ko je

ţe prepozno, sta:

natančno načrtovanje namestitve (angl. deployment planning) in

natančno načrtovanje ponovne vzpostavitve (angl. disaster recovery planning).

Ker se v računalniškem oblaku uporabljajo virtualni streţniki, ki uporabljajo strojne slike

(angl. machine images), moramo pri premiku v infrastrukturo oblaka najprej definirati in

razviti ponovljiv namestitveni proces, ki ga zagotovi celotno izvajalno okolje. Temu pravimo

načrtovanje namestitve. Če je aplikacija ţe del namestitve, je za zagon aplikacije v oblaku

potrebno samo naloţiti strojno sliko, iz katere se zaţene nova virtualna instanca. Kako

aplikacijo namestiti v računalniški oblak, si bomo v kasnejših poglavjih pogledali ob

platformi IBM.


5 PLATFORMA IBM ZA RAZVOJ OBLAČNIH REŠITEV

V tem poglavju bomo predstavili del platforme IBM WebSphere, ki omogoča razvoj sodobnih

rešitev SOA. IBM WebSphere je platforma za integracijo aplikacij, procesov, informacij in

ljudi. Vsebuje celotno infrastrukturo vmesnega sloja (streţnike, storitve in orodja), ki

omogoča razvoj, izvajanje in nadzor integriranih informacijskih rešitev. WebSphere

Application server (WAS) je osnova za celotno infrastrukturo. Opisali bomo WebSphere

Process Server in WebSphere Enterprise Service Bus, ki temeljita na WAS in predstavljata

platformo za aplikacije SOA. Podrobneje pa bomo predstavili WebSphere CloudBurst

Appliance in WebSphere Application Server Hypervisor Edition, ker ju bomo uporabili v

praktičnem delu diplomske naloge.

5.1 IBM WebSphere CloudBurst Appliance

WebSphere CloudBurst Appliance ali krajše WCBA predstavlja strojno komponento, ki ima

vlogo celovitega upravljavca računalniškega oblaka. Optimizira konfiguracijo, namestitev in

upravljanje z okolji WebSphere Application Server v oblaku. Čeprav je WCBA primarno

namenjen za lokalne zasebne oblake, se ga lahko uporabi tudi za gostitev javnih oblakov in

okolij SaaS. Naprava ne deluje samostojno, ampak potrebujemo strojno opremo, na kateri se

izvaja dejanska virtualizacija. Omogoča enostaven razvoj, testiranje in namestitev okolja za

poslovne aplikacije. Njegova glavna vloga je namestitev in nadzor izvajalnih okolij. Ko

imamo WCBA topologijo postavljeno, se lahko uporabniki in administratorji povezujejo

neposredno v okolja WAS. Potrebno je izpostaviti, da WCBA nima nikakršne vloge pri

izvajanju okolij WAS– skrbi izključno za namestitev in nadzor. Poleg strojne opreme dobimo

tudi prednastavljene virtualne slike WAS Hypervisior Edition in vzorce topologij WebSphere.

WCBA lahko uporabljamo z vso strojno opremo, na kateri se izvaja podprt nadzornik

virtualnih strojev (npr. VMware ESX, ESXi ali XEN) (27).


Na sliki 5.1 je predstavljena strojna enota IBM WebSphere CloudBurst Appliance in vse

njene glavne komponente. Katalog ponuja gradnike, iz katerih sestavimo topologijo

WebSphere (vzorec), ki jo lahko namestimo v računalniški oblak. Vzorci predstavljajo zbirko

topologij, ki definirajo arhitekturo virtualnega oblaka. Na voljo imamo ţe nekaj osnovnih

vzorcev (en streţnik, gruča s štirimi streţniki in večja gruča s petnajstimi streţniki), ki si jih

lahko prilagodimo ali pa generiramo nove. Infrastruktura in viri vsebujejo informacije o

strojni opremi, upravljavce virtualnih strojev, varnostno politiko in mnoţico podomreţnih IP

naslovov, ki jih WCBA uporabi pri nameščanju virtualnih slik WebSphere. Virtualni sistemi

vsebujejo nameščene vzorce in vse potrebne informacije za njihovo delovanje (28).

Slika 5.1: Struktura IBM WebSphere CloudBurst Appliance

Pred WCBA je bilo nameščanje okolja WAS (ena celica) na distribuiran sistem dokaj

zapleteno opravilo. Administrator je moral na primarni streţnik namestiti WAS in narediti

profil upravljavca namestitev (angl. deployment manager profile). Za tem je moral na vse

ostale streţnike namestiti WAS in narediti profil za vozlišče (angl. custom node profile). Na

zadnji streţnik je moral namestiti še IBM HTTP streţnik in osnovna infrastruktura je bila

vzpostavljena. Sledila je administracija: zdruţevanje vozlišč in nastavitve IBM HTTP

Katalog

Vzorci Virtualni

sistemi

Infrastruktura

in viri

Aplication Server

Admin Agent

Custom Node

IBM HTTP Server

Deployment Manager

Job Manager

Deployment Manager

Custom Node Custom Node

…

Deployment Manager

Custom Node

IBM HTTP Server

Custom Node

Custom Node

Custom Node

Hypervisors


streţnika na upravljavcu namestitev, nameščanje aplikacije ter nastavitve varnostne politike.

Za laţjo administracijo je na voljo upravljavec za centralizirano nameščanje oz. CIM (angl.

centralised installation manager), vendar je še vedno potrebno izvesti veliko število opravil,

ki jih na distribuirani infrastrukturi CIM ne zmore.

Vzpostavitev nove topologije WebSphere s pomočjo WCBA je veliko enostavneje. Najprej je

potrebna konfiguracija WCBA, kjer definiramo strojno opremo (mnoţica streţnikov na katere

WCBA lahko namešča virtualna okolja) in varnostno politiko (dostop do strojne opreme ipd.).

Na pravilno konfigurirani enoti administrator najprej definira ţeleno topologijo oz. vzorec. Iz

kataloga izbere vse potrebne komponente (glej sliko 5.1) in jih premakne na načrtovalno

podlago. Za vsako komponento je potrebno nastaviti število virtualnih procesorjev, velikost

pomnilnika, ime celice, ime vozlišča, dve gesli (»root« in »virtuser«) in moţnost VNC22

. Ko

imamo vzorec definiran, mu lahko dodamo lastne programske rutine in aplikacije, ki se

samodejno namestijo, ko se topologija vzpostavi. WCBA sam namesti topologijo tako, da

inteligentno izbere razpoloţljive streţnike, ki najbolj odgovarjajo topološkim zahtevam. Ko je

infrastruktura vzpostavljena, se komponente zdruţijo v delujočo celico, nato pa se namestijo

rutine in aplikacije, ki smo jih definirali v vzorcu. Če administrator ţeli dodati v topologijo

nov streţnik, to lahko stori hitro in enostavno. WCBA lahko sam izbere najprimernejši

streţnik in ga dinamično vključi v topologijo. Ko je virtualni oblak (eden ali več upravljavcev

virtualnih strojev) vzpostavljen, se administrator in uporabniki poveţejo neposredno na

virtualne streţnike. Velika prednost vzorcev je, da so prenosljivi. Administrator lahko na

različne infrastrukture hitro in učinkovito namesti identične topologije, če ima na voljo vzorec

WCBA. Če povzamemo, razvojni WCBA podpira celoten cikel namestitve WAS in vključuje

tri faze (angl. virtualize-dispense-manage), ki jih specificira IBM:

virtualiziranje – iz kataloga (virtualne slike WAS in vzorci) sestavimo topologijo

razširitev – vzorec se namesti na infrastrukturo (na upravljavce navideznih strojev)

upravljanje – upravljanje z virtualnimi streţniki, generiranje poročil ipd.

Procesu, ki iz vzorca generira dejansko virtualno topologijo, pravimo aktivacija. Vsaki

virtualni sliki se pred nameščanjem na enega izmed upravljavcev virtualnih strojev priredi

22

VNC – omogoča oddaljen dostop do virtualnih streţnikov


unikaten IP. Po uspešni avtentikaciji (administratorsko geslo operacijskega sistema in

administratorko geslo WebSphere) in specifikaciji imen vozlišč in celice se po vrsti aktivirajo

vse virtualne slike v vzorcu. Ko je okolje vzpostavljeno, lahko WCBA odstranimo, ker ne

vpliva na delovanje virtualnega oblaka (28). WCET vsebuje tudi API za storitve REST, ki se

uporabljajo za integracijo. Upravljanje lahko prevzamejo večji poslovni upravljavci za

storitve in avtomatizacijska orodja, kot je IBM Tivoli, ki imajo moţnost nastavljati skupine

uporabnikov, vire, licence ipd.

5.2 IBM WebSphere Application Server Hypervisor Edition

Kot smo ţe povedali, je upravljavec virtualnih strojev programska oprema, ki omogoča

sočasno izvajanje več operacijskih sistemov na istem računalniku. WCBA podpira VMware

ESX, ESXi in PowerVM. WebSphere Application Server Hypervisor Edition ali krajše WAS-

HE je optimiziran WAS za virtualno okolja, ki lahko bolj učinkovito izrabljajo računalniške

vire. Podpira WAS v6.1 in WAS v7.0. Na sliki 5.2 imamo prikazano strukturo WAS-HE.

Vsebuje operacijski sistem SUSE Enterprise Linux v10.2, IBM HTTP streţnik, virtualni

sisteme WAS, ki se lahko namestijo v virtualni oblak, in vse profile, ki spadajo zraven.

Slika 5.2: Struktura IBM WebSphere Application Server Hypervisor Edition (28)

Virtualne slike so formata OVF (angl. Open Virtualization Format), kar zagotavlja

prenosljivost in kompatibilnost. WAS-HE se lahko namesti takoj po uspešni aktivaciji. Lahko

se namesti v obliki enega streţnika (SUSE, WebSphere izvajalna koda in enostreţniški profil)

ali upravljavca namestitev (SUSE, WebSphere izvajalna koda, profil upravljavca namestitev),

ki je pogoj za nameščanje več vozlišč oz. virtualnih streţnikov.

Profili

virtualna slika WAS

IBM HTTP strežnik

SUSE 10.2


5.3 IBM WebSphere Process Server

WebSphere Process Server ali WPS je celovita integracijska platforma SOA, ki temelji na

WAS. Omogoča razvoj in izvajanje standardnih ter komponentnih integriranih aplikacij SOA.

Razširja WebSphere Enterprise Service Bus in deluje skupaj s WebSphere Integration

Developerjem. Programski model, ki se uporablja z WPS-om, smo ţe omenili v prejšnjih

poglavjih in je prikazan na sliki 5.3 Podatki so definirani s tehnologijo SDO, katero WPS

razširi v model BO. Ta vsebuje dodatne informacije, ki so pomembne za učinkovito

integracijo. Na nivoju storitev izvaja komponente SCA, na nivoju kompozicije poslovnih

storitev, pa podpira izvajanje procesov BPEL.

Slika 5.3: Programski model WebSphere Process Server

WPS nudi izvajalno okolje za poslovne procese in omogoča upravljanje koreografije

poslovnih procesov. Izvajalnemu ogrodju pravimo kontejner poslovnih procesov (angl.

business process container), ki je podoben spletnim in EJB-kontejnerjem v WAS. Ogrodje

nudi izvajalno okolje in podpira tok poslovnih procesov, hkrati pa zagotavlja interakcijo med

ljudmi in poslovnimi procesi.

5.4 IBM WebSphere Enterprise Service Bus

Kot smo ţe opisali v poglavju 3.1.1.1, je skupno storitveno vodilo zelo pomemben del

arhitekture SOA. WebSphere ESB, v nadaljevanju ESB, je IBM-ovo skupno storitveno

vodilo, ki je nameščeno na WAS. Modelu SCA doda posredovalni nivo (angl. mediation

layer) in zagotavlja inteligentno »vsak-z-vsakim« povezljivost. Slika 5.4 prikazuje skupno

SDO in BO

SCA

BPEL Procesi

Storitve

Podatki


storitveno vodilo kot hrbtenico, ki povezuje vse pomembne komponente poslovne SOA. EBS

skrbi za sporočilno komunikacijo, klice spletnih storitev in obravnava dogodke.

Slika 5.4: Struktura WebSphere ESB

ESB razširja WAS:

z vgrajenimi posredovalnimi funkcijami (nudijo integracijsko logiko za povezljivost),

z enostavnim razvijanjem komponent za posredovalne tokove,

z enostavnim vključevanjem v WID,

z interoparabilnostjo JMS in WebSphere MQ,

s podpiranjem adapterjev, ki temeljijo na JEE Connector Architeceture

ESB povezuje portale, storitvene tokove, podatke, obstoječe aplikacije, nove poslovne

storitve, zahteve SOAP, komponente B2B v skupnem izvajalnem okolju, kar pomeni celovit

nadzor na komunikacijo. Glavne prednosti ESB so: višja učinkovitost in optimizacija

omreţja, višja fleksibilnost (to zagotavlja šibka sklopljenost), ponovna uporaba, enostaven

razvoj, ki skriva zapleteno ozadje (28).

Interakcijske storitve (WS Portal Server)

Procesne storitve (WS BI Server)

Informacijske storitve (WS Information Integrator)

Partnerske storitve (WS BI Connect)

Storitve poslovnih aplikacij (WAS)

Storitve za dostop (WBI Adapters, HATS)

ESB *sporočilne vrste – MQ, prehodi – WS Gateway in posredovalci dogodkov WBI E/M Broker]


6 RAZVOJ ARHITEKTURE SKYINFO IN IMPLEMENTACIJA

STORITVE TRUSTSERVICE NA PLATFORMI IBM

Kot praktični primer razvoja aplikacije v oblačni arhitekturi bomo načrtovali arhitekturno

rešitev za aplikacijo SkyInfo. SkyInfo je aplikacija za sporočanje aţurnih in uporabniku

relevantnih informacij. Najprej bomo predstavili idejo, nato pa bomo začeli z razvojem po

metodologiji, ki smo jo opisali v četrtem poglavju. Na koncu bomo implementirali še storitev

TrustService, da lahko pokaţemo izvajanje.

6.1 Predstavitev problema

Danes, v informacijski dobi so temelj modernega ţivljenja informacije, ki poleg energije in

surovin predstavljajo vire, ki jih potrebujemo za vsakršne procese. Obvladovanje informacij je

danes dominantno znanje, saj količina informacij iz dneva v dan hitreje narašča. Velika

količina informacij pa ţal ne pomeni prednosti, ker količina in kvaliteta nista neposredno

povezani veličini. V nekem časovnem intervalu nas zanima majhna in aţurna podmnoţica

pravilnih informacij, ki nam obogati znanje. V vsakdanjem ţivljenju so za nas uporabne

najrazličnejše informacije, kot so informacije o vremenu, prometu, športnih dogodkih,

politiki, trgovskih izdelkih, koncertih in zabavah … Danes imamo na voljo kar nekaj virov

informacij (spletne strani, SMS-obvestila), vendar se teh virov ne da enostavno zdruţevati in

osebno prilagajati, poleg tega pa velika večina pridobljenih informacij ni neposredno

povezana z našim zanimanjem. Prav tako večina informacij, ki jih imamo na voljo, ni

povezana z našo trenutno lokacijo, kar si velikokrat ţelimo. Običajno nas zanimajo

informacije, ki se nanašajo na našo lokacijo. Če smo v Mariboru, nas običajno ne zanimajo

informacije o prometnih nesrečah v Ljubljani in o vremenskih razmerah na Bledu. Kako

razviti sistem za širjenje informacij, ki omogoča popolno personalizacijo (klasifikacija in

lokacijska odvisnost informacij), bomo opisali v naslednjem razdelku.


6.2 Ideja

Ideja je razviti informacijsko rešitev za masovno in inteligentno informiranje (tudi

oglaševanje) ljudi z aţurnimi in za uporabnika zanimivimi informacijami. Uporabnik je

obveščan preko mobilnega telefona ali preko spletne aplikacije. Osnovne funkcionalnosti, ki

jih zajema SkyInfo so:

Registriranje in nastavitve lastnih pravil obveščanja (kategorije, pravila).

Moţnost natančnih nastavitev relativnih razdalj (za vsako kategorijo), ki za nas

označujejo območja relevantnih informacij.

Pošiljanje informacije na dva načina:

brez GPS: ročna izbira lokacije, izbira kategorije, tekst ali fotografija,

z GPS: izbira kategorije, tekst ali fotografija in

Prejemanje informacij:

mobilna namenska aplikacija,

SMS, MMS in

spletna aplikacija.

Pregled vseh informacij in moţno filtriranje po kategorijah, oddaljenost, faktorju

zaupanja ipd.

Inteligentno in avtomatizirano prepoznavanje neresničnih informacij.

Dinamično realnočasovno ocenjevanje informacij (faktor zaupanja).

Omejevanje števila prejetih informacij.

Pošiljanje povratne informacije, ki vpliva na faktor zaupanja informacije.

Statistika informacij po kategorijah in časovnih intervalih ipd.

Koncept, na katerega se nanaša SkyInfo, je, da uporabniki dajejo informacije in jih tudi

sprejemajo. Prejemanje in oddajanje informacij je primarno na mobilnih telefonih – pri

oddajanju uporabnik napiše sporočilo, izbere kategorijo in pošlje sporočilo (v katero se

samodejno vključi tudi lokacija) v oblak, ki posreduje to sporočilo vsem uporabnikom, ki

ustrezajo vnaprej definiranim pravilom (npr. bliţina, kategorija, prioriteta …). Ko uporabnik

prejme sporočilo, ima na voljo tri moţnosti: sporočilo lahko potrdi, ovrţe ali ignorira. Če je

informacija, ki jo je prejel, pravilna in jo potrdi, faktor zaupanja informacije naraste. Če je

informacija nepravilna, jo uporabnik ovrţe, kar faktor zaupanja zmanjša. Na padanje tega


faktorja vpliva tudi čas (funkcije se določijo glede na kategorijo in vrsto informacije). Tako

doseţemo, da se nepravilne informacije same izločijo in propadejo. Idejno gledano gre za

dvosmerni »publish/subscribe« vzorec, ki je temelj za dogodkovno vodene aplikacije oz.

storitve. Uporabniki so povezani v skupen oblak (za uporabnika je neviden in nepomemben),

ki skrbi za prejemanje, pošiljanje, pregled in nadzor informacij. Te so hkrati na voljo za

statistične raziskave in analize. Slika 6.1 prikazuje osnovno arhitekturo, ki jo sestavljajo

računalniški oblak, uporabniki, administrator, mobilno omreţje in splet.

Slika 6.1: Topologija SkyInfo

6.2.1 Dodatne razširitve

Zanimivo je dinamično prilagajanje pravil za obveščanje – npr. če faktor zaupanja informacije

naraste nad vnaprej določeni prag (informacija postane pomembnejša), se poveča radij

(razdalja) za pošiljanje informacij (dogodek - akcija) vsem uporabnikom.

Zanimiv aspekt je tudi personalizirano oglaševanje – trgovine lahko razen navadnega

oglaševanja ponujajo tudi lokalizirane oglase. Če je uporabnik v bliţini trgovine in ima

omogočeno oglaševanje, prejme oglas. Ker sistem SkyInfo hrani vse informacije, sčasoma

pridobimo veliko količino lokacijsko povezanih informacij, nad katerimi lahko izvajamo

poslovno inteligenco, prepoznavamo vzorce ali ponavljajoče se dogodke, ki so vezani na čas

ali kraj dogodka. Izvajamo lahko raznovrstne analize, statistiko za promet, vreme ipd.

Spletni strežnik

Aplikacijski strežnik

Podatkovni center

Uporabniki

Administrator

Uporabniki

Informacije s spleta

SkyInfo


Zaradi popolne personalizacije in dinamičnega prilagajanja sistema se ponuja tudi moţnost

privatnega avtonomnega oblaka za organizacije in institucije, kot so pošta, policija, vojska,

reševalci in podjetja (prevozniki, podjetniki …). Zanj se lahko definirajo drugačna, specifična

pravila in interne kategorije. S tem pridobimo celovit sistem, nad katerim imamo popoln

nadzor – nadzor nad samimi informacijami in nad tokom informacij. Zagotovljeno imamo

minimalno redundanco informacij, ki jih je zaradi strukture moţno tudi semantično označiti in

jih povezovati. Optimiziran je tudi dostavni sistem, ker informacije razpošilja elastičen oblak,

ki se lahko prilagaja zahtevam.

Sistemu je moţno dodati poljuben sistem plačevanja – glede na tip uporabnika, na število

informacij, na oceno ali pomembnost le-teh, na kategorijo, na lokacijo, na tip ali količino

oglaševanja ipd.

6.2.2 Opis delovanja sistema SkyInfo

Uporabnika zanimajo informacije o vremenu, prometu, zabavah in kulturnih dogodkih. Ko se

uporabnik registrira, si izbere te štiri kategorije in si lahko nastavi radije, ki omejujejo

območje relevantnih informacij. Recimo, da uporabnik ţeli prejemati prometne informacije,

ki so manj kot 10 km oddaljene od njegove trenutne lokacije. Radij za vremenske informacije

nastavi na 15 km, za informacije o zabavah na 3 km, za informacije o kulturnih dogodkih pa

pusti privzeto nastavitev, ki je 10 km. Uporabnik se sprehaja in prejema aţurne informacije na

mobilni telefon. Če je priča prometni nesreči, lahko pošlje sporočilo o dogodku v oblak.

Uporabnik izbere kategorijo promet, napiše sporočilo (npr. »manjša nesreča«) in na

zemljevidu izbere lokacijo. Zemljevid se dinamično generira glede na lokacijo uporabnika. Za

to uporabimo Google Maps, ki deluje tudi brez GPS-ja in določi lokacijo uporabnika na 2 km

natančno s pomočjo triangulacije oddajnikov ponudnika mobilne telefonije. Če pa ima

uporabnikov mobilni telefon GPS, se točna lokacija sama pripne sporočilu, kar pomeni, da

izbiranje lokacije ni potrebno. Ko SkyInfo prejme sporočilo, najprej preveri, ali v sistemu ta

informacija ţe obstaja. Preverijo se lokacija, čas, kategorija in sporočilo. Če sistem ugotovi,

da te informacije ţe vsebuje, se poveča faktor zaupanja informacije, oz. se sporočilo

obravnava kot pritrdilna povratna informacija. Če je informacija nova, jo SkyInfo razpošlje

vsem uporabnikom, katerih nastavitve to dopuščajo. Uporabniki, ki so prijavljeni na prometno


kategorijo in so dovolj blizu, prejmejo informacijo o nesreči (čas, lokacijo in sporočilo).

Odzovejo se lahko na naslednje tri načine:

Informacijo lahko potrdijo – v oblak se pošlje povratna informacija, ki zviša faktor

zaupanja.

Informacijo lahko ignorirajo – povratna informacija se ne pošilja.

Informacijo lahko ovrţejo – v oblak se pošlje povratna informacij, ki zniţa faktor

zaupanja.

Na takšen način se nepravilne informacije samodejno izključijo. Faktor zaupanja informacije

se časovno zmanjšuje, saj se aţurnost informacije sčasoma niţa. Za različne kategorije se

lahko definirajo različne časovne funkcije upadanja faktorja zaupanja.

6.3 SkyInfo arhitektura

Zaradi čim večje fleksibilnosti smo se odločili za 5 slojno arhitekturo, ki ima strogo ločene

nivoje. Konceptna arhitektura je prikazana na sliki 6.2. Najniţje imamo podatkovni nivo, ki

vsebuje podatkovno bazo in podatkovno skladišče. V podatkovni bazi hranimo vse podatke o

uporabnikih in sporočila, ki so stara največ 1 mesec. Vsa ostala sporočila hranimo v

podatkovnem skladišču (OLAP), ki je primerjnejše za analize, statistiko in poslovno

inteligenco. Na drugem nivoju imamo objektni model, ki hkrati predstavlja nivo dostopa do

podatkov. Vsebuje poslovne objekte, ki jih bodo uporabljale storitve in objekte DAO (angl.

Data Access Object), ki s pomočjo povezovalnika prenašajo podatke v podatkovno bazo in iz

nje. Nivo poslovne logike definira storitve, ki realizirajo funkcionalnosti. Izvajanje

kakršnihkoli operacij nad podatki se dogaja izključno na tem nivoju. Četrti nivo je varnostni

nivo, ki skrbi za varno komunikacijo med prezentacijskim nivojem (vsebuje uporabniške

vmesnike) in poslovno logiko. Za vsak dostop do storitev sta potrebni avtentikacija in

avtorizacija.


Slika 6.2: 5-slojna arhitektura SkyInfo

6.3.1 Podatkovni model

Z razvojem bomo začeli na nivoju podatkov, kot to predlaga metodologija, opisana v četrtem

poglavju. Iz zahtev smo razvili entitetno-relacijski model podatkovne baze, ki vsebuje 13

entitet, ki so s atributi opisane v tabeli 6.1.

Spletne storitve

Mobilna aplikacija

Google Maps

Silverlight Bing Maps

Spletna aplikacija

Prejemanje povratne

informacije

Prejemanje sporočila

Pošiljanje sporočil

Upravljanje sistema

Upravljanje uporabnikov

Pridobivanje ustreznih

prejemnikov

Procesiranje sporočila

Procesiranje lokacije

Upravljanje kategorij

Upravljanje profila

Prirejanje pravil

Ocenjevanje informacije

Plačilni sistem

Upravljanje podatkovnega

skladišča

Upravljanje pravil

Podatkovni nivo

Objektni model - nivo dostopa do podatkov

Nivo poslovne logike

Varnostni nivo

Prezentacijski nivo

PB Podatkovno

skladišče OLAP

Poslovni objekti Objekti DAO Povezovalnik

SSL Avtorizacija Avtentikacija


Tabela 6.1: Seznam podatkovnih entitet s pripadajočimi atributi

Entiteta in njena vloga Atributi z opisi

SkyInfoUser

(uporabnik)

Hrani podatke o uporabnikih.

id – identifikator

idLanguage –identifikator jezika

idUserRole – identifikator vloge uproabnika

name – ime uporabnika

surname – priimek uporabnika

username – uporabniško ime uporabnika

password – geslo uporabnika

email – elektronska pošta uporabnika

phoneNumber – telefonska številka uporabnika

rating – ocena uporabnika

blocked – identifikator za uporabnika

Category

(kategorija informacij)

Hrani podatke o kategorijah in privzete

vrednosti za pošiljanje (minimalni

faktor zaupanja, čas veljavnosti

informacije in razdaljo).


idParentCategory – identifikator starševske kategorije

name – ime kategorije

description – opis kategorije

defaultTrustTreshold – privzet prag faktorja zaupanja za pošiljanje

defaultValidityTime – privzet čas obravnavanja informacije

defaultDistanceTreshold – privzeta razdalja pošiljanja

Message

(sporočilo)

Hrani podatke o prejetih sporočilih in

trenutni faktor zaupanja.


idUser – identifikator pošiljatelja

idCategory – identifikator kategorije

timestamp – čas pošiljanja sporočila

shortDescription – kratek opis sporočila

longDescription – neobvezen daljši opis sporočila

latitude – zemljepisna širina lokacije sporočila

longitude – zemljepisna dolţina lokacije sporočila

trustFactor – faktor zaupanja (posodablja sistem)

postalCode, city, street, streetNumber in Country - predstavljajo

zemljepisni naslov, ki ga določi sistem

Feedback

(povratna informacija)

Hrani podatke o prejetih povratnih

sporočilih.

idMessage – identifikator sporočila

idUser – identifikator uporabnika

latitude – zemljepisna širina lokacije povratnega sporočila

longitude – zemljepisna dolţina lokacije povratnega sporočila

value – tip povratne informacije (potrditev ali ovrţba)

timestamp – čas pošiljanja povratnega sporočila

Attachment

(priponka)

Hrani prejete priponke.



name – ime priponke

type – tip priponke (slika, video, ipd.)

data – datoteka


NotificationArea

(območje pošiljanja sporočil)

Hrani podatke o uporabniških

nastavitvah, povezanih z lokacijo za

določen tip sporočila in kategorijo.


idUserCategoryMessageType – identifikator kategorije/tipa soročila

area – območja (občina, regija ipd.)

latitude – zemljepisna širina središča območja

longitude – zemljepisna dolţina središča območja

radius – polmer ki definira kroţno območje od lokacije uporabnika

UserRequest

(Zahteve uprabnikov)


nastavitvah za določen tip sporočila in

kategorijo.



latitude – zemljepisna širina trenutne lokacije uporabnika

longitude – zemljepisna dolţina trenutne lokacije uporabnika

timestamp – čas prejetja zahteve

MessagingType

(tipi sporočila)

Hrani podatke o tipih sporočil.


type – tip sporočila (elektronska pošta,SMS, sporočilo za mobilno aplikacijo)

description – opis tipa sporočila

UserCategoryMessagingType

(povezuje uporabnika kategorijo in

tip sporočila)


nastavitvah (pragovi, čas, število

sporočil) za določen tip sporočila in

kategorijo.


idMessageType – identifikator tipa sporočila

idUserCategory – identifikator uporabniku prirejene kategorije

trustTreshold – definiran prag (faktor zaupanja) pošiljanja*

validityTime – definiran čas obravnavanja informacije*

distanceTreshold – definirana razdalja pošiljanja*

maxMessagesPerDay – maksimalno število prejetih sporočil*

*glede na tip sporočila in kategorijo

UserCategory

(povezuje uporabnika in kategorijo)

Hrani podatke o izbranih kategorijah

uporabnika.


idUser- identifikator uporabnika

idCategory – identifikator kategorije

MessageHistory

(zgodovina sporočil)

Hrani podatke o sporočilih, ki jih

SkyInfo pošlje uporabnikom.



idMessageType – identifikator tipa sporočila

timestamp – čas pošiljanja

UserRole

(vloga uporabnikov)

Vsebuje uporabniške vloge.


role – vloga (administrator, navadni uporabnik ipd.)

UserLanguage

(jeziki)

Vsebuje podprte jezike.


country – drţava

language – jezik

Model hrani vse kategorije, uporabnike, njihove nastavitve in vse prejete informacije. Podpira

tudi N-nivojsko hierarhijo kategorij, kar pomeni, da lahko definiramo glavne kategorije in

poljubno število podkategorij, ki jih poveţemo s starševskimi nadkategorijami z

identifikatorejm idParentCategory. Tako lahko realiziramo drevo kategorij. Model omogoča


nastavitve tudi glede na tip sporočanja. Uporabnik si lahko za vsako kategorijo nastavi več

tipov sporočanja (SMS, MMS, elektronska pošta, sporočilo za mobilno apliakcijo) in za vsak

tip definira drugačno politiko sprejemanja (razdalja, čas, faktor zaupanja).

Sistem obveščanja deluje po modelu »na zahtevo«. Uporabniki niso ves čas povezani z

oblakom, ampak se poveţejo, ko hočejo poslati ali prejeti nova sporočila. Za beleţenje

sporočil, ki jih je SkyInfo uporabniku ţe poslal, skrbi entiteta MessageHistory, kjer se

zabeleţi, katero sporočilo in kakšnega tipa je bilo kdaj poslano uporabniku. Na sliki 6.3 je

prikazan logični ERD model. Ker bo celotni sistem razvit na platformi IBM, smo se odločili,

da bomo za fizični nivo podatkov uporabili podatkovno bazo DB2. Za modeliranje entitetno-

relacijskega diagrama smo uporabili Visual Paradigm DB Visual Architect, ki omogoča

preslikavo logičnega modela v fizične entitete oz. v fizično shemo na instanci streţnika IBM

DB2. Za upravljanje s podatkovno bazo uporabljamo IBM Data Studio 2.2.0.1.

Slika 6.3: Model ERD podatkovne baze SkyInfo


6.3.2 Model storitev

Logični model nam poleg specifikacij funkcionalnosti predstavlja vhod v proces identifikacije

storitev. Čeprav nam najšibkejšo sklopljenost prinaša model storitev z eno ali največ dvema

operacijama, smo se odločili za manjše število storitev, ki so semantično uniformne. Glavna

razloga za takšen model storitev sta dobro poznavanje mej problemske domene in rezultat

preučevanja moţnosti za razširitev sistema z dodatnimi funkcionalnostim. Model je razširljiv

in razgradljiv, kar zagotavlja agilnost in fleksibilnost. Definirali smo osem storitev, ki

zadostujejo vsem funkcionalnim in nefunkcionalnim zahtevam. Komponentni diagram

storitev je prikazan na zgornjem delu slike 6.4. Storitve so na kratko opisane v naslednjih

razdelkih. Iz komponentnega diagrama smo razvili tudi SCA model v orodju IBM WebSphere

Integradtion Developer 7.0, ki je prikazan na spodnjem delu slike 6.4.

Slika 6.4: Komponentni diagram in SCA model storitev SkyInfo


6.3.2.1 DatabaseService

Storitev DatabaseService skrbi za tok podatkov med podatkovno bazo in ostalimi storitvami.

Odgovorna je za vse operacije, ki potekajo nad podatkovno bazo. Sestavlja vse potrebne

poslovne objekte, ki jih druge storitve potrebujejo. Nivo dostopa do podatkov bi lahko

realizirali na dva načina. Prvi način predstavljajo entitetne storitve (ena entiteta – ena

storitev), ki bi implementirale vse potrebne operacije. Drugi način pa so POJO ali Java DAO

razredi, ki neposredno komunicirajo s podatkovno bazo. Odločili smo se za drugo moţnost,

ker s privatnimi entitetnimi storitvami ne bi pridobili veliko, saj DatabaseService ţe deluje kot

fasada. Vaţno je, da imamo vso logiko, ki je povezana z dostopom do podatkov na enem

mestu, in da so privatne metode enkapsulirane (skrite za fasado), kar onemogoča kakršnekoli

podatkovno povezane posege mimo DatabaseServicea.

6.3.2.2 SkyInfoService

SkyInfoService je glavna storitev, ki je izpostavljena navzven in je na prvem nivoju. Njena

glavna vloga je koreografija oz. delegiranje operacij ustreznim storitvam, ki operacije

dejansko izvedejo. Deluje kot dvosmerni namestnik, saj skrbi za vso komunikacijo med

uporabniki in sistemom. Od uporabnikov sprejema informacije in jih posreduje v sistem,

hkrati pa pošilja informacije iz sistema nazaj k uporabnikom.

6.3.2.3 LoginService

LoginService je storitev na drugem nivoju, ki skrbi za nadzorovan dostop do ostalih storitev.

Odgovorna je za prijavo oz. avtentikacijo in registracijo uporabnikov. Operacija, ki avtenticira

uporabnika, je prva operacija, ki jo proţi SkyInfoService. Dokler se uporabnik uspešno ne

avtenticira, ga sistem ignorira. Registracija je mogoča samo s spletno aplikacijo.


6.3.2.4 ProcessorService

ProcessorService je, tako kot LoginService, storitev na drugem nivoju. Sprejme vsa sporočila,

ki pridejo v sistem skozi SkyInfoService. Njena glavna naloga je procesiranje vseh sporočil –

sporočil z novimi informacijami in sporočil s povratnimi informacijami. Procesiranje

sporočila zajema analizo sporočila (AnalyzerService), izračun faktorja zaupanja

(TrustService) in delegiranje sporočila storitvi DatabaseService, ki jih shrani in posodablja

njihova stanja.

6.3.2.5 AnalyzerService in TrustService

AnalyzerService je tretjenivojska storitev, ki jo proţi ProcessorService. Vsako sprejeto

sporočilo se vsaj delno validira. Vsebino tekstovnega sporočila se vedno poiskusi

deterministično ovrednotiti. Storitev je odgovorna tudi za iskanje duplikatov oz. za

razpoznavanje informacij, ki niso nove. TrustService je tudi tretjenivojska storitev, ki se proţi

pri procesiranju vsakega sprejetega sporočila. Storitev je odgovorna za računanje faktorja

zaupanja, ki predstavlja pomembnost in vrednost informacije. Ob vsaki spremembi (novo

sporočilo, čas) faktor zaupanja posodobi.

6.3.2.6 SMSService in RuleApplierService

Storitev SMSService je odgovorna za pošiljanje SMS-sporočil vsem uporabnikom, ki imajo

izbran takšen način obveščanja. Za pošiljanje SMS sporočil bomo uporabili zunanjo storitev.

RuleApplierService je drugonivojska storitev, ki je odgovorna za izbiro pravilne podmnoţice

informacij, ki bodo posredovane uporabniku. Upoštevajo se vse uporabnikove nastavitve in

njegova trenutna lokacija. Proţi jo SkyInfoService, ko uporabnik zahteva nove informacije.

6.3.3 Preslikava podatkovnega modela v poslovni objektni model

Ko imamo identificirane storitve in definirano njihovo vlogo, potrebujemo podatkovne

strukture, s katerimi si storitve lahko prenašajo podatke. Kot smo ţe omenili, so podatkovne

strukture, ki odraţajo poslovne podatke, poslovni objekti. Dober model poslovnih objektov je


za kvalitetno implementacijo zelo vaţen. Med načrtovanjem modela smo se odločili, da se

bomo drţali dobrih praks in bomo model razdelili na dva dela.

Prvi del vsebuje osnovne poslovne objekte, ki predstavljajo preslikavo logičnega

podatkovnega modela v objektni model. Drugi del pa vsebuje vse poslovne objekte, ki se

bodo izmenjevali med storitvami, zato jim pravimo »object envelopes«. Vrednost takšnega

modela se pokaţe, ko ţelimo prenesti kakšno dodatno informacijo, oziroma ko ţelimo v

zahtevo vključiti še kakšen dodaten objekt. Če bi prenašali navadne poslovne objekte, bi

morali spremeniti vmesnik operacije, kar pomeni spremembe na vseh storitvah, ki

implementirajo ta vmesnik. Če prenašamo »envelope« objekte, lahko vanj vstavimo dodaten

objekt in vmesnik ostane enak. Če dodatnega objekta ne potrebujemo, ga preprosto

ignoriramo. V tabeli 6.2 je seznam vseh poslovnih objektov.

Tabela 6.2: Seznam poslovnih objektov

Poslovni objekti SkyInfo/Objects Poslovni objekti SkyInfo/Envelopes

Object Envelope

Attachment ArrayOfCategoriesEnvelope

Authentication ArrayOfMessagesEnvelope

Category AuthenticationEnvelope

CategoryKeywords BooleanEnvelope

FaultMessage CategoriesSubscriptionEnvelope

Feedback CategoryEnvelope

Language CategoryKeywordsEnvelope

Message FaultMessageEnvelope

MessageRequest FeedbackEnvelope

MessagingType InitializationDataEnvelope

NotificationArea InitializationRequestEnvelope

User MessageEnvelope

ArrayOfCategory MessagesRequestEnvelope

ArrayOfMessage MessageTrustEnvelope

SendFeedbackEnvelope

SendMessageEnvelope

UserEnvelope

UserUpdateEnvelope

Poslovne objekte smo modelirali v IBM WebSphere Integration Developer 7.0.


6.3.4 Definiranje vmesnikov in operacij

Ko imamo definirane vse poslovne objekte, ki jih potrebujemo, lahko oblikujemo vmesnike

storitev. Vsaka storitev bo implementirala en vmesnik. Ker bomo implementirali samo

storitev TrustService, bomo vmesnik TrustService podrobno opisali, ostale vmesnike in

njihove operacije pa samo omenili. Imena vmesnikov so identična imenom ţe definiranih

storitev.

Vmesnik DatabaseService vsebuje operacije CRUD23

in vse drugeoperacije, ki jih potrebujejo

ostale storitve (authenticateUser, checkDuplicateMessage, ipd.). Vmesnik SkyInfoService

vsebuje deset operacij, med katerimi so najpomembnejše:

getInitializationData – vrne vse podatke, ki jih potrebuje uporabniški vmesnik,

sendMessage – proţi uporabnik, ko pošlje sporočilo,

sendFeedback – proţi uporabnik, ko pošlje povratno informacijo, in

getCurrentEvents – sistem uporabniku vrne aţurne informacije glede na njegov profil.

Vmesnik LoginService vsebuje dve operaciji: registerNewUser, ki registrira novega

uporabnika, in authenticateUser, ki avtenticira uporabnika. Vmesnik ProcessorService prav

tako vsebuje dve operaciji. Operacija processMessage sprejme sporočilo in ga prične

procesirati, processFeedback pa sprejme povratno informacijo in delegira računanje novega

faktorja zaupanja storitvi TrustService. Vmesnik AnalyzerService vsebuje operacijo

validateMessage, ki preveri vsebino sporočila, in operacijo checkDuplicateMessage, ki

preveri, ali prispelo sporočilo vsebuje nove informacije. Vmesnik SMSService vsebuje

operacijo sendShortMessage, ki za pošiljanje SMS-sporočila pokliče zunanjo storitev.

Vmesnik RuleApplierService vsebuje samo eno operacijo. GetRelevantInformation iz

mnoţice vseh aktualnih informacij generira podmnoţico informacij, ki ustrezajo vsem

uporabnikovim pravilom. Vse operacije ob morebitni napaki vrnejo objekt tipa

FaultMessageEnvelope, ki vsebuje vir in opis napake.

23

CRUD-operacije so osnovne operacije za vstavljanje, branje, posodabljanje in brisanje.


6.3.5 Vmesnik TrustService

Vmesnik TrustService, ki ga bomo kasneje tudi implementirali, vsebuje dve operaciji:

calculcateTrust in updateTrust. Definicijo vmesnika TrustService lahko vidimo na sliki 6.5.

Slika 6.5: Definicija vmesnika TrustService

6.3.5.1 Operacija calculateTrust

Operacija calcualteTrust izračuna faktor zaupanja oz. FT novo prejete informacije. Faktor se

izračuna glede na kredibilnost avtorja (številski atribut »rating«). Kot parameter prejme

poslovni objekt tipa MessageEnvelope, ki je prikazan na sliki 6.6. Objekt vsebuje sporočilo in

avtentikacijske podatke uporabnika.

Slika 6.6: Definicija poslovnega objekta MessageEnvelope


Operacija iz baze pridobi podatke o faktorju kredibilnosti avtorja sporočila. Faktor

kredibilnosti je celo število na intervalu od 0 do 100. Začetni faktor zaupanja (FT) izračunamo

tako, da avtorjevo kredibilnost delimo z 10. Izračunani FT vrnemo v poslovnem objektu

MessageTrustEnvelope, ki vsebuje realnoštevilski atribut messageTrust.

6.3.5.2 Operacija updateTrust

Operacija updateTrust posodobi FT vsakič, ko v sistem pride nova povratna informacija. Nova

povratna informacija je lahko pozitivna ali negativna. Pozitivna povratna informacija pomeni

pozitiven odziv oz. potrditev informacije, kar FT zviša. Negativna povratna informacija pa

pomeni, da informacija ni resnična, kar FT zniţa. Ne smemo pozabiti, da na niţanje FT vpliva

tudi čas. Pri implementaciji bomo vključili dve funkciji, ki opisujeta obnašanje FT v

odvisnosti od časa:

Gaussova funkcija: 𝑓(𝑥) = 10𝑒−𝑥2

25 ; funkcija je prikazana na levi strani slike 6.7.

linearna funkcija 𝑓 𝑥 = −𝑥 + 10 ; funkcija je prikazana na desni strani slike 6.7.

Ordinatna os [0 ≤ 𝑦 ≤ 10] predstavlja faktor zaupanja FT, abscisna os [0 ≤ 𝑥 ≤ 10] pa čas.

Časovna enota je relativno določena z lestvico od 0 do 10. Za grafični prikaz smo uporabili

WolframAlpha24

.

Slika 6.7: Funkciji FT v odvisnosti od časa

24

http://www.wolframalpha.com/ primer za prvo Gaussovo funkcijo: plot [10e^-(x/5)^2, {x, 0, 10}, {y, 0, 10}]

http://www.wolframalpha.com/


Za računanje nove vrednost FT v odvisnosti od povratne informacije (pozitivne ali negativne),

bomo uporabili naslednji dve funkciji:

Gaussova funkcija: 𝑓(𝑥) = 10𝑒− x−100

42 2

; funkcija je prikazana na levi strani slike 6.8.

logaritemska funkcija 𝑓 𝑥 = 2ln(𝑥) ; funkcija je prikazana na desni strani slike 6.8.

Ordinatna os [0 ≤ 𝑦 ≤ 10] predstavlja faktor zaupanja FT, abscisna os [0 ≤ 𝑥 ≤ 100] pa

absolutno vrednost razlike med številom pozitivnih in negativnih povratnih informacij. Če v

sistem pride povratna informacija, ki je pozitivna, se na grafu pomaknemo desno, sicer pa

levo.

Slika 6.8: Funkciji FT v odvisnosti od povratne informacije

Uporaba različnih funkcij nam omogoča različno obravnavanje oz. vrednotenje FT v

odvisnosti od časa in povratnih informacij.

Ker smo se v načrtovalni fazi zavedali, da bomo potrebovali tudi inverzne funkcije, smo jih

definirali pred implementacijo. Inverzne funkcije potrebujemo za izračun abscisnih vrednosti

(neodvisnih spremenljivk), ki definirajo absolutno vrednost FT. Ta je pri vseh funkcijah

enaka, relativna vrednost FT, pa je odvisna od lastnosti funkcije. Tabela 6.3 vsebuje vse štiri

uporabljene funkcije in njim pripadajoče inverze. Prvi dve funkciji (Gaussova in linearna)

opisujeta obnašanje FT v odvisnosti od časa. Drugi dve funkciji (Gaussova in logaritemska) pa

odraţata vpliv povratne informacije.


Tabela 6.3: Seznam poslovni objekti

Funkcija Inverzna funkcija

𝑦 = 10𝑒−𝑥2

25 𝑥 = 5 − ln y

10

𝑦 = −𝑥 + 10 𝑥 = −𝑦 + 10

𝑦 = 10𝑒− x−10042

2

𝑥 = 100− 42 − ln y

10

𝑦 = 2ln(𝑥) 𝑥 = 𝑒y2

6.4 Implementacija TrustService

Pred implementacijo smo ugotovili, da bi bilo pametno najprej implementirati razred, ki bi

nudil povezavo do podatkovne baze in instanco tovarne poslovnih objektov (angl.

BOFactory). V izvorni kodi 3 je prikazan del implementacije statičnega razreda DbWrapper.

Pri implementaciji metode bofInstance smo uporabili vzorec edinec, kar pomeni, da imamo v

sistemu vedno samo eno instanco tovarne poslovnih objektov, saj jih več ne potrebujemo.

Razred implementira tudi statično metodo getConnection, ki vrača povezavo do podatkovne

baze. Tukaj je prav tako definiran podatkovni vir SkyInfoDS.

Izvorna koda 3: Implementacija razreda DbWrapper

public final class DbWrapper {

private static BOFactory bof = null;

public static BOFactory bofInstance() {

if (bof == null) {

bof = (BOFactory)ServiceManager.INSTANCE.locateService(

"com/ibm/websphere/bo/BOFactory");

}

return bof;

}

public static Connection getConnection()

throws javax.naming.NamingException, SQLException {

javax.naming.InitialContext ctx = new javax.naming.InitialContext();

javax.sql.DataSource ds = (javax.sql.DataSource)ctx.lookup("SkyInfoDS");

return ds.getConnection();

}

…


Razred implementira tudi vse statične metode (getUser, getMessage ipd.), ki kot parameter

prejmejo eno vrstico podatkov (angl. result set) in sestavijo poslovni objekt. Te osnovne

metode so statično implementirane v razredu DbWrapper zaradi mnoţične uporabe

Pred implementacijo storitve TrustService smo implementirali še dva Java razreda, ki jih

uporabljamo za izračun faktorja zaupanja oz FT:

TrustFactorByTimeCalculator.java implementira metodi za izračun FT v odvisnosti od

časa. Implementacija razreda je vključena v prilogi 9.4. Metodi getNextGaussianValue

in getNextLinearValue prejmeta trenutno vrednost FT in faktor premika (v izvorni kodi

stepFactor). Iz trenutne vrednosti FT se z inverzno funkcijo najprej izračuna absolutna

vrednost FT. Rezultatu nato prištejemo obratno vrednost faktorja premika

(1/𝑠𝑡𝑒𝑝𝐹𝑎𝑐𝑡𝑜𝑟; 0 < 𝑠𝑡𝑒𝑝𝐹𝑎𝑐𝑡𝑜𝑟 ≤ 20). Ko se po abscisi premaknemo naprej

(desno), ponovno izračunamo relativni FT in ga vrnemo. Metodi se med seboj

razlikujeta le po uporabljenih funkcijah.

TrustFactorByFeedbackCalculator.java implementira metode za izračun FT, ko sistem

prejme povratno informacijo. Implementacija razreda je vključena v prilogi 9.5.

Metodi getNextGaussianValue in getNextLogarithmicValue prejmeta trenutno

vrednost FT, faktor premika in logično spremenljivko, ki določa tip povratne

informacije. Iz trenutne vrednosti FT se z inverzno funkcijo najprej izračuna absolutna

vrednost FT. Rezultatu nato prištejemo, oz. odštejemo obratno vrednost faktorja

premika. Ko se po abscisi premaknemo naprej (desno) ali nazaj (levo), ponovno

izračunamo relativni FT in ga vrnemo. Smer premika je odvisna od tipa povratne

informacije.

Ko smo uspešno implementirali in testirali vse tri podporne razrede, smo se lotili

implementacije storitve TrustService. Izvorni kodi implementacije ţe opisanih operacij

calcualteTrust in updateTrust sta na voljo v prilogah 9.6 in 9.7. Implementirali smo tudi

kratko simulacijo, ki simulira pošiljanje povratne informacije in neprestano spreminjanje FT.

Storitev SkyInfoService iz podatkovne baze prebere tri sporočila z različnimi kategorijami in

za njih generira dvajset povratnih sporočil ter jih pošlje storitvi ProcessorService. Ta

preusmeri sporočila v TrustService, kjer se izvede metoda updateTrust. Rezultati simulacije

so na voljo v prilogi 9.8.


6.5 Povzetek razvoja arhitekture in delne implementacije aplikacije SkyInfo

S praktičnim primerom smo prikazali najboljše prakse razvoja oblačnih aplikacij, saj smo

upoštevali metodologijo, ki vpeljuje celovit pristop k načrtovanju in razvoju. Iz ideje in zahtev

smo najprej definirali podatkovni model, ki smo ga uporabili pri identifikaciji in razvoju

poslovnih objektov ter vmesnikov storitev. V zadnji fazi razvoja arhitekture smo izdelali

model storitev, ki predstavlja arhitekturno zasnovo za celoten projekt. Na primeru storitve

TrustService smo z orodjem IBM WebSphere Integration Developer 7.0 prikazali

implementacijo komponente SCA.


7 SKLEP

Računalništvo v oblaku, ki je zaznamovalo konec tega desetletja, se razvija izredno hitro.

Gartner25

pravi, da bo na informacijsko druţbo vplivalo tako, kot je še pred kratkim

elektronsko poslovanje. S trditvijo se strinjam, saj koncept oblaka ponuja velike prednosti.

Moţnost najema infrastrukture za izvajanje lastnih aplikacij minimizira stroške, hkrati pa

zagotavlja veliko računsko moč in varnost ter integriteto podatkov. Optimizacija učinkovitosti

virtualnih streţnikov, ki podpirajo dinamično skalabilnost in elastičnost ter omogočajo

integracijo poslovnih rešitev na najvišjem nivoju, je pomemben korak naprej. Po drugi strani

pa se je potrebno zavedati, da model oblaka še ni dokončno razvit. Teţave in problemi, ki

obstajajo, se sicer pospešeno rešujejo, a natančne meje, ki bi zagotavljala popolno delovanje,

nihče ne pozna.

Če se kot razvijalci inovativnih in sodobnih informacijskih rešitev vprašamo, kako razvijati

aplikacije tako, da bodo skalabilne, varne, integrabilne in robustne, je odgovor jasen. Model

SOA podpira in zagotavlja vse lastnosti, ki jih aplikacija mora imeti, da lahko učinkovito

uporablja oblačno infrastrukturo. SOA nudi celovit pogled na procese poslovanja, moţnost

upravljanja, vodenja in optimizacijo poslovnih procesov ter zagotavlja integrabilnost. Pri

razvoju aplikacij za oblačno računalništvo se moramo zavedati, da običajno nimamo

popolnega dostopa do infrastrukture in da je koncept varnosti izrednega pomena, saj so

podatki in aplikacije nekje v oblaku in ne pri nas. Na podatkovnem nivoju moramo

upoštevati, da je lokalnost podatkov pomemben faktor za učinkovito procesiranje in da večina

podatkovnih baz še ne podpira infrastrukture virtualnih oblakov.

Ob pisanju naloge sem spoznal vse večje ponudnike oblačnih storitev. Izpostavil bi Amazon

in IBM, ki se mi zdita najnaprednejša. Amazon ponuja velik spekter najrazličnejših PaaS

25

Gartner, Gartner Says Cloud Computing Will Be As Influential As E-business,

http://www.gartner.com/it/page.jsp?id=707508, obiskano 22. februarja 2010

http://www.gartner.com/it/page.jsp?id=707508


storitev, ki jih danes uporablja ţe veliko podjetij. Za IBM pa menim, da ponuja najboljšo

platformo za razvoj, namestitev in upravljanje oblačnih informacijskih rešitev. IBM

WebSphere CloudBurst Appliance prikrije kompleksno infrastrukturo in nam omogoča

enoten pogled na računalniške vire. Namestitev in upravljanje virtualnih privatnih oblakov

postane enostavno, kar bistveno izboljša učinkovitost. IBM WebSphere Integration Developer

je zelo dobro orodje za razvoj SOA oblačnih aplikacij, ki ga veliko razvijalcev ţe uporablja za

razvoj običajnih SOA aplikacij. To pomeni hiter premik iz navadne SOA platforme, v

virtualno infrastrukturo oblaka.

Metodologija razvoja, ki je opisana v četrtem poglavju, zagotavlja kvaliteten razvoj SOA

aplikacij, kar je pomembno, ker je razvoj zahtevnih poslovnih rešitev dolgotrajen in drag.

Razvojni cikel, ki ga definira ta metodologija, se mi zdi dober in zanesljiv, ker razvijalce ves

čas usmerja v pravilno smer in minimizira moţnosti večjih arhitekturnih napak. Pri razvoju

praktičnega primera sem se večinoma upošteval metodologijo in dobre prakse. Z rezultatom

sem zadovoljen, saj je arhitektura sistema SkyInfo skalabilna, robustna in podpira vse

funkcionalne zahteve, hkrati pa zagotavlja podatkovno integriteto in visok nivo varnosti, ki je

pomemben del vseh aplikacij, ki se izvajajo v oblaku. Celoten razvoj sistema SkyInfo je

potekal brez večjih teţav.

Kaj nas čaka v bliţji prihodnosti? Gartner26

je računalništvo v oblaku umestil na prvo mesto

lestvice najpomembnejših tehnologij v letu 2010. Ta napoved in dejstvo, da se investira vedno

več denarja v razvoj tehnologij oblačnega računalništva, kaţe na hiter razvoj vseh vrst

oblačnih storitev. Podjetja, ki bodo uporabljala virtualne oblake, bodo imela prednost

agilnega, fleksibilnega in hitrega prilagajanja zahtevam na trgu. Menim, da bo to eden izmed

glavnih razlogov za premik iz statičnih informacijskih sistemov v sodobne in prilagodljive

informacijske rešitve, ki bodo dostopne vedno in povsod.

26

Gartner, Gartner: Cloud computing, analytics top 2010 strategic tech list,

http://blogs.zdnet.com/BTL/?p=2619, obiskano 21. februarja 2010

http://blogs.zdnet.com/BTL/?p=2619


8 VIRI

1. Miller, Marcus. Cloud Computing, Web-Based Applications That Change the Way You Work and

Collaborate Online. Indiana : QUE, 2008.

2. Velte, Anthony T., Velte, Toby J. in Elsenpeter, Robert. Cloud Computing: A Practical Approach. s.l. : Mc

Graw Hill, 2010.

3. Reese, George. Cloud Application Architectures. ZDA : O'Reilly, 2009.

4. Wallis, Paul. A Brief History of Cloud Computing: Is the Cloud There Yet? | Cloud Computing Journal.

Cloud Computing Journal. [Elektronski] 22. avgust 2008. [Navedeno: 7. februar 2010.]

http://cloudcomputing.sys-con.com/node/581838.

5. Platform Computing Corporation. Enterprise Cloud Computing: Transforming IT. 2009.

6. Lakshmana, G. Infosys - White Papers | Cloud Computing. Infosys. [Elektronski] April 2009. [Navedeno: 8.

februar 2010.] http://www.infosys.com/cloud-computing/white-papers/Documents/relevance-enterprise.pdf.

7. Rittinghouse, John W. in Ransome, James F. Cloud Computing Implementation, Management, and

Security. ZDA : CRC Press, 2010.

8. Wikipedia. Cloud Computing. [Elektronski] 6. februar 2010. [Navedeno: 8. februar 2010.]

http://en.wikipedia.org/wiki/Cloud_computing.

9. Hogan, Mike. Cloud Computing & Databases, How databases can meet the demands of cloud computing.

ScaleDB: Cloud Database Virtualization for MySQL using Shared-Disk Clustering. [Elektronski] 14. november

2008. [Navedeno: 9. februar 2010] http://www.mysql-clustering.com/pdfs/CloudComputingDaaS.pdf.

10. Treadway, John. CloudBzz. Databases and Cloud. [Elektronski] 13. julij 2009. [Navedeno: 9. februar

2010.] http://www.cloudbzz.com/cloud-dbms-databases-and-cloud-computing/.

11. Sun. Oracle. Oracle - Featured Articles. [Elektronski] julij 2009. [Navedeno: 9. februar 2010.]

http://www.sun.com/featured-articles/CloudComputing.pdf.

12. Bittman, Thomas. Gartner blogs. Gartner blogs. [Elektronski] Gartner, 8. april 2010. [Navedeno: 10. februar

2010.] http://blogs.gartner.com/thomas_bittman/2009/04/08/the-spectrum-of-private-to-public-cloud-services/.

13. IDC. IDC eXchange. New IDC IT Cloud Services Survey: Top Benefits and Challenges. [Elektronski] 15.

december 2009. [Navedeno: 11. februar 2010.] http://blogs.idc.com/ie/?p=730.

14. Brodkin, Jon. InfoWorld. Gartner: Seven cloud-computing security risks. [Elektronski] 2. julij 2008.

[Navedeno: 11. februrar 2010.] http://www.infoworld.com/d/security-central/gartner-seven-cloud-computing-

security-risks-853?page=0,1.

15. Amazon. Overview of Amazon Web Services. [Elektronski] december 2009. [Navedeno: 12. februar 2010.]

http://awsmedia.s3.amazonaws.com/AWS_Overview_Whitepaper_120809.pdf.


16. Google. Google App Engine. Google App Engine. [Elektronski] Google. [Navedeno: 11. februar 2010.]

http://code.google.com/appengine/.

17. EMC. EMC. EMC. [Elektronski] EMC. [Navedeno: 11. februar 2010.] http://www.emc.com/about/who-we-

are/slovenia.htm.

18. Chappel, David. Windows Azure Platform. Windows Azure Platform. [Elektronski] december 2009.

[Navedeno: 11. februar 2010.]

http://view.atdmt.com/action/mrtyou_FY10AzurewhitepapterIntroWindowsAzurePl_1.

19. Varia, Jinesh. Amazon Web Services. [Elektronski] 2009. [Navedeno: 12. februar 2010.]

http://jineshvaria.s3.amazonaws.com/public/cloudarchitectures-varia.pdf.

20. Juric, Matjaž B., in drugi. SOA Approach to Integration, XML, Web services, ESB, and BPEL in real-

world SOA projects. Birmingham : Packt Publishing, 2007.

21. Bean, James. SOA and Web Services Interface Design, Principles, Techniques and Standards. ZDA :

Elsevier, 2010.

22. Barber, Graham. Open SOA Collaboration. Open SOA Collaboration. [Elektronski] 7. november 2007.

[Navedeno: 16. februar 2010.] http://www.osoa.org/display/Main/Service+Component+Architecture+Home.

23. Beisiegel, Michael, in drugi. Service Component Architecture, Building Systems using a Service Oriented.

[Whitepaper] ZDA : s.n., 2005.

24. IBM. IBM Education Assistant. IBM Education Assistant - WebSphere® Process Server and WebSphere

Integration Developer. [Elektronski] 25. junij 2009. [Navedeno: 16. februar 2010.]

http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/topic/com.ibm.iea.wpi_v6/wpswid/6.2/SCA/WBPMv

62_SCA_Overview.pdf?dmuid=20090611172726403525.

25. Seeley, Rich. Is Microsoft dissing SOA just to push Azure Cloud computing? SearchCloudComputing.com.

[Elektronski] 31. oktober 2008. [Navedeno: 15. februar 2010.]

http://searchcloudcomputing.techtarget.com/news/article/0,289142,sid201_gci1355222,00.html#.

26. Linthicum, David S. Cloud computing and SOA convergence in your enterprise, a step-by-step guide.

USA : Addison-Wesley, 2009.

27. IBM. Rapid WebSphere Application Server Provisioning with WebSphere. ZDA : IBM, 2009.

28. IBM Education Assistant - WebSphere software. IBM Education Assistant. [Elektronski] IBM. [Navedeno:

19. februar 2010.] http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/index.jsp.


9 PRILOGE

9.1 Seznam slik

Slika 2.1: Primerjava kontekstov »oblaka« ................................................................................ 4

Slika 2.2: Shema modela odjemalec-streţnik ............................................................................. 7

Slika 2.3: Shema modela enakovrednih gostiteljev oz. P2P ...................................................... 7

Slika 2.4: Konvergenca smernic razvoja računalniških arhitektur (5) ....................................... 9

Slika 2.5: Sklad, ki predstavlja računalništvo v oblaku (6) ...................................................... 13

Slika 2.6: Elementi, ki sestavljajo storitev tipa PaaS ............................................................... 15

Slika 2.7: Elementi, ki sestavljajo storitve tipa IaaS ................................................................ 17

Slika 2.8: Delitev podatkovnih baz za uporabo v oblaku (10) ................................................. 21

Slika 2.9: Dva pogleda na tipe oblakov (12) ............................................................................ 23

Slika 2.10: Rezultati ankete o izzivih računalništva v oblaku 2010 (13) ................................. 27

Slika 2.11: Primerjava modelov za varovanje omreţja (3) ...................................................... 30

Slika 3.1: Komponente modela SCA (22) ................................................................................ 39

Slika 3.2: Komponenta SCA (23) ............................................................................................. 40

Slika 3.3: Storitveni modul (24) ............................................................................................... 41

Slika 3.4: Razvojni cikel aplikacij SOA (20) ........................................................................... 43

Slika 4.1: Koraki metodologije razvoja »oblačnih« aplikacij (26) ........................................... 44

Slika 4.2: Razvoj informacijskega modela (26) ....................................................................... 45

Slika 4.3: Nivo podatkov in nivo storitev (26) ......................................................................... 47

Slika 4.4: Razvoj modela storitev (26) ..................................................................................... 48

Slika 4.5: Postopni premik storitev v računalniški oblak ......................................................... 49

Slika 4.6: Razvoj procesnega modela (26) ............................................................................... 51

Slika 4.7: Generičen model spletnih aplikacij (3) .................................................................... 54


Slika 5.1: Struktura IBM WebSphere CloudBurst Appliance .................................................. 59

Slika 5.2: Struktura IBM WebSphere Application Server Hypervisor Edition (28) ................ 61

Slika 5.3: Programski model WebSphere Process Server ........................................................ 62

Slika 5.4: Struktura WebSphere ESB ....................................................................................... 63

Slika 6.1: Topologija SkyInfo .................................................................................................. 66

Slika 6.2: 5-slojna arhitektura SkyInfo ..................................................................................... 69

Slika 6.3: Model ERD podatkovne baze SkyInfo .................................................................... 72

Slika 6.4: Komponentni diagram in SCA model storitev SkyInfo ........................................... 73

Slika 6.5: Definicija vmesnika TrustService ............................................................................ 78

Slika 6.6: Definicija poslovnega objekta MessageEnvelope .................................................... 78

Slika 6.7: Funkciji FT v odvisnosti od časa .............................................................................. 79

Slika 6.8: Funkciji FT v odvisnosti od povratne informacije .................................................... 80

9.2 Seznam tabel

Tabela 2.1: Poraba procesne moči pri popolni in delni virtualizaciji (2) ................................. 12

Tabela 2.2: Microsoftova zrelostna klasifikacija SaaS arhitektur (7) ...................................... 14

Tabela 2.3: Prednosti računalništva v oblaku ........................................................................... 24

Tabela 2.4: Slabosti računalništva v oblaku ............................................................................. 25

Tabela 2.5: Lastnosti ponudnikov računalništva v oblaku ....................................................... 35

Tabela 4.1: Atributi imenika storitev ........................................................................................ 50

Tabela 6.1: Seznam podatkovnih entitet s pripadajočimi atributi ............................................ 70

Tabela 6.2: Seznam poslovnih objektov ................................................................................... 76

Tabela 6.3: Seznam poslovni objekti ........................................................................................ 81


9.3 Seznam izvorne kode

Izvorna koda 1: Sinhronizacijska implementacija rezervacije sobe (3) ................................... 55

Izvorna koda 2: Primer posodobitve z uporabo časovnih značk (3) ........................................ 56

Izvorna koda 3: Implementacija razreda DbWrapper............................................................... 81

Izvorna koda 4: Implementacija razreda TrustFactorByTimeCalculator ................................. 91

Izvorna koda 5: Implementacija razreda TrustFactorByFeedbackCalculator .......................... 92

Izvorna koda 6: Implementacija metode calculateTrust ........................................................... 93

Izvorna koda 7: Implementacija metode updateTrust .............................................................. 94

9.4 TrustFactorByTimeCalculator.java

package si.cloud.math;

public class TrustFactorByTimeCalculator {

private final static double e = java.lang.Math.E;

private final static double roundFactor = 100.0;

public static double getNextGaussianValue(double y, double stepFactor)throws Exception

{

// validation of parameters

validateParameters(y, stepFactor);

if(y < 0.1) {

return 0.0;

}

// inverse function 5*sqrt(-ln(y/10))

double sqrtValue = java.lang.Math.log(y/10.0) * (-1);

double x = 5 * java.lang.Math.sqrt(sqrtValue);

// decrease trust factor

double nextValue = x + (1/stepFactor);

// if new value x > 10 trust factor becomes 0

if(nextValue > 10) {

return 0.0;

}

// Gaussian function 10*e^(-(x/5)^2)

double pow = java.lang.Math.pow((nextValue/5), 2) * (-1);

double functionResult = java.lang.Math.pow(e, pow) * 10;

if(functionResult < 0.01) {

return 0.0;

}

// round and return

return java.lang.Math.round(functionResult * roundFactor) / roundFactor;

}

public static double getNextLinearValue(double y, double stepFactor) throws Exception

{



if(y < 0.1) {

return 0.0;

}


// inverse function -y+10

double x = -y+10;



// if new value x > 10 trust factor becomes 0

if(nextValue > 10) {

return 0.0;

}

// Linear function -x + 10

double functionResult = (x*(-1)) +10;


return 0.0;

}

// round and return


}

private static void validateParameters(double y, double stepFactor) throws Exception

{

// max relative shift is 1 ; min relative shift is 1/20

if( stepFactor < 1 || stepFactor > 20) {

throw new Exception("stepFactor ot in specified range (0, 20]!");

}

if(y < 0 || y > 10) {

throw new Exception("Y not in specified range [0, 10]!");

}

}

}

Izvorna koda 4: Implementacija razreda TrustFactorByTimeCalculator

9.5 TrustFactorByFeedbackCalculator.java

package si.cloud.math;

public final class TrustFactorByFeedbackCalculator {

private final static double e = java.lang.Math.E;

private final static double roundFactor = 100.0;

public static double getNextGaussianValue(double y, double stepFactor, boolean isPositive)

throws Exception {



// inverse function 100-42*sqrt(-ln(y/10))

double sqrtValue = java.lang.Math.log(y/10.0) * (-1);

double x = 100 - (42 * java.lang.Math.sqrt(sqrtValue));

// increase trust factor



if(!isPositive) {

nextValue = x - (1/stepFactor);

// if new value x < 1 trust factor becomes 0

if(nextValue < 1) {

return 0.0;

}

}

// Gaussian function 10*e^(-((x-100)/42)^2)

double pow = java.lang.Math.pow(((nextValue-100)/42), 2) * (-1);

double functionResult = java.lang.Math.pow(e, pow) * 10;

// If result < 0.01 trust factor becomes 0


functionResult = 0;

}


// If result < 10 trust factor becomes 10

if(functionResult > 10) {

functionResult = 10;

}

// round and return


}

public static double getNextLogarithmicValue(double y, double stepFactor, boolean isPositive) t

hrows Exception

{



// inverse function e^(y/2)

double pow = y/2.0;

double x = java.lang.Math.pow(e, pow);

// [0, 100]

if(x > 100) {

x = 100;

}




if(!isPositive) {

nextValue = x - (1/stepFactor);

// if new value x < 1 trust factor becomes 0

if(nextValue < 1) {

return 0.0;

}

}

// logarithmic function 2ln(x)

double functionResult = java.lang.Math.log(nextValue) * 2;

// If result > 10 trust factor becomes 10

if(functionResult > 10) {

functionResult = 10;

}

// round and return


}

private static void validateParameters(double y, double stepFactor) throws Exception

{

// max relative shift is 1 ; min relative shift is 1/20

if( stepFactor < 1 || stepFactor > 20) {

throw new Exception("stepFactor ot in specified range (0, 20]!");

}

if(y < 0 || y > 10) {

throw new Exception("Y not in specified range [0, 10]!");

}

}

}

Izvorna koda 5: Implementacija razreda TrustFactorByFeedbackCalculator

9.6 TrustService.calculateTrust

public DataObject calculcateTrust(DataObject message) {

DataObject result = DbWrapper.bofInstance().create(

"http://skyinfo.cloud.si/envelopes/message/",

"MessageTrustEnvelope");

try {

// read ID

int authorID = message.getInt("message/author/id");

DataObject userEnvelope = DbWrapper.bofInstance().create(

"http://skyinfo.cloud.si/envelopes/user/",

"UserEnvelope");


userEnvelope.setInt("user/id", authorID);

// invoke returnAuthorRating

DataObject reply = (DataObject)this.locateService_DatabaseServicePartner().invoke(

"returnAuthorRating", userEnvelope);

double trust = reply.getDouble(0)/10;

// set calculated trust factor

result.setDouble("messageTrust", trust);

System.out.println("MessageTrust:\t" + trust);

}

catch (Exception e) {

if (e.getClass().toString().contains("ServiceBusinessException")) {

throw (com.ibm.websphere.sca.ServiceBusinessException) e;

}

else {

DataObject faultMessage = DbWrapper.bofInstance().create(

"http://skyinfo.cloud.si/envelopes/fault/",

"FaultMessageEnvelope");

DataObject fault = faultMessage.createDataObject("faultMessage");

fault.setString("faultName", e.getMessage());

fault.setString("faultDescription", e.toString());

ServiceBusinessException sbe = new ServiceBusinessException(faultMessage);

throw sbe;

}

}

return result;

}

Izvorna koda 6: Implementacija metode calculateTrust

9.7 TrustService.updateTrust

public DataObject updateTrust(DataObject feedback) {

DataObject result = DbWrapper.bofInstance().create(


"MessageTrustEnvelope");

try {

double newFactor = -1;

// read IDs

int authorID = feedback.getInt("feedback/author/id");

int messageID = feedback.getInt("feedback/message/id");

System.out.println("AuthorID: " + authorID);

System.out.println("MessageID: " + messageID);

boolean isPositive = feedback.getBoolean("feedback/value");

int categoryID = feedback.getInt("feedback/message/category/id");

double factor = feedback.getDouble("feedback/message/trustFactor");

System.out.println("-- OLD FACTOR: " + factor);

// static category: traffic category - Gaussian function

if(categoryID == 1) {


if(isPositive) {

System.out.println("Gaussian function - trust factor increase");

newFactor = TrustFactorByFeedbackCalculator.getNextGaussianValue(

factor, 1, true);

}


else {

System.out.println("Gaussian function - trust factor decrease");

newFactor = TrustFactorByFeedbackCalculator.getNextGaussianValue(

factor, 1, false);

}

}


// static category: weather or fun category - logarithmic function

if(categoryID == 10 || categoryID == 12) {


if(isPositive) {

System.out.println("logarithmic function - trust factor increase");

newFactor = TrustFactorByFeedbackCalculator.getNextLogarithmicValue(

factor, 1, true);

}


else {

System.out.println("logarithmic function - trust factor decrease");

newFactor = TrustFactorByFeedbackCalculator.getNextLogarithmicValue(

factor, 1, false);

}

}

System.out.print("-- NEW FACTOR: " + newFactor);

// save new factor

DataObject messageEnvelope = DbWrapper.bofInstance().create(


"MessageEnvelope");

messageEnvelope.setInt("message/id", messageID);

messageEnvelope.setDouble("message/trustFactor", newFactor);

// invoke updateTrustFactor

DataObject reply = (DataObject)this.locateService_DatabaseServicePartner().invoke(

"updateTrustFactor", messageEnvelope);

if(reply.getBoolean(0)) {

System.out.println("Trust factor updated in DB");

}

}

catch (Exception e) {

if (e.getClass().toString().contains("ServiceBusinessException")) {

throw (com.ibm.websphere.sca.ServiceBusinessException) e;

}

else {

DataObject faultMessage = DbWrapper.bofInstance().create(

"http://skyinfo.cloud.si/envelopes/fault/","FaultMessageEnvelope");

DataObject fault = faultMessage.createDataObject("faultMessage");

fault.setString("faultName", e.getMessage());

fault.setString("faultDescription", e.toString());

ServiceBusinessException sbe = new ServiceBusinessException(faultMessage);

throw sbe;

}

}

return result;

}

Izvorna koda 7: Implementacija metode updateTrust

9.8 Rezultati simulacije vpliva povratne informacije

SystemOut ProcessorService: starting processFeedback

SystemOut TrustService: message found Nesrečal![Nesrečna na Titovem mostu!]

SystemOut TrustService: current TrustFactor: 6.0

SystemOut TrustService: Gaussian function - trust factor decrease

SystemOut ProcessorService: new TrustFactor: 5.8

SystemOut ProcessorService: TrustFactor successfully updated in database

SystemOut ProcessorService: processFeedback finisehd


SystemOut TrustService: message found Poledica![Ceste so zasnežene in poledenele!]


SystemOut TrustService: Gaussian function - trust factor increase




















SystemOut TrustService: message found Toča![Točaprihaja iz smeri Ruš!]


SystemOut TrustService: logarithmic function - trust factor increase
























































SystemOut TrustService: logarithmic function - trust factor decrease






















































9.9 Naslov študenta

Ime in priimek: Martin Potočnik

Naslov: Preţihova ulica 9

Pošta: 2000 Maribor

Tel.študenta: +386 40 309 727

E-pošta študenta: [email protected]

9.10 Kratek življenjepis

Rojen: 11. 4. 1985 v Mariboru

Šolanje: 1992 – 2000 Osnovna šola Bojana Ilicha, Maribor

2000 – 2004 Prva gimnazija Maribor

2004 – 2010 Fakulteta za elektrotehniko, računalništvo in informatiko Maribo

mailto:[email protected]

Razvoj informacijskih rešitev v oblaĊni arhitekturi · SOA Storitveno-usmerjena arhitektura...

Documents

Transcript of Razvoj informacijskih rešitev v oblaĊni arhitekturi · SOA Storitveno-usmerjena arhitektura...