RAZVOJ INFORMACIJSKIH REŠITEV V OBLAČNI ARHITEKTURI

Transkripcija

1 Martin Potočnik RAZVOJ INFORMACIJSKIH REŠITEV V OBLAČNI ARHITEKTURI Diplomsko delo Maribor, februar 2010

2 I Diplomsko delo univerzitetnega študijskega programa RAZVOJ INFORMACIJSKIH REŠITEV V OBLAČNI ARHITEKTURI Študent: Študijski program: Smer: Mentor: Lektorica: Martin Potočnik UN ŠP računalništvo in informatika Informatika red. prof. dr. Matjaţ B. Jurič Joţica Lorenci, prof. Maribor, februar 2010

3 II

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

5 IV RAZVOJ INFORMACIJSKIH REŠITEV V OBLAČNI ARHITEKTURI Ključne besede: Računalništvo v oblaku, IBM WebSphere, SOA, SCA, SaaS UDK: :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.

6 V DEVELOPMENT OF IT SOLUTIONS USING CLOUD ARCHITECTURE Key words: Cloud computing, IBM WebSphere, SOA, SCA, SaaS UDK: :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.

7 VI VSEBINA 1 UVOD Pomen informacijskih rešitev in računalništva v oblaku Cilji diplomskega dela Opis poglavij in strukture diplomskega dela Računalništvo v oblaku Definiranje in umestitev računalništva v oblaku Zgodovina in nastanek računalništva v oblaku Oblačna arhitektura Moţni prehodi v oblačno arhitekturo Topologija računalniškega oblaka Tehnologije računalniškega oblaka Storitve in modeli oblačne infrastrukture SaaS - programska oprema kot storitev PaaS platforma kot storitev IaaS Infrastruktura kot storitev CaaS in MaaS Podatkovne shrambe v oblaku Tipi oblakov Javni oblaki Zasebni oblaki Hibridni oblaki Lastnosti računalništva v oblaku Varnost računalništva v oblaku Varnostni izzivi... 26

8 VII Varnostni mehanizmi Primerjava velikih Google EMC Microsoft Amazon Salesforce.com IBM Primerjava Storitveno usmerjena arhitektura Kaj je SOA? Tehnologije SOA Skupno storitveno vodilo Kompozicija poslovnih storitev in BPEL SCA SOA in računalništvo v oblaku Razvoj aplikacij za oblak Nivo podatkov Definiranje problemske domene Definiranje informacijskega modela Nivo storitev Definiranje storitev Pomen šibke sklopljenosti storitev Metastoritve in imenik storitev Nivo procesov Definiranje procesov... 51

9 VIII BPM Nivo vodenja oz. upravljanja Pogled na testiranje Spletne aplikacije v oblaku Problem stanj in zagotavljanje podatkovne integritete Načrtovanje strojne slike Platforma IBM za razvoj oblačnih rešitev IBM WebSphere CloudBurst Appliance IBM WebSphere Application Server Hypervisor Edition IBM WebSphere Process Server IBM WebSphere Enterprise Service Bus Razvoj arhitekture SkyInfo in implementacija storitve TrustService na platformi IBM Predstavitev problema Ideja Dodatne razširitve Opis delovanja sistema SkyInfo SkyInfo arhitektura Podatkovni model Model storitev DatabaseService SkyInfoService LoginService ProcessorService AnalyzerService in TrustService SMSService in RuleApplierService Preslikava podatkovnega modela v poslovni objektni model... 75

10 IX Definiranje vmesnikov in operacij Vmesnik TrustService Operacija calculatetrust Operacija updatetrust Implementacija TrustService Povzetek razvoja arhitekture in delne implementacije aplikacije SkyInfo SKLEP VIRI PRILOGE Seznam slik Seznam tabel Seznam izvorne kode TrustFactorByTimeCalculator.java TrustFactorByFeedbackCalculator.java TrustService.calculateTrust TrustService.updateTrust Rezultati simulacije vpliva povratne informacije Naslov študenta Kratek ţivljenjepis... 96

11 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) K T Faktor zaupanja (angl. trust factor)

12 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 SOA 1 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, P2P 2, 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.

13 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 2 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.

14 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 3 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

15 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 4 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 infrastrukturo 3 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. Povezljivost Zunanji strežniki Medmrežje Računalniški oblak Usmerjevalnik Storitve, podatki, varnost Povezljivost Medmrežje Stikalo Lokalni strežniki Odjemalci Varnost, storitve, aplikacije, podatki in infrastruktura Odjemalci Podatki, varnost 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.

16 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 5 Č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-programirljive 5. 5 Avto-programirljive rutine so rutine, ki se ob napaki znajo same ustrezno reprogramirati.

17 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 6 Našteli smo šest lastnosti, ki jih Google postavlja v ospredje (1), vendar lahko dodamo še nekaj pomembnih lastnosti, ki so opisane v razdelku 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 gospodarsuţ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.

18 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 7 Strežnik (podatki in aplikacije) Zvezdišče Odjemalci (terminali) 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). Enakovredni gostitelji (hkratni odjemalci in strežniki) Slika 2.3: Shema modela enakovrednih gostiteljev oz. P2P

19 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 8 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 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

20 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 9 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.

21 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 10 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 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

22 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 11 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) 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-V 7 in IVT 8. 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

23 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 12 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.

24 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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). SaaS (programska oprema kot storitev) PaaS (platforma kot storitev) IaaS (infrastruktura kot storitev) Slika 2.5: Sklad, ki predstavlja računalništvo v oblaku (6) 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

25 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 14 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 Nivo 1: ad-hoc Nivo 2: konfigurabilnost Nivo 3: večkratno najemanje Nivo 4: skalabilnost Opis 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 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. 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. 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).

26 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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. PaaS Razvoj Načrtovanje Modeliranje Razvoj Testiranje Gostovanje SaaS Virtualna pisarna Storitve za integracijo podatkov Storitve za sodelovanje Storitve za upravljanje stanj Storitve za zagotavljanje varnosti Slika 2.6: Elementi, ki sestavljajo storitev tipa PaaS

27 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 16 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 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.

28 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 17 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 SMB 9 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. IaaS Strojna 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 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.

29 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 18 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 ITIL 11, 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« 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 (Gartner 12 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.

30 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 19 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 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)

31 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 20 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).

32 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 21 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 NAS 13 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

33 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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 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.) 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.

34 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 23 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 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. LASTNIKI DOSTOP DO STORITEV VSI NADZOR / LASTNIŠTVO UPORABNIK PONUDNIKI Slika 2.9: Dva pogleda na tipe oblakov (12)

35 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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 Nižji infrastrukturni stroški Centralizacija Enostavnejše in cenejše vzdrževanje Nižji stroški programske opreme Enostavnejše posodabljanje programske opreme Višja računska moč»neskončne«shranjevalne kapacitete Višja varnost podatkov Opis 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. Centralizirana infrastruktura omogoča učinkovitejše izvajanje aplikacij in zviša nivo varnosti. Za vzdrţevanje programske in strojne opreme ne skrbimo mi, ampak ponudnik, kar še dodatno zniţa stroške. 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. 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. Na voljo imamo veliko strojne opreme, ki jo lahko uporabimo, kadar to ţelimo in nismo omejeni z zmogljivostjo lastne infrastrukture. Oblak nam nudi ogromno prostora za varno shranjevanje podatkov. Omogočena je tudi redundanco velikih količin 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.

36 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 25 Dostopnost Boljša kompatibilnost Lažje sodelovanje Večkratna sočasna uporaba Integriteta podatkov Dinamična skalabilnost Enostaven začetek poslovanja 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. 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). 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.). Oblak zagotavlja sočasno uporabo naše aplikacije in optimizira porabo računalniških virov, ki jih plačujemo. Oblak zagotavlja celovito integriteto vseh podatkov. Temu pravimo tudi»elastičnost«, kar pomeni, da se oblak prilagaja uporabi aplikacije tako, da dinamično dodeljuje računalniške vire. 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 Popolna odvisnost od omrežja Odzivnost aplikacij Omejenost ponujenih SaaS Opis Za dostop do podatkov in uporabo aplikacij moramo biti povezani z oblakom. Če omreţje odpove, smo nemočni. 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). 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.

37 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 26 Varnost je lahko vprašljiva Realnočasovna opravila Implementacija aplikacij 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. 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, 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 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 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.

38 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 27 Rezultati ankete - 3Q 2009 Ocenite izzive računalništva v oblaku med 1 in 5! Varnost Dostopnost Učinkovitost Model plačevanja Pomanjkanje standardov Prenosljivost Težavnost integracije Premajhna presonalizacija 87,5 83,3 82, ,2 79,8 76,8 76 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).

39 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 28 Č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?

40 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 29 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 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-karakteristik 14. 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 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 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.

41 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 30 Trinivojsko domensko varovanje Brezdomensko varovanje oblaka Podatkovni strežniki Uravnavanje prometa Medmrežje Aplikacijski strežniki DMZ Upravljavec virtualnih strojev Skupinska pravila Skupinska pravila Skupinska pravila Strežnik za uravnavanje prometa Aplikacijski strežnik Podatkovni strežnik 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.

42 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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 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 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).

43 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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) SQL Azure Windows Azure Platform AppFabric Aplikacije v oblaku Windows Azure Lokalne aplikacije Windows Ostali OS 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).

44 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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 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

45 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 34 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 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.

46 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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 EMC Google App Engine GMail GoogleDocs Podpora za DB2, Oracle, MSSQL, SAP, Sysbase PaaS App Engine za lastne aplikacije SaaS GMail, GoogleDocs 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 IBM Salesforce CRM Force.com Platform Chatter Smart Business Development/Test Cloud Smarti Analytics Cloud Smartin Business Storage Cloud IaaS CRM, javna uprava, finance PaaS The Service Cloud Apex razvojno okolje IaaS CloudBurst Appliance PaaS IBM Websphere Platform

47 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 36 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.

48 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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 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 ESBjem 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.

49 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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.

50 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 39 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 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. Sestavljanje storitev SCA Implementacija storitev Povezovanje storitev Politika delovanja Slika 3.1: Komponente modela SCA (22)

51 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 40 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. STORITVE KOMPONENTA SCA REFERENCE RAZLIČNE IMPLEMENTACIJE 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 SDO 17 in BO 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.

52 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 41 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. STORITVENI MODUL I IZVOZ SAMOSTOJNA REFERENCA R I STORITVENA KOMPONENTA IMPLEMENTACIJA R R I I STORITVENA KOMPONENTA UVOZ 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).

53 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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. SAP 19, 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.

54 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 43 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. Identifikacija Analiza in optimizacija Modeliranje Nadzor Implementacija Izvajanje Kompozicija Namestitev Slika 3.4: Razvojni cikel aplikacij SOA (20)

55 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 44 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. Definiranje podatkov Definiranje storitev Definiranje procesov Definiranje vodenja oz. upravljanja 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 semantiko 20 in metapodatke, ki obstajajo v naši 20 Semantika v smislu različnih pomenov podatkov v različnih aplikacijah.

56 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 45 domeni, ker to potrebujemo za vzpostavitev dobre arhitekturne osnove, s katero definiramo podatkovni nivo 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) 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 ontologije 21 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. Razumevanje ontologij Razumevanje podatkov Strukturiranje podatkov Izgradnja inf. modela Ontologije Imenik podatkov in metapodatkov Katalog podatkov Informacijski model Slika 4.2: Razvoj informacijskega modela (26) 21 Ontologije v smislu pomenske povezanosti in odvisnosti podatkov

57 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 46 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).

58 APLIKACIJA Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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). NIVO STORITEV NIVO PODATKOV PODATKI Slika 4.3: Nivo podatkov in nivo storitev (26)

59 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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. Razumevanje storitev Povezovanje informacij in storitev Izgradnja modela storitev Informacijski model Katalog podatkov Kandidati storitev Storitve + informacije 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

60 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 49 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. Ponudnik računalniškega oblaka Oblak del storitev Oblak vse storitve Naša infrastruktura (vse storitve) Naša infrastruktura (del storitev) 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 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

61 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 50 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 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 Namen Avtentikacija Odvisnosti Nivo storitve Lastništvo Tehnologija Programski model Atributi zmogljivosti Validacija podatkov Vključene storitve Lokacija vključenih storitev Funkcijske točke Diagrami toka podatkov Strukturni diagrami Definicije vmesnikov Revizije programske kode Načrti testiranj Rezultati testiranj 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.

62 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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 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. Razumevanje procesov Povezovanje storitev in procesov Izgradnja procesnega modela Katalog podatkov Informacijski model Model storitev Kandidati procesov Storitve + procesi Procesni model Slika 4.6: Razvoj procesnega modela (26)

63 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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,

64 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 53 č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.

65 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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-viewcontroller), ki ločuje nivo poslovne (aplikacijske) logike od akcij (vhoda) in od prezentacijskega nivoja. Spletni brskalnik Akcije Uporabniški vmesnik Poslovni objekti Vsebina Podatkovna baza 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.

66 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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. 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); } } 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

67 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 56 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. UPDATE rezervacija SET stranka =?, cas_zadnje_posodobitve =?, uporabnik_zadnje_posodobitve =? WHERE rezervacija_id =? AND cas_zadnje_posodobitve =? AND uporabnik_zadnje_posodobitve =?; 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

68 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 57 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.

69 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 58 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).

70 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 59 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). Katalog Vzorci Virtualni sistemi Infrastruktura in viri Admin Agent Deployment Manager Job Manager Custom Node Custom Node Hypervisors IBM HTTP Server Deployment Manager Custom Node Deployment Manager Custom Node Custom Node IBM HTTP Server Aplication Server Custom Node Custom Node 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

71 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 60 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 VNC 22. 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

72 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 61 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. Profili virtualna slika WAS IBM HTTP strežnik SUSE 10.2 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.

73 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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. Procesi Storitve Podatki BPEL SCA SDO in BO 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 , 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

74 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 63 storitveno vodilo kot hrbtenico, ki povezuje vse pomembne komponente poslovne SOA. EBS skrbi za sporočilno komunikacijo, klice spletnih storitev in obravnava dogodke. Interakcijske storitve (WS Portal Server) Procesne storitve (WS BI Server) Informacijske storitve (WS Information Integrator) ESB *sporočilne vrste MQ, prehodi WS Gateway in posredovalci dogodkov WBI E/M Broker] Partnerske storitve (WS BI Connect) Storitve poslovnih aplikacij (WAS) Storitve za dostop (WBI Adapters, HATS) 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).

75 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 64 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.

76 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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

77 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 66 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. Podatkovni center Informacije s spleta Administrator Spletni strežnik Aplikacijski strežnik Uporabniki SkyInfo Uporabniki Slika 6.1: Topologija SkyInfo 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.

78 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 67 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 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

79 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 68 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.

80 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 69 Prezentacijski nivo Silverlight Bing Maps Spletna aplikacija Spletne storitve Mobilna aplikacija Google Maps Varnostni nivo Avtorizacija SSL Avtentikacija Nivo poslovne logike Upravljanje sistema Upravljanje uporabnikov Prejemanje povratne informacije Prejemanje sporočila Pošiljanje sporočil Upravljanje kategorij Upravljanje profila Procesiranje lokacije Procesiranje sporočila Pridobivanje ustreznih prejemnikov Upravljanje pravil Upravljanje podatkovnega skladišča Plačilni sistem Ocenjevanje informacije Prirejanje pravil Objektni model - nivo dostopa do podatkov Poslovni objekti Objekti DAO Povezovalnik Podatkovni nivo Podatkovno skladišče OLAP PB Slika 6.2: 5-slojna arhitektura SkyInfo 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.

81 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 70 Tabela 6.1: Seznam podatkovnih entitet s pripadajočimi atributi Entiteta in njena vloga SkyInfoUser (uporabnik) Hrani podatke o uporabnikih. Category (kategorija informacij) Hrani podatke o kategorijah in privzete vrednosti za pošiljanje (minimalni faktor zaupanja, čas veljavnosti informacije in razdaljo). Message (sporočilo) Hrani podatke o prejetih sporočilih in trenutni faktor zaupanja. Feedback (povratna informacija) Hrani podatke o prejetih povratnih sporočilih. Attachment (priponka) Hrani prejete priponke. id identifikator idlanguage identifikator jezika Atributi z opisi iduserrole identifikator vloge uproabnika name ime uporabnika surname priimek uporabnika username uporabniško ime uporabnika password geslo uporabnika elektronska pošta uporabnika phonenumber telefonska številka uporabnika rating ocena uporabnika blocked identifikator za uporabnika id identifikator 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 id identifikator 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 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 id identifikator idmessage identifikator sporočila name ime priponke type tip priponke (slika, video, ipd.) data datoteka

82 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 71 NotificationArea (območje pošiljanja sporočil) Hrani podatke o uporabniških nastavitvah, povezanih z lokacijo za določen tip sporočila in kategorijo. UserRequest (Zahteve uprabnikov) Hrani podatke o uporabniških nastavitvah za določen tip sporočila in kategorijo. MessagingType (tipi sporočila) Hrani podatke o tipih sporočil. UserCategoryMessagingType (povezuje uporabnika kategorijo in tip sporočila) Hrani podatke o uporabniških nastavitvah (pragovi, čas, število sporočil) za določen tip sporočila in kategorijo. UserCategory (povezuje uporabnika in kategorijo) Hrani podatke o izbranih kategorijah uporabnika. MessageHistory (zgodovina sporočil) Hrani podatke o sporočilih, ki jih SkyInfo pošlje uporabnikom. UserRole (vloga uporabnikov) Vsebuje uporabniške vloge. UserLanguage (jeziki) Vsebuje podprte jezike. id identifikator 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 id identifikator iduser identifikator uporabnika latitude zemljepisna širina trenutne lokacije uporabnika longitude zemljepisna dolţina trenutne lokacije uporabnika timestamp čas prejetja zahteve id identifikator type tip sporočila (elektronska pošta,sms, sporočilo za mobilno aplikacijo) description opis tipa sporočila id identifikator 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 id identifikator iduser- identifikator uporabnika idcategory identifikator kategorije iduser identifikator uporabnika idmessage identifikator sporočila idmessagetype identifikator tipa sporočila timestamp čas pošiljanja id identifikator role vloga (administrator, navadni uporabnik ipd.) id identifikator 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

83 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 72 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 entitetnorelacijskega 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 Slika 6.3: Model ERD podatkovne baze SkyInfo

84 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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

85 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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 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 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.

86 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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 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 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 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

87 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 76 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 Object Attachment Authentication Category CategoryKeywords FaultMessage Feedback Language Message MessageRequest MessagingType NotificationArea User ArrayOfCategory ArrayOfMessage Poslovni objekti SkyInfo/Envelopes Envelope ArrayOfCategoriesEnvelope ArrayOfMessagesEnvelope AuthenticationEnvelope BooleanEnvelope CategoriesSubscriptionEnvelope CategoryEnvelope CategoryKeywordsEnvelope FaultMessageEnvelope FeedbackEnvelope InitializationDataEnvelope InitializationRequestEnvelope MessageEnvelope MessagesRequestEnvelope MessageTrustEnvelope SendFeedbackEnvelope SendMessageEnvelope UserEnvelope UserUpdateEnvelope Poslovne objekte smo modelirali v IBM WebSphere Integration Developer 7.0.

88 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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 CRUD 23 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.

89 Razvoj informacijskih rešitev v oblačni arhitekturi Stran 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 Operacija calculatetrust Operacija calcualtetrust izračuna faktor zaupanja oz. F T 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