Konvergenca storitveno usmerjene arhitekture in ... · Service-oriented Architecture– SOA) z...

Ilče Georgievski

KONVERGENCA STORITVENO USMERJENE ARHITEKTURE IN RAČUNALNIŠTVA V

OBLAKU

Diplomsko delo

Maribor, maj 2010

Diplomsko delo univerzitetnega študijskega programa

KONVERGENCA STORITVENO USMERJENE ARHITEKTURE IN

RAČUNALNIŠTVA V OBLAKU

Maribor, maj 2010

Univerza v Mariboru

Študent: Ilče Georgievski

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

Smer: Informatika

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

Lektorica: doc. dr. Darinka Verdonik

ZAHVALA

Zahvaljujem se mentorju rednemu profesorju

doktorju Matjažu B. Juriču za pomoč in vodenje pri

opravljanju diplomskega dela.

Posebna zahvala velja staršema Vangelu in Snežani

ter bratu Borčetu, ki so mi omogočili študij in so me

podpirali v vsakem trenutku. Brez njihove podpore

to diplomsko delo verjetno ne bi obstajalo.

Hvala Nadi in Tometu za njuno nesebično podporo.

Hvala tudi vsem najbližjim prijateljem za to, kar so.

S t r a n | VII

Ilče Georgievski VII | S t r a n

KONVERGENCA STORITVENO USMERJENE ARHITEKTURE IN


Ključne besede: SOA, SCA, računalništvo v oblaku, SaaS, IaaS, IBM

UDK: 004.7771005(043.2)

Povzetek

V diplomskem delu obravnavamo konvergenco storitveno usmerjene arhitekture in

računalništva v oblaku. Predstavimo temelje storitveno usmerjene arhitekture z namenom

lažjega razumevanja prednosti, ki jih le-ta prinaša. Prav tako podrobno predstavimo

storitveno komponentno arhitekturo (SCA) kot model za gradnjo aplikacije in sisteme na

osnovi SOA principov. Sledi temeljni opis računalništva v oblaku, ki prispeva k jasnejšemu

razumevanju njegovega vpliva. Obravnavali smo virtualizacijo v sklopu oblaka in filozofijo

programske opreme kot storitve (SaaS). Dejansko vrednost računalništva v oblaku

potrdimo s konkretnimi podatki in primerjavami ter analiziramo relacije med SOA in

računalništvom v oblaku. Konvergenco obeh sil praktično prikažemo z načrtovanjem

prototipne storitve za zdravstveno oskrbo pacienta z uporabo IBM-ovih orodij.

VIII | S t r a n

VIII | S t r a n Ilče Georgievski

S t r a n | IX

Ilče Georgievski IX | S t r a n

SERVICE-ORIENTED ARCHITECTURE AND CLOUD

COMPUTING CONVERGENCE

Keywords: SOA, SCA, cloud computing, SaaS, IaaS, IBM

UDK: 004.7771005(043.2)

Abstract

In this final work we reveal service-oriented architecture and cloud computing

convergence. We present the SOA’s foundations to better understand the advantages

enterprises will take by using it. Our aim is to promote detailed service component

architecture (SCA), which describes a model for building applications and systems using

SOA's principles. Of course, cloud computing’s fundamentals contribute to a clearer

understanding of its impact. We cover virtualization under the cloud and software as a

service's philosophy (SaaS). The real value of cloud computing is confirmed by actual

data, comparisons and analysis of relationship between SOA and cloud computing. We

practically show the convergence of both forces by designing a prototipical service for

patient healthcare by using IBM tools.

X | S t r a n

X | S t r a n Ilče Georgievski

S t r a n | XI

Ilče Georgievski XI | S t r a n

Kazalo

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

2 STORITVENO USMERJENA ARHITEKTURA .......................................................3

2.1 Temelji storitveno usmerjene arhitekture ..............................................................4

2.1.1 Storitev .........................................................................................................6

2.1.2 Storitvena usmerjenost ..................................................................................6

2.1.3 Model logične arhitekture .............................................................................8

2.2 Predstavitev storitveno komponentne arhitekture ............................................... 11

2.2.1 Storitveno komponentna arhitektura ............................................................ 12

2.2.2 Storitvena komponenta ............................................................................... 13

2.2.3 Kompozit .................................................................................................... 18

2.2.4 Implementacija komponente ....................................................................... 24

2.2.4.1 Implementacijski tip Java ........................................................................ 24

2.2.4.2 Implementacijski tip BPEL ...................................................................... 26

2.2.5 Storitveni podatkovni objekt ....................................................................... 29

2.2.5.1 Podatkovni objekt .................................................................................... 31

2.2.5.2 Podatkovni graf ....................................................................................... 32

2.2.5.3 Metapodatki ............................................................................................ 34

2.3 Vodenje SOA ..................................................................................................... 34

3 RAČUNALNIŠTVO V OBLAKU ............................................................................ 37

3.1 Temelji računalništva v oblaku .......................................................................... 38

3.1.1 Infrastruktura oblaka ................................................................................... 40

3.1.2 Virtualizacija .............................................................................................. 44

XII | S t r a n

XII | S t r a n Ilče Georgievski

3.2 Programska oprema kot storitev ......................................................................... 47

3.2.1 Filozofija .................................................................................................... 48

3.2.2 Poslovni model ........................................................................................... 50

3.2.3 Arhitektura aplikacije .................................................................................. 52

3.2.4 Operativna struktura ................................................................................... 54

3.2.5 Varnost ....................................................................................................... 55

3.3 Vrednost računalništva v oblaku ........................................................................ 57

3.3.1 Infrastrukturne možnosti ............................................................................. 57

3.3.2 Ekonomija oblačnega računalništva ............................................................ 58

3.3.3 Ovire in priložnosti ..................................................................................... 61

4 KONVERGENCA STORITVENO USMERJENE ARHITEKTURE IN

RAČUNALNIŠTVA V OBLAKU ................................................................................... 67

4.1 SOA za računalništvo v oblaku .......................................................................... 68

4.2 IaaS kot infrastruktura za SOA ........................................................................... 70

4.3 SOA in SaaS prekrivanje ................................................................................... 75

4.4 Elementarna metodologija za razvoj SOA rešitev v oblaku ................................ 77

4.4.1 Definiranje podatkov .................................................................................. 77

4.4.2 Definiranje storitev ..................................................................................... 79

4.4.3 Definiranje procesov ................................................................................... 80

4.4.4 Definiranje vodenja ..................................................................................... 81

4.5 IBM prinaša SOA k oblaku ................................................................................ 83

5 STORITEV ZA ZDRAVSTVENO OSKRBO PACIENTOV .................................... 89

5.1 Problemsko področje ......................................................................................... 90

5.2 Ideja ................................................................................................................... 90

5.3 heJump arhitektura ............................................................................................. 92

5.3.1 Podatkovni model ....................................................................................... 94

S t r a n | XIII

Ilče Georgievski XIII | S t r a n

5.3.2 Komponentni model ................................................................................... 97

5.4 Storitev PHRService ........................................................................................ 101

6 SKLEP ................................................................................................................... 105

7 LITERATURA ....................................................................................................... 107

8 PRILOGE ............................................................................................................... 113

8.1 Seznam slik ...................................................................................................... 113

8.2 Seznam shem ................................................................................................... 114

8.3 Seznam preglednic ........................................................................................... 115

8.4 Seznam izvorne kode ....................................................................................... 115

8.5 Naslov študenta ................................................................................................ 117

8.6 Kratek življenjepis ........................................................................................... 117

XIV | S t r a n

XIV | S t r a n Ilče Georgievski

S t r a n | XV

Ilče Georgievski XV | S t r a n

Kratice

SOA Service Oriented Architecture

SCA Service Component Architecture

CC Cloud Computing

WSDL Web Service Description Language

SLA Service Level Agreement

IT Information Technology

LOB Line Of Business

ESB Enterprise Service Bus

BPEL Business Process Execution Language

CDL Choreography Description Language

XML eXtensible Markup Language

SAP

SCDL

System Analysis and Program

Service Component Definition Language

SOAP Simple Object Access Protocol

API Application Programming Interface

URI Uniform Resource Identifier

WS Web Service

SDO Service Data Object

IBM International Business Machines

SaaS Software as a Service

PaaS Platform as a Service

IaaS Infrastructure as a Service

VM Virtual Machine

OVF Open Virtualization Format

CRM Costumer Relationship Management

DDoS Distributed Denial Of Service

HPC High Performance Computing

WAN Wide Area Network

PHR Patient Healthcare Record

http://en.wikipedia.org/wiki/Wide_Area_Network

http://en.wikipedia.org/wiki/Personal_health_record

http://en.wikipedia.org/wiki/High-performance_computing

http://en.wikipedia.org/wiki/Denial-of-service_attack

http://en.wikipedia.org/wiki/Customer_relationship_management

http://www.vmware.com/appliances/getting-started/learn/ovf.html

http://en.wikipedia.org/wiki/Virtual_machine

http://en.wikipedia.org/wiki/Cloud_computing

http://en.wikipedia.org/wiki/Platform_as_a_service

http://en.wikipedia.org/wiki/Software_as_a_service

http://en.wikipedia.org/wiki/IBM

http://www.osoa.org/display/Main/Service+Data+Objects+Specifications

http://www.w3.org/2002/ws/

http://en.wikipedia.org/wiki/Uniform_Resource_Identifier

http://en.wikipedia.org/wiki/Application_programming_interface

http://www.w3.org/TR/soap/

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wps.doc/doc/csca_scdl.html

http://en.wikipedia.org/wiki/SAP_AG

http://en.wikipedia.org/wiki/XML

http://www.w3.org/TR/ws-cdl-10/

http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf

http://en.wikipedia.org/wiki/Enterprise_service_bus

http://en.wikipedia.org/wiki/Line_of_business

http://en.wikipedia.org/wiki/Information_technology

http://www.sla-zone.co.uk/

http://www.w3.org/TR/wsdl

http://en.wikipedia.org/wiki/Cloud_computing

http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications

http://en.wikipedia.org/wiki/Service-oriented_architecture

XVI | S t r a n

XVI | S t r a n Ilče Georgievski

1 UVOD S t r a n | 1

Ilče Georgievski 1 | S t r a n

1

1 UVOD

»Ne človek, niti narod ne more obstajati brez vzvišene ideje.«

Fjodor Dostojevski

Sploh obstaja kdo, ki ni v oblaku? Oblak je znana beseda, vendar nova v svetu

informacijskih tehnologij, in računalništvo v oblaku nov, de jour korak k evoluciji tega

sveta. Ljudje se bojijo novih dejstev, a človek ne more obstajati brez čudovite ideje.

Računalništvo v oblaku je sprovociralo svet, ne razumejo ga in ga odvržejo, toda o

njegovem vzvišenem življenju bomo govorili.

Računalništvo v oblaku je evolucija različnih tehnologij, ki so se sinergirale in spremenile

pristop h gradnji infrastrukture informacijskih tehnologij. Nastop na odru, kakršnega ima

računalništvo v oblaku, je primerljiv z nastopom spleta pred petnajstimi leti, kajti

tehnologije, ki jih je splet omogočil, so že nekaj časa obstajale; podobno je večina

tehnologij, ki sestavljajo računalništvo v oblaku, prisotnih že nekaj let.

Računalništvo v oblaku obeta povečanje hitrosti, s katero so aplikacije dobavljene,

povečanje inovativnosti in zmanjšanje stroškov ter hkratno povečanje elastičnosti posla.

Namesto da programi in podatki tečejo na posameznem računalniku, vse gostuje v oblaku

– megleni sestavi računalnikov in strežnikov, ki so dostopni preko spleta. Poleg tega

omogoča dostop do aplikacij in dokumentov kjerkoli na svetu, brez občutka namizne

omejenosti, ter lajša sodelovanje med skupinami na različnih lokacijah.

2 | S t r a n 1 UVOD

2 | S t r a n Ilče Georgievski

Dokler storitveno usmerjena arhitektura zagotavlja ogrodje za približevanje arhitekture

informacijskih tehnologij podjetju, predstavlja uporaba računalništva v oblaku pravi vir

denarja. Storitvena arhitektura dejansko omogoča elastičnost sistemov in hkrati pripravlja

podjetje na uporabo računalništva v oblaku tako, da ustvari potrebne vmesnike in podpira

standarde. Razširitev storitvene arhitekture je platforma na spletu, ki zagotavlja dostopnost,

povezanost, varnost in zmanjšanje stroškov. Omogočeno je tako izkoriščanje virov preko

spleta, ki zagotavljajo dostop do zgrajenih procesov in storitev, kakor tudi dostop do

platforme, dobavljene kot storitve. Vrednost tega razširjanja se nanaša na računalništvo v

oblaku.

Naš cilj je poleg predstavitve storitveno usmerjene arhitekture spodbuditi uporabo

storitveno komponentne arhitekture kot način gradnje rešitve SOA. Še en korak naprej se

seznanimo z idejo in osnovami računalništva v oblaku, predstavimo storitve, ki jih ponuja,

in posebno pozornost posvetimo programski opremi kot storitvi. K ciljem prispeva tudi

razlaga o dejanski vrednosti računalništva v oblaku in določitev konvergence med

računalništvom v oblaku in storitveno usmerjeno arhitekturo na praktičnem primeru.

Temelje storitveno usmerjene arhitekture predstavimo v drugem poglavju. Relativno nov

pristop gradnje arhitekture na osnovi principov storitvene arhitekture predstavlja storitveno

komponentna arhitektura. Podrobnosti tega pristopa obravnavamo tudi v tem poglavju.

Tretje poglavje se osredotoča prav na računalništvo v oblaku. Opisani so temeljni pojmi,

virtualizacija, programska oprema kot storitev in dejanska vrednost računalništva v oblaku

v svetu informacijskih tehnologij.

Konvergenco storitvene arhitekture in računalništva v oblaku predstavimo v četrtem

poglavju. Opisani so predpogoji, ki jih storitvena arhitektura mora izpolniti z namenom

učinkovite uporabe računalništva v oblaku. Predlagani so tudi viceversa predpogoji.

V petem poglavju na praktičnem primeru prikažemo osvojena teoretična znanja.

Predstavimo problemsko področje in idejno rešitev v skladu s principi storitveno

komponentne arhitekture in s tem storitveno usmerjene arhitekture. Predstavljena je tudi

delna implementacija arhitekture.

Šesto poglavje predstavlja ključne ugotovitve diplomskega dela.

2 STORITVENO USMERJENA ARHITEKTURA S t r a n | 3


2

2 STORITVENO USMERJENA ARHITEKTURA

Poglavje predstavlja storitveno usmerjeno arhitekturo (angl. Service-oriented Architecture –

SOA) z različnimi definicijami in poskuša ugotoviti, kaj storitvena arhitektura dejansko je.

Predstavljena je storitveno komponentna arhitektura (angl. Service Component Architecture

– SCA) kot novejši način za dobavitev aplikacij, ki podpira koncepte storitvene arhitekture.

Na kratko je opisano SOA vodenje (angl. SOA governance) kot koncept, ki uporablja

aktivnosti za izvajalni nadzor nad storitvami v storitveni arhitekturi.

Osnovni problem funkcionalno načrtovanih poslovnih informacijskih sistemov je

naslavljanje podpore določeni aktivnosti, in ne celotnemu poslovnemu procesu. Takšen

poslovni proces mora povezati množico obstoječih sistemov. Tehnično povedano to

pomeni, da je potrebna integracija različnih aplikacij oziroma tehnologij ter določitev

zaporedja izvajanja. Veliko podjetij upa, da bodo odpravila zalomljene informacijsko-

tehnološke (angl. Information Technology – IT) arhitekture tako, da na vrh obstoječih

tehnologij dodajo še en tehnični nivo.

Storitveno usmerjene arhitekture omogočajo rešitev tega problema tako, da ponujajo

enostaven koncept za razvoj poslovnih aplikacij z abstrakcijo spletnih storitev. Agilnost, ki

jo podjetju prinaša SOA, temelji na uporabi različnih transportnih mehanizmov, modelu

komunikacije, zagotavljanju varnosti in zanesljivosti ipd.

Storitvena arhitektura kot vrsta porazdeljenih sistemov je sestavljena iz spletnih storitev, ki

predstavljajo komponente sistema. Pomembno je zagotoviti učinkovit način ustvarjanja

4 | S t r a n 2.1 Temelji storitveno usmerjene arhitekture


teh komponent ter mehanizem za opisovanje, kako te komponente delujejo med seboj.

SCA definira splošni pristop, ki zagotavlja ti dve stvari.

SOA vodenje zagotavlja takšno okolje, ki nam bo omogočilo uspešnost na osnovi

fleksibilnosti in nizkih stroškov vzdrževanja. To je možno doseči s ponovno uporabo

storitev, kar predstavlja glavni cilj vodenja.

2.1 Temelji storitveno usmerjene arhitekture

Spletne storitve in njihova arhitektura temeljijo na storitveni arhitekturi (1). Odgovor na

vprašanje »Kaj je SOA?« je odvisen od odgovarjalca, ker različnim ljudem SOA različno

pomeni.

Storitvena arhitektura zagotovo ne predstavlja zgolj izpostavljanja metod preko spletnih

storitev. Pogosta napaka je, da uporaba tehnologij spletnih storitev pomeni kar uporabo

SOA. Za storitveno arhitekturo ne moremo reči, da je zgolj integracija aplikacij (angl.

Enterprise Application Integration). SOA je zasnovalni koncept in arhitektura hkrati,

kjer koncept načrtovanja zagotavlja oblikovanje aplikacij z dobro definiranimi

samoopisujočimi vmesniki in storitvami, organizirani v poslovnem procesu, ter arhitektura,

ki pri integraciji ponuja enostavne mehanizme za uporabo teh vmesnikov (2).

Nekateri pravijo, da je SOA predvsem paradigma, ki ponuja organiziranje in izkoriščanje

porazdeljenih sposobnosti, ki so lahko pod nadzorom različnih lastniških domen.

Paradigma je opisana z vidnostjo, interakcijo in učinkom. Vidnost se nanaša na

zmogljivost, da se med seboj vidijo tisti, ki imajo zahteve, in tisti s sposobnostjo obdelati te

zahteve. Ko pride do ujemanja potreb in sposobnosti, se izvede interakcija preko izmenjave

informacij in proženih akcij. Namen uporabe sposobnosti je uresničitev enega ali več

učinkov iz realnega sveta, ki so lahko povratne informacije ali spremembe stanja

sodelujočih entitet (3).

Pomembno stališče pri definiranju storitvene arhitekture predstavlja poslovanje. Pri tem

nas zanima, kako posel deluje oziroma kateri poslovni procesi so izvedeni, kakšna je

2.1 Temelji storitveno usmerjene arhitekture S t r a n | 5


organizacijska struktura, kateri so kratkoročni in dolgoročni poslovni cilji, kako se

gospodarski in tržni vplivi odražajo na doseganju teh ciljev ipd. Odgovor na ta vprašanja

nam zagotavlja poslovni načrt, ki je izhodišče storitveni arhitekturi. Zato lahko trdimo, da

je SOA most, ki ustvari simbiotično in sinergijsko vez med poslovnim svetom in svetom

informacijskih tehnologij tako, da naredi oba učinkovitejša (4).

Na osnovi poslovnega načrta oblikujemo model informacijskega sistema. Tako zagotovimo

lažje upravljanje sprememb informacijskega sistema, povzročenih zaradi sprememb

poslovanja. Sodelovanje med poslovnim in informacijskim načrtom je predstavljeno s

SOA življenjskim ciklom, kjer je poslovni proces iterativno modeliran, sestavljen,

dobavljen in spremljan. Pomen zadnjega je, da informacijski sistem lahko uporabimo za

spremljanje stanja poslovanja, poročanje o doseganju zadanih ciljev, ponujanje ustreznih

sprememb v poslovnem načrtu ipd.

Sinergijska povezava med poslovnim in informacijskim načrtom je omogočena z

naslednjimi lastnostmi (4):

• formalizem in jezik za zajemanje poslovnega načrta

• metodologija za preslikavo poslovnega načrta v množico implementacijskih

artefaktov informacijskega sistema

• infrastruktura za gostovanje teh artefaktov, ki je fleksibilna, kot je sam poslovni

načrt

• prostor za ohranitev povezave med poslovnim načrtom in informacijskim

sistemom, ki je lahko uporaben za identifikacijo in popravljanje napak pri

doseganju ciljev ter za omejitve poslovnega načrta

• sredstva, s katerimi lahko upravljamo sistem, da zagotovimo izpolnjevanje teh

ciljev

Poslovni proces in opravila, iz katerih je sestavljena storitvena arhitektura, si lahko

predstavljamo kot storitve. Tako je poslovni načrt dejansko kompozicija storitev in politik,

načrt informacijskega sistema pa pogoji, pod katerimi so te storitve uporabljene.

Kljub temu se še vedno pojavi vprašanje: »Kaj pravzaprav je storitev?«



2.1.1 Storitev

Pri vsaki definiciji SOA osrednji koncept predstavlja storitev. Izhajamo lahko iz slovarske

definicije samostalnika storitev1

• sposobnost opraviti delo za koga

in dodamo še lastnosti:

• specifikacija dela, ponujenega nekomu

• ponudba za opravljanje dela za koga

Sklep je, da so storitve mehanizem, s katerim je omogočeno srečanje med potrebami in

sposobnostmi (3).

Vidnost, interakcija in učinek kot koncepti SOA paradigme se neposredno aplicirajo na

storitvah. Vidnost storitve je zagotovljena z vmesnikom, ki predstavlja opis sporočil,

potrebnih za interakcijo in tudi pogodbo med storitvijo in njenimi odjemalci (3). Opis

storitve vsebuje vhode, izhode in semantiko oziroma pove, kaj je opravljeno pri proženju

storitve in kakšni so pogoji za uporabo storitve.

Storitve morajo razumeti vsebino posameznih sporočil in jih obdelovati po načelu šibke

sklopljenosti2 Slika 2.2 ( ). Vsak vmesnik vsebuje operacije, ki definirajo zaporedje

sporočil. Zaporedje je lahko po principu zahteva/odgovor, enosmerno, obvestilo ali

spodbujen odgovor (5) (Slika 2.1).

2.1.2 Storitvena usmerjenost

Na procesnem nivoju lahko rečemo, da je storitev ponovljivo opravilo (4). Integracijo

spletnih storitev v poslovne procese omogočimo s kompozicijo storitev. S takšnimi

definiranimi procesi dosežemo ključne prednosti SOA (5):

1 Naročeno delo, ki se opravi za koga, navadno za plačilo. 2 Pravila, ki jih uporabljamo za definiranje storitve v določenem kontekstu, so lahko neuporabna v drugem.

ODJEMALEC Zahteva

Odgovor

Zahteva Odgovor

Obvestilo

Prošnja ODJEMALEC

ODJEMALEC

ODJEMALEC

STORITEV

STORITEV

STORITEV

STORITEV

Slika 2.1 – Tipi izmenjave sporočil



• izboljšana odzivnost na poslovne spremembe

• vpogled v poslovne procese v realnem času

• enostavnost definicije in sprememb poslovnih procesov

Storitvena usmerjenost predstavlja način integracije poslovanja kot množica povezanih

storitev. Najprej definiramo storitve v vsaki navpični in vodoravni liniji poslovanja (angl.

line of business – LOB), in nato začnemo povezovati te LOB-e s kompozicijo njihovih

storitev v večjem poslovnem procesu (4). Posledica storitvene usmerjenosti je

fleksibilnost, izražena z možnostjo iterativne optimizacije poslovnega načrta. Pri tem je

(ne)učinkovitost IT strukture manj pomembna.

Iz poslovnega načrta identificiramo ustrezno granularnost in konstrukcijo storitve. Da

zagotovimo minimalno podvojenost programiranja in se izognimo redundanci poslovne

logike, lahko uporabimo fasado3

Slika 2.2

za enkapsulacijo te logike. Granularnost fasade naj bi

bila grobozrnata. To pomeni, da ni treba prožiti več metod za izvajanje ene poslovne

funkcije. Boljša analiza funkcionalnosti in boljši načrt pomeni bolj grobo granularnost (2)

( ).

3 Načrtovalski vzorec, ki ponuja poenostavljen vmesnik do veliko programskih kod.

OBJEKTI

KOMPONENTE

SPLETNE STORITVE

SKLOPLJEN

OST

tesna

šibka

fina

groba

GRAN

ULA

RNO

ST

Slika 2.2 – Granularnost in sklopljenost v SOA



Delo si lahko olajšamo, če poslovne procese in pripadajoče sodelovanje, izmenjavo

informacij in aktivnosti izrazimo z uporabo ustreznih tehnologij, kot so ESB (angl.

Enterprise Service Bus), BPEL (angl. Business Process Execution Language) in CDL (angl.

Choreography Description Language).

2.1.3 Model logične arhitekture

Vemo že, da poslovni vidik poudarja storitveno usmerjenost. Tehnični vidik pa se nanaša

na arhitekturo oziroma na arhitekturni stil gradnje šibko sklopljenih, interoperabilnih in

sestavljivih komponent oziroma programskih agentov – storitev. IT arhitektura izkorišča

principe storitvene usmerjenosti, da doseže tesnejšo povezavo med poslovanjem in

informacijskim sistemom, ki podpira to poslovanje (4).

Sedaj lahko trdimo, da SOA ni zgolj tehnologija. SOA vključuje orodja in metodologije

za zajemanje poslovnega načrta. SOA vključuje orodja, programski model in tehnike za

implementacijo poslovnega načrta v informacijski sistem. Vključuje vmesno infrastrukturo

za gostovanje implementacije. SOA upravlja te implementacije, zagotavlja poslovanju

razpoložljivost le-teh in omogoča učinkovito uporabo virov pri izvajanju implementacije.

SOA zagotavlja avtorizacijo in procese za kontrolo sprememb v poslovnem načrtu ter

njegovi implementaciji. Nenazadnje, SOA pospeši časovno in vrednostno pridobivanje teh

koristi.

Osredotočimo se lahko na logično arhitekturo in podrobno opišemo pripadajoče

komponente. Slika 2.3 prikaže model logične arhitekture, ki poskuša razgraditi

funkcionalne temelje aplikacijskega načrta. Komponente, kot so interakcijske storitve,

procesne storitve, informacijske storitve, partnerske storitve, poslovne aplikacijske storitve

in dostopne storitve, uporabljamo za razporeditev programske opreme, ki nam omogoča

zajem logike, specifične za poslovni načrt. Druge komponente asistirajo preostalemu delu

SOA življenjskega cikla (4):

• razvojne storitve – integrirano okolje za načrtovanje in ustvarjanje rešitev

• poslovna inovacija in optimizacija storitev – omogoča boljše odločanje s časovno

realno poslovno informacijo

• IT upravljanje storitev – upravljanje in zaščita storitev, aplikacij in virov

• infrastrukturne storitve – optimizira prepustnosti, razpoložljivosti in izvedbe



Zabeležimo lahko, da komponente v zgornji vrstici (interakcijske, procesne in

informacijske storitve) predstavljajo tradicionalno obliko trinivojske arhitekture

(prezentacijski nivo, nivo poslovne logike, podatkovni nivo). Če upoštevamo, da je

komponenta poslovne aplikacijske storitve dekompozicija procesne storitve, vidimo

večnivojsko arhitekturo, ki še vedno upošteva principe SOA.

Interakcijske storitve predstavljajo prezentacijsko logiko poslovnega načrta. Komponente

podpirajo interakcijo med aplikacijami in uporabniki (ljudmi, roboti, senzorji ipd). Za

vsako interakcijo je značilna zmožnost projekcije prilagojenega pogleda informacijskega

sistema na potrebe uporabnika. Prilagoditev se nanaša na zvestobo specifični interakciji,

pogostost interakcije in prezentacijsko kompozicijo, ki je najbolj ustrezna.

Procesne storitve predstavljajo kompozicijsko logiko, kot je tok poslovnega procesa (angl.

business process flow) in poslovni avtomat4

4 Avtomat je dogodkovno vodena poslovna aplikacija, v kateri zunanje operacije povzročajo spremembe avtomata iz enega diskretnega načina v drugega. Vsak način predstavlja posamezno stanje, ki določa, katere aktivnosti in operacije se lahko zgodijo.

(angl. business state machine). Oba pristopa

omogočata koreografijo storitev z različnim stilom (4). Seveda lahko uporabimo

procesiranje odločitvenega drevesa ali poslovna pravila za orkestracijo in avtomatizacijo

poslovnih procesov.

INFRASTRUKTURNE STORTIVE

RAZV

OJN

E ST

ORI

TVE

IT U

PRAV

LJAN

JE S

TORI

TEV

POSLOVNA INOVACIJA & OPTIMIZACIJA STORITVE

INTERAKCIJSKE STORITVE

PROCESNE STORITVE

INFORMACIJSKE STORITVE

POSLOVNE APLIKACIJSKE

STORITVE

DOSTOPNE STORITVE

PARTNERSKE STORITVE

ESB

Slika 2.3 – Model logične arhitekture



Informacijske storitve vsebujejo podatkovno logiko poslovnega načrta. Logika obstaja na

dveh nivojih (Slika 2.4). Na vrhu informacijske storitve omogočajo dostop do trajnih

podatkov. Običajno gre za povpraševalne izjave za pridobivanje informacij ali za

referenčne preglede integritet manipuliranih podatkov.

Na tem nivoju informacijske storitve združujejo različne podatkovne vire – zagotavljajo

poenostavljen vzorec za dostop do teh virov.

Na drugem nivoju imajo informacijske storitve podarhitekturo za upravljanje kompozicije

podatkov in pretoka podatkov skozi organizacije. Kompozicija informacij je izvedena na

tak način, da se ujema s kompozicijo storitev v poslovnem načrtu. V praksi sta podatkovni

in aplikacijski model pogosto ločena. Pomen tega je, da mora aplikacija opraviti

kompleksna združevanja čez podatkovni model z namenom pridobitve potrebnih

informacij. Kompleksnost dostopnih vzorcev je povečana z zbiranjem podatkov, potrebnih

za kompleksno kompozicijo poslovne storitve (4). Zapletenost se še poveča, če se podatki

nahajajo v različnih podatkovnih bazah in sistemih – relacijske podatkovne baze, različni

podatkovni katalogi, datotečni sistemi, XML repozitorji ipd.

Druga zahteva na drugem nivoju predstavlja premik informacije iz enega v drugi del

organizacije z namenom zadovoljiti svoj podatkovni tok. Možna je uporaba ETL (angl.

Extract-Transform-Load) mehanizma za integracijo podatkov, ki je tesno povezan s

skladiščenjem podatkov ter poslovno inteligenco (6).

Partnerske storitve zajemajo semantiko partnerskih interoperabilnosti, ki so direktno

vključene v poslovni načrt. Partnerske storitve projicirajo partnerjem pogled v poslovanje

INFORMACIJSKE

STORITVE

POSLOVNA INTELIGENCA

INTEGRACIJA INFORMACIJ

GLAVNO UPRAVLJANJE PODATKOV

UPRAVLJANJE PODATKOV

UPRAVLJANJE VSEBIN

Slika 2.4 - Upravljanje informacij v SOA

2.2 Predstavitev storitveno komponentne arhitekture S t r a n | 11


in nadzirajo njihovo interakcijo s poslovanjem. Vključujejo politike in omejitve, s katerimi

se morajo druga podjetja uskladiti. Lahko vključujejo poslovno logiko za upravljanje z

načinom izbiranja partnerjev.

Poslovne aplikacijske storitve implementirajo jedro poslovne logike. Te storitvene

komponente so namensko ustvarjene kot storitve znotraj poslovnega modela in

predstavljajo osnovne gradnike v poslovnem načrtu – storitve, ki niso dekompozirajoče

znotraj poslovnega modela in so sestavljive pri oblikovanju storitev na višjem nivoju.

Dostopne storitve integrirajo zapuščinske aplikacije in funkcije v storitveno usmerjeni

arhitekturi. Integracija je dosežena z enostavnim ovijanjem te funkcije in ponujanjem kot

storitve. V bolj zapletenih primerih lahko nadgradimo logiko obstoječih funkcij tako, da

izpolnijo zahteve poslovnega načrta (4).

2.2 Predstavitev storitveno komponentne arhitekture

Model programiranja zajema množico vlog, opravil, jezikov in kodirnih pravil,

uporabljenih za ustvarjanje programske opreme. SOA model programiranja je načrtovan z

dvema ciljema:

• Programski model mora zajemati in namestiti pripadajoče programske jezike,

konkretno aplikacijo in komponentne modele, uporabljene v informacijskem

sistemu. Če uporabimo CICS5, BPEL, XML, DB26, SAP7

• Programski model mora maskirati razlike med temi jeziki in okoljem v največji

možni meri tako, da bi poenostavil programiranje in maksimiziral možnosti

ponovnih uporab ter kompozitnosti SOA aplikacije.

ipd. v sestavljenem

sistemu, potem mora SOA model programiranja omogočiti nadaljno uporabo teh

izvajalnih okolij z namenom ohraniti obstoječe poslovne investicije in spretnosti.

5 CICS – Costumer Information Control System – transakcijski strežnik, ki teče na IBM-ovo platformo. 6 DB2 – IBM-ov relacijski podatkovni strežnik. 7 SAP – Standard Assessment Procedure – programska oprema za upravljanje poslovanja.

12 | S t r a n 2.2 Predstavitev storitveno komponentne arhitekture


Osredotočimo se na storitveno komponentno arhitekturo, ki je sestavni del SOA modela

programiranja.

2.2.1 Storitveno komponentna arhitektura

Storitveno komponentna arhitektura8

Cilj SCA predstavlja zmanjšanje ali odstranitev »incidentne« kompleksnosti, s katero se

soočajo aplikacijski razvijalci pri ukvarjanju z vmesnimi API-ji (angl. Application

Programming Interface). SCA omogoča razvijalcem, da se fokusirajo na pisanje poslovne

logike. Koristi tega pristopa so (7):

(angl. Service Component Architecture – SCA) je

jezikovno in tehnično nevtralen pristop za kompozicijo storitev. SCA predstavlja izvršljiv

model za sestavljanje storitev v poslovnih rešitvah. Prav tako je SCA poenostavljen

komponentni programski model za implementacijo poslovnih storitev.

• poenostavljen razvoj poslovnih komponent

• šibka sklopljenost

• heterogenost – več implementacijskih jezikov in komunikacijskih mehanizmov

• poenostavljeno sestavljanje in namestitev poslovnih rešitev

• povečana agilnost in fleksibilnost

• zaščita pridobitev poslovne logike pred nizkonivojskimi spremembami

• izboljšana testabilnost

SCA podpira različne implementacije komponente, kot je BPEL, Java, COBOL, XML9

SCA podpira tudi različne tipe vmesnika, kot je WSDL (angl. Web Service Definition

Language), Java interface ipd. Možna je uporaba SCDL-a (angl. Service Component

Definition Language) za definiranje storitvene komponente, ki implementira storitve.

SCDL izraža pomembne komponentne podrobnosti, kot so moduli, reference, uvozi in

izvozi (8).

,

C++, PHP ipd. Izbira jezika je odvisna od ideje, ki jo želimo ustvariti s poslovno

komponento. Na primer, BPEL je primeren za izražanje kompozicije storitev v obliki

procesnega toka, Java pa za izražanje logike osnovnih funkcij storitve.

8 Objavljena leta 2005 v obliki specifikacije s strani BEA Systems, IBM, Iona Technologies, Oracle, SAP, Siebel Systems, Sybase in Xcalia. 9 Tehnologije, ki temeljijo na XML, kot je XSLT, XQuery ipd.



SCA komponente so lahko povezane z različnimi tipi vezav, kot je WSDL/SOAP za

spletne storitve, JavaTM Message Service (JMS) za sporočilno usmerjene sisteme in

J2EETM Slika 2.5 Connector Architecture (JCA) za informacijske storitve ( ).

SCA ponuja gradnjo storitveno usmerjene aplikacije v dveh delih – prvi del predstavlja

implementacija storitvenih komponent in drugi del sestavljanje komponent v poslovni

aplikaciji. Najpomembnejši elementi SCA arhitekture so (9):

• storitvena komponenta – tehnično in jezikovno neodvisna predstavitev storitvene

implementacije

• vezava storitev – tehnično in jezikovno neodvisna predstavitev kompozicije storitev

• storitveni podatkovni objekt (angl. Service Data Object – SDO) – tehnično in

jezikovno neodvisna predstavitev podatkovnih entitet

2.2.2 Storitvena komponenta

Komponente predstavljajo atome, iz katerih je SCA aplikacija zgrajena. SCA komponente

se dosledno obnašajo in jih lahko sestavimo v različnih konfiguracijah. Razumevanje SCA

je le mogoče z razumevanjem teh temeljnih gradnikov (10).

Slika 2.5 – SCA sestavni model

KOMPOZIT

KOMPOZIT

STORITVENA KOMPONENTA


ZUNANJA REFERENCA

ZUNANJA REFERENCA

STORITEV

ZUNANJA REFERENCA STORITVENA

KOMPONENTA

STORITEV



RMI/IIO SOAP/HTTP

BPEL Java EE

JMS

C++

Po načinu govora SCA je komponenta primerek implementacije, ki je ustrezno

konfiguriran (11). Implementacija je koda, ki dejansko ponuja komponentne funkcije.

Konfiguracija, izražena v SCDL, definira interakcijo komponente z zunanjim svetom.

Teoretično je za implementacijo SCA komponente možna uporaba skoraj vsake

tehnologije.

Komponente so podelementi kompozita, ki ga podrobneje obravnavamo kasneje.

Komponenta je predstavljena s komponentnim elementom, ki je otrok kompozitnega

elementa. Vsak kompozit lahko vsebuje enega ali več komponentnih elementov. Spodnja

shema prikazuje XML shemo komponentnega elementa:

Komponentni element vsebuje naslednje atribute (11):

• Name (obvezen) – ime komponente. Ime mora biti unikatno med vsemi

komponentami v kompozitu.

• Autowire (opcijski) – določa, ali bodo komponentne reference samodejno vezane.

Privzeta vrednost je false.

<?xml version="1.0" encoding="UTF-8"?>  <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"

targetNamespace="xs:anyURI" name="xs:NCName" local="xs:boolean"? autowire="xs:boolean"? constrainingType="QName"? requires="list of xs:QName"? policySets="list of xs:QName"?>

... <component name="xs:NCName" requires="list of xs:QName"?

autowire="xs:boolean"? requires="list of xs:QName"? policySets="list of xs:QName"? constrainingType="xs:QName"?>*

<implementation/>? <service name="xs:NCName" requires="list of xs:QName"?

policySets="list of xs:QName"?>* <interface/>? <binding uri="xs:anyURI"? requires="list of xs:QName"?

policySets="list of xs:QName"?/>* </service> <reference name="xs:NCName" multiplicity="0..1 or 1..1 or 0..n or 1..n"?

autowire="xs:boolean"? target="list of xs:anyURI"? policySets="list of xs:QName"? wiredByImpl="xs:boolean"? requires="list of xs:QName"?>* <interface/>? <binding uri="xs:anyURI"? requires="list of xs:QName"?

policySets="list of xs:QName"?/>* </reference> <property name="xs:NCName" (type="xs:QName" | element="xs:QName")?

mustSupply="xs:boolean"? many="xs:boolean"? source="xs:string"? file="xs:anyURI"?>* property-value?

</property> </component>

... </composite>

Shema 2.1 – XML shema komponente



• Requires (opcijski) – seznam namer politike.10

• PolicySets (opcijski) – seznam množic politike.

• ConstrainingType (opcijski) – ime constrainingTypa. Ko je določen, so množica

storitev, referenc in lastnosti ter povezane namere, omejene na množici, definirane

s constrainingTypom.

Komponenta ima največ en implementacijski element. Komponenta brez

implementacijskega elementa ni izvajalna.

Osnova vsake komponente so storitve, reference, lastnosti in vezave, ki jih opisujemo v

nadaljevanju (Slika 2.6).

Vsak komponentni element običajno implementira nekakšno poslovno logiko, ki je

izpostavljena kot ena ali več storitev. Element storitev ima naslednje atribute:

• name (obvezen) – ime storitve; ujemati se mora z imenom storitve, definiranim v

implementaciji

• requires (opcijski) – seznam namer politike

• policySets (opcijski) – seznam množic politike

Storitev ima največ en vmesnik, ki je dostopen odjemalcu in opiše ponujene operacije.

Vmesnik je opisan z vmesniškim elementom, ki je otrok storitvenega elementa. Če

vmesnik ni določen, potem je v uporabi implementacijskega vmesnika. V nasprotnem

primeru mora vmesnik ponujati ustrezno podmnožico operacij, definiranih v

implementaciji. V primeru implementacije Java komponenta uporablja vmesnik Java,

10 Pojem politika je uporabljen za opis sposobnosti ali omejitev, ki se lahko aplicirajo na storitveni komponenti ali na interakciji med komponentami.


....

....

STORITEV

REFERENCA

LASTNOST

Slika 2.6 - SCA komponenta



medtem ko je komponenta implementirana z BPEL-om lahko opiše storitve z uporabo

WSDL-ja (angl. Web Service Description Language).

Komponenta lahko uporablja storitve drugih komponent iz svoje ali zunanje domene.

Takrat rečemo, da komponenta kliče referenco, ki definira vmesnik z operacijami, ki jih

komponenta potrebuje. Komponentni element ima nič ali več referenčnih elementov, ki

konfigurirajo reference. Reference, ki so konfigurirajoče, so definirane v implementaciji.

Referenčni element vsebuje naslednje atribute (11):

• Name (obvezen) – ime reference. Ujemati se mora z imenom reference,

definiranim v implementaciji.

• Autowire (opcijski) – določa, ali bodo reference samodejno vezane. Privzeta

vrednost je false.

• Requires (opcijski) – seznam namer politike.


• Multiplicity (opcijski) – definira število vezav, ki jih ima referenca s ciljnimi

storitvami; vrednost je lahko 1..1, 0..1, 1..n, 0..n.

• Target (opcijski) – seznam URI-jev (angl. Uniform Resource Identifier) ciljnih

storitev.

• WiredByImpl (opcijski) – predstavlja logično vrednost. Privzeta je false, kar

pomeni, da implementacija dinamično poveže referenco. Če je vrednost true, potem

je cilj reference določen v času izvajanja s strani implementacijske kode. Takrat

referenca znotraj kompozita ni statično vezana.

Podobno kot pri storitvi ima referenca največ en vmesnik, ki opiše operacije, zahtevane s

strani reference. Vmesnik je opisan z vmesniškim elementom, ki je otroški element

referenčnega elementa.

Poleg storitve in reference ima komponentni element nič ali več lastnostnih elementov

(angl. property element). Lastnostni elementi konfigurirajo podatkovne vrednosti za

lastnosti implementacije. Vsak lastnostni element ponuja vrednost za poimenovano

lastnost, ki je posredovana implementaciji. Konfigurajoče lastnosti in njihovi tipi so

definirani v implementaciji. Vrednost lastnosti je lahko določena na enega od naslednjih

načinov (11) (10):



• Kot vrednost, dobavljena kot vsebina lastnostnega elementa.

• Z referenciranjem vrednosti lastnosti kompozita, ki vsebuje komponento. Referenca

je opravljena z uporabo atributa source, ki ga lastnostni element vsebuje.

• Z določanjem URI-ja do datoteke, ki vsebuje vrednost lastnosti. Referenca je

opravljena z uporabo atributa file. Vrednost je lahko prebrana iz SCDL

konfiguracijske datoteke.

Lastnostni element vsebuje naslednje atribute:

• Name (obvezen) – ime lastnosti. Ujemati se mora z imenom lastnosti, definiranim

v implementaciji.

• Type (opcijski) – tip lastnosti, ki je definiran kot kvalificirano ime XML

shematičnega tipa.

• Element (opcijski) – tip lastnosti, ki je definiran kot kvalificirano ime XML

shematičnega globalnega tipa.

• Source (opcijski) – XPath izraz, ki pokaže pot do lastnosti trenutnega kompozita, iz

katerega je pridobljena vrednost komponentne lastnosti.

• File (opcijski) – dereferencirajoči URI do datoteke, ki vsebuje vrednost lastnosti.

• Many (opcijski) – lastnost ima bodisi eno (false) bodisi več (true) vrednosti.

Storitve in reference omogočajo komponenti komunikacijo z drugo programsko opremo.

Kako se zgodi ta komunikacija, nam odgovorijo vezave (angl. binding). Vezava natančno

specificira, kako naj se odvija komunikacija med elementi. Komponenta, ki komunicira z

drugo komponento v isti domeni, ne potrebuje specifikacije eksplicitnih vezav. Za

komunikacijo z zunanjo domeno (SCA aplikacija v drugi domeni ali aplikacija, ki ne

podpira SCA) je treba specificirati eno ali več vezav. Vsaka vezava definira določen

protokol, ki je uporabljen za komunikacijo s storitvijo ali referenco. Posamezna storitev ali

referenca lahko ima več vezav, kar pomeni, da različne programske opreme komunicirajo z

njo na različne načine.

SCA predstavlja poenostavljen pristop. Namesto zavijanje različnih protokolov v različnih

tehnologijah z različnimi API-ji SCA omogoča vsaki storitvi ali referenci specifikacijo

protokolov, ki jih podpira z uporabo vezave. Model programiranja, viden s strani

aplikacije, ostane nespremenjen ne glede na uporabljen protokol (10).



Primer prikaže Slika 2.7. SCA storitev je dostopna preko SOAP/HTTP, če uporablja

vezavo spletnih storitev (angl. Web Services binding) ali dostop preko protokola čakajočih

sporočil (angl. Queued Messaging Protocol), ki je omogočen z uporabo JMS vezave.

Podobno EJB vezava omogoča dostop do sejnih zrn z uporabo IIOP (angl. Internet Inter-

Orb Protocol). Možna je SCA vezava v času izvajanja SCA. SCA vezava je lahko

uporabljena v primeru, ko storitev in njen uporabnik tečeta v isto domeno. Uporabljen

protokol ni določen, a najpogosteje je uporabljen binarni protokol. V času izvajanja lahko

SCA izbere različne protokole v različnih stanjih, ki pripadajo SCA vezavi.

2.2.3 Kompozit

Če so komponente atomi SCA, potem so kompoziti molekule. Kompoziti grupirajo

komponente v uporabnih kombinacijah, ki so lahko tudi nadalje kombinirane (10). SCA

kompozit vsebuje množico komponent, storitev, referenc in vezav, ki jih povezuje, ter

množico lastnosti za konfiguracijo komponent.

JAX-WS

SOAP

JMS EJB RMI

IIOP Protokol čakajočih sporočil

Aplikacija

STORITVENO KOMPONENTNA ARHITEKTURA

IIOP SOAP Protokol čakajočih

sporočil


WS vezava JMS vezava EJB vezava SCA vezava

Binaren protokol

Binaren protokol

Slika 2.7 – Pogled SCA pristopa

Kompoziti lahko oblikujejo komponentne implementacije za višje nivojske kompozite

oziroma višji nivojski kompoziti lahko imajo komponente, ki so implementirane s strani

kompozitov. Vsebina kompozita je lahko uporabljena v drugem kompozitu preko

vključevanja (angl. inclusion). Kadar je kompozit vključen v drug kompozit, je vsa

njegova vsebina dostopna za uporabo v vključujočem kompozitu (11).

Kompozit je definiran v datoteki xxx.composite in je predstavljen s kompozitnim

elementom. Naslednja shema prikazuje XML shemo kompozitnega elementa:

Kompozitni element vsebuje naslednje atribute (11):

• Name (obvezen) – ime kompozita. Oblika imena je XML QName, definirana v

imenskim prostoru, določenem s targetNamespace atributom.

<?xml version="1.0" encoding="ASCII"?>  <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"

targetNamespace="xs:anyURI" name="xs:NCName" local="xs:boolean"? autowire="xs:boolean"? constrainingType="QName"? requires="list of xs:QName"? policySets="list of xs:QName"?>

<include name="xs:QName"/>* <service name="xs:NCName" promote="xs:anyURI"

requires="list of xs:QName"? policySets="list of xs:QName"?>* <interface/>? <binding uri="xs:anyURI"? name="xs:QName"?

requires="list of xs:QName"? policySets="list of xs:QName"?/>* <callback>?

<binding uri="xs:anyURI"? name="xs:QName"? requires="list of xs:QName"? policySets="list of xs:QName"?/>+

</callback> </service> <reference name="xs:NCName" target="list of xs:anyURI"?

promote="list of xs:anyURI" wiredByImpl="xs:boolean"? multiplicity="0..1 or 1..1 or 0..n or 1..n"? requires="list of xs:QName"? policySets="list of xs:QName"?>* <interface/>? <binding uri="xs:anyURI"? name="xs:QName"?

requires="list of xs:QName"? policySets="list of xs:QName"?/>* <callback>?

<binding uri="xs:anyURI"? name="xs:QName"? requires="list of xs:QName"? policySets="list of xs:QName"?/>+

</callback> </reference> <property name="xs:NCName" (type="xs:QName" | element="xs:QName")

many="xs:boolean"? mustSupply="xs:boolean"?>* default-property-value?

</property> <component name="xs:NCName" autowire="xs:boolean"? ... </component> <wire source="xs:anyURI" target="xs:anyURI" />*

</composite>

Shema 2.2 – XML shema kompozita



• TargetNamespace (opcijski) – identifikator za ciljni imenski prostor, v katerem je

kompozit deklariran.

• Local (opcijski) – določa, ali se bodo vse komponente kompozita izvajale v isti

proces operacijskega sistema. Vrednost true pomeni, da se morajo vse komponente

izvajati v isti proces. Vrednost false, ki je privzeta, pomeni da se različne

komponente kompozita lahko izvajajo v različnih procesih operacijskega sistema

ali celo v različnih vozliščih omrežja.

• Autowire (opcijski) – določa, ali bodo reference vsebujočih komponent samodejno

vezane. Privzeta vrednost je false.

• ConstrainingType (opcijski) – ime constrainingTypa. Ko je določen, so množica

storitev, referenc in lastnosti ter povezane namere omejene na množico, definirano

s constrainingTypom.

• Requires (opcijski) – seznam namer politike.

• PolicySets (opcijski) – seznam množic politik.

Kompozitne storitve vključujejo promocijo (angl. promotion) ene storitve ene komponente,

kar pomeni, da je kompozitna storitev ponujena s strani ene od kompozitnih komponent.

Kompozitne reference vključujejo promocijo ene ali več referenc ene ali več komponent.

Več komponentnih referenc je lahko promoviranih isti kompozitni referenci, če se

medsebojno usklajujejo. V tem primeru si vse komponentne reference delijo isto

konfiguracijo, vključno s ciljno storitvijo. Na spodnji sliki (Slika 2.8) je storitev A, ki je




D

E

A

STORITEV

REFERENCA

ŽICA

PROMOCIJA

A

D

E

Slika 2.8 – Model kompozita



implementirana s strani prve komponente, promovirana kot storitev kompozita. Podobno

sta referenci D in E promovirani na kompozitni ravni.

Kompozitne storitve in kompozitne reference lahko uporabijo konfiguracijo njihovih

promocijskih storitev in referenc. Alternativno lahko kompozitne storitve in kompozitne

reference prepišejo del ali celotno konfiguracijo promocijskih storitev in referenc s

pomočjo konfiguracije vezav kompozitnih storitev ali referenc.

Lastnosti omogočajo konfiguracijo implementacije z zunanjo množico podatkovnih

vrednosti. Vsaka implementacija lahko deklarira nič ali več lastnosti. Vsaka lastnost ima

tip, ki je enostaven ali kompleksen. Lastnostni element ima naslednje atribute (11):

• Name (obvezen) – ime lastnosti.

• Eden izmed (obvezen):

o type – tip lastnosti (kvalificirano ime XML shematičnega tipa),

o element – tip lastnosti, ki je definiran kot kvalificirano ime XML

shematičnega globalnega tipa.

• Many (opcijski) – lastnost ima bodisi eno (false) bodisi več (true) vrednosti.

Privzeto je false.

• MustSupply (opcijski) – določa, ali je vrednost lastnosti zagotovljena s strani

komponente, ki uporablja implementacijo. Pri vrednosti true mora komponenta

dobaviti vrednost, ker implementacija nima privzete vrednosti za lastnost. V

primeru falsa je dobavljen element default-property-value.

Reference kompozita so definirane s promoviranjem referenc, definiranih s strani

komponent, vsebovanih v kompozitu. Vsaka promovirana referenca kaže, da mora biti

komponentna referenca obravnavana s strani storitve zunaj kompozita. Komponentna

referenca je promovirana z uporabo kompozitnega referenčnega elementa. Vsak kompozit

lahko ima nič ali več referenčnih elementov. Referenčni element vsebuje enake atribute,

kot smo jih opisali pri komponentnem referenčnem elementu, in še dodatni atribut:

• Promote (obvezen) – identificira eno ali več promoviranih komponentnih referenc.

Vrednost je seznam vrednosti v obliki <component-name>/<reference-

name>, razdeljene s presledkom.



Kompozitna referenca opcijsko lahko določi interface, multiplicity, required intents in

bindings. Vse, kar ni določeno, je privzeto po promovirani komponentni referenci (11).

Storitve kompozita so definirane s promoviranjem storitev, definiranih s strani komponent,

vsebovanih v kompozitu. Komponentna storitev je promovirana s pomočjo kompozitnega

storitvenega elementa. Vsak kompozit lahko ima nič ali več storitvenih elementov.

Storitveni element vsebuje enake atribute, kot smo jih opisali pri komponentnem

storitvenem elementu, in še dodatni atribut:

• Promote (obvezen) – identificira promovirane storitve. Vrednost je v obliki

<component-name>/<service-name>.

SCA žice (angl. wires), znotraj kompozita, povežejo izvorne komponentne reference s

ciljnimi komponentnimi storitvami (11) (Slika 2.8). Žica predstavlja abstraktno

prezentacijo razmerja med referenco in storitvijo, ki izpolni zahteve te reference (10). Eden

od načinov definiranja žice je s konfiguracijo komponentnih referenc z uporabo njenega

ciljnega atributa (angl. wire-target-URI). Drug način je s pomočjo žičnega elementa (angl.

wire element), ki je otrok kompozitnega elementa. Kompozit lahko ima nič ali več žičnih

elementov. Žični element vsebuje naslednje atribute:

• source (obvezen) – poimenuje izvorno komponentno referenco

• target (obvezen) – poimenuje ciljno komponentno storitev

Žica lahko poveže izvor s ciljem samo v primeru, ko cilj implementira vmesnik, ki se

ujema z vmesnikom izvora. Izvor in cilj se ujemata, če (11):

• izvorni vmesnik in ciljni vmesnik morata biti bodisi oba oddaljena (angl. remotable)

ali oba lokalna

• operacije ciljnega vmesnika morajo biti enake ali podmnožica operacij izvornega

vmesnika

• kompatibilnost posamezne operacije mora biti enaka: ime operacije, vhodni tipi in

izhodni tipi

• vrstni red vhodnih in izhodnih tipov mora biti enak

• množica pričakovanih napak in izjem na izvoru mora biti enaka ali podmnožica

definiranih na cilju



• ostali določeni atributi obeh vmesnikov se morajo ujemati

Vsa razmerja v kompozitu so izražena v SCDL konfiguracijski datoteki (10).

Vezave (angl. bindings) so uporabljene s strani storitev in referenc. Reference uporabijo

vezave za opis dostopnega mehanizma, ki omogoča klic storitev. Storitve uporabijo vezave

za opis dostopnega mehanizma, ki ga uporabijo odjemalci za klic storitev.

SCA podpira uporabo različnih tipov vezav, kot je SCA service vezava, Web service (WS)

vezava, stateless session EJB vezava, EIS service vezava ipd. SCA izvajalno okolje mora

ponuditi podporo za SCA service vezavo in Web service vezavo.

Vezava je definirana z vezavnim elementom, ki je otroški element storitvenega ali

referenčnega elementa v kompozitu. Prvi kvalifikator elementa je vedno imenovan

»binding«, naslednji kvalifikator pa določa ustrezen tip vezave (binding.composite,

binding.ws, binding.ejb, binding.eis). Vezavni element ima naslednje atribute (11):

• Uri (opcijski) – ima naslednjo semantiko:

o za vezavo referenc, URI atribut definira ciljni URI reference; atribut je

opcijski za reference, definirane v kompozitih, ki so uporabljene kot

komponentne implementacije, ter obvezen za reference, definirane v

kompozitih, ki prispevajo k SCA domenam;

o za vezavo storitev, URI atribut definira URI, povezan s komponento, ki

omeji storitev na določeno SCA domeno; privzeta vrednost URI-ja je

vrednost name atributa vezave.

• Name (opcijski) – ime primerka vezave (QName). Atribut omogoča razlikovanje

med več vezavnimi elementi za isto storitev ali referenco. Privzeta vrednost atributa

je ime storitve ali reference.

• Requires (opcijski) – seznam zahtevanih namer politike.


SCA vezava je lahko uporabna za interakcijo med referencami in storitvami v isti SCA

domeni. Način implementacije tega tipa vezave ni definiran v specifikaciji in je lahko

izveden na različne načine v različnih SCA izvajalnih okoljih. Edina zahteva je, da morajo

biti implementirani zahtevani predpisi za SCA vezavo.



Storitev ali referenca brez določenega vezavnega elementa uporablja SCA vezavo. Če je

vmesnik storitve ali reference lokalni, potem je uporabljena lokalna različica SCA vezave.

Če je vmesnik storitve ali reference oddaljen, je uporabljena bodisi lokalna bodisi

oddaljena različica SCA vezave.

WS vezava omogoča definiranje objave storitve kot spletne storitve ter način proženja

spletne storitve preko reference. WS vezava je definirana na osnovi WSDL vezave, kar

pomeni, da WS vezava referencira obstoječo WSDL vezavo ali omogoča določitev dovolj

informacij za generacijo WSDL vezave. WS vezava lahko kaže na obstoječo WSDL

datoteko, ki določa podrobnosti o WSDL vezavi in portType shemi za ponujanje ali

proženje spletne storitve (12).

2.2.4 Implementacija komponente

Implementacija komponente je poslovna logika, napisana v enem izmed programskih

jezikov, kot so konvencionalni objektno orientirani in proceduralni jeziki Java, PHP, C++,

COBOL in C (Slika 2.9). Možna je implementacija z uporabo XML jezika, kot je BPEL, in

XSLT transformacij in deklarativnih jezikov, kot sta SQL in XQuery. Pomemben vidik

SCA je, da lahko uporabimo nam najustreznejši implementacijski tip – implementacija je v

službi poslovnemu procesu, in ne obratno.

2.2.4.1 Implementacijski tip Java

Implementacijski tip Java <implementation.java> ponuja implementacijo SCA

komponent, vključno z njihovimi storitvami, referencami in lastnostmi.

Komponenta A Komponenta B

Komponentni tip Implementacija

Primerki implementacije

konfigurira

Slika 2.9 – Razmerje med komponentami in implementacijo



Storitve, implementirane v Javi, lahko imajo vmesnike definirane na enega izmed

naslednjih načinov (13):

• vmesnik Java – komponenta implementira bodisi Java vmesnik bodisi vse operacije

vmesnika

• razred Java – storitev ni oddaljena (angl. remotable)

• vmesnik Java, generiran iz WSDL portTypa – storitev je oddaljena

Ker vsak vmesnik ne pomeni definicije storitev SCA, se uporablja beležka @Service, ki

indicira storitveno implementacijo in pripadajoče vmesniške definicije.

Storitev, definirana z vmesnikom ali razredom, lahko uporabi @Remotable za deklaracijo

semantike oddaljivih storitev (angl. remotable services). Če @Remotable ni deklariran,

potem je storitev lokalna.

Reference so pridobljene s pomočjo injekcije (angl. injection) ali s pomočjo

ComponentContext API. Kadar je to mogoče, ima prednost prvi način. Implementacija Java

eksplicitno specificira reference z uporabo beležke @Reference. Če @Reference beleži

javna ali zaščitena metoda setter, mora izvajalno okolje SCA ponuditi ustrezno

implementacijo reference, definirano s tipom parametra v metodi. Obseg implementacije

določa, kdaj se bo zgodila injekcija. Če @Reference beleži javno ali zaščiteno polje, mora

izvajalno okolje SCA ponuditi ustrezno implementacijo reference, definirano s tipom polja.

Obseg implementacije določa, kdaj se bo zgodila injekcija. Če @Reference beleži

parameter ali konstruktor, mora izvajalno okolje SCA ponuditi ustrezno implementacijo

reference, definirano s konstruktorskim parametrom med instanciranjem implementacije.

Lastnosti so pridobljene s pomočjo injekcije ali s pomočjo ComponentContext API. Kadar

je to je mogoče, ima prednost prvi način. Implementacija Java eksplicitno specificira

lastnost z uporabo beležke @Property. Če @Property beleži določen element

implementacije, mora izvajalno okolje SCA ponuditi ustrezno vrednost lastnosti. Obseg

implementacije določa, kdaj bo zgodila injekcija.

Implementacijski tip Java podpira naslednje obsege implementacije: STATELESS,

REQUEST, CONVERSATION in COMPOSITE. Implementacija specificira svoj obseg z

beležko @Scope. Privzeti obseg pa je STATELESS.



2.2.4.2 Implementacijski tip BPEL

Za implementacijo komponente SCA se lahko uporabi procesni jezik BPEL, definiran z

implementacijskim tipom <implementation.bpel>. Za opis poslovnega procesa v

BPEL definiramo novo spletno storitev (komponento), ki je kompozija obstoječih spletnih

storitev. Vmesnik nove storitve uporablja množico portnih tipov, preko katerih ponuja

operacije.

Običajno poslovni proces BPEL sprejme zahtevo. Da jo izpolni, proces proži vključene

storitve in odgovori klicalcu. Pri komunikaciji s storitvami proces uporablja WSDL opise

storitve. WSDL specificira relacije med storitvami v poslovnemu procesu. Relacije

imenujemo partnerske povezave (angl. partner links).

Proces BPEL je sestavljen iz aktivnosti, ki so lahko osnovne ali sestavljene. Osnovne

aktivnosti predstavljajo osnovne konstrukte (14):

• <invoke> za proženje spletnih storitev

• <receive> za sprejem zahteve, poslane v obliki sporočila s strani odjemalca

• <reply> za generiranje odgovora za sinhrone operacije

• <assign> za manipulacijo podatkovnih spremenljivk

• <throw> za indikacijo napak in izjem

• <wait> za čakanje

• <terminate> za končanje celotnega procesa

Z uporabo osnovnih aktivnosti lahko sestavimo kompleksne algoritme, ki natančno

definirajo korake poslovnega procesa. Za kombinacijo osnovnih aktivnosti BPEL podpira

strukturirane aktivnosti, med katere sodijo:

• <sequence> za definiranje množice aktivnosti, ki bodo prožene v urejeno

zaporedje

• <flow> za definiranje množice aktivnosti, ki bodo prožene vzporedno

• <switch> za implementacijo vejitev

• <while> za definiranje zank

• <pick> za definiranje možnosti za izbiro ene od številnih poti



Definicija poslovnega procesa je napisana v dokumentu XML. Korenski element je

element <process>. Znotraj elementa <process>, običajno na najvišjem nivoju, je

element <sequence>. Znotraj zaporedja bo proces najprej čakal na prihajajoče

sporočilo za začetek procesa (konstrukt <receive>). Nato bo proces prožil spletne

storitve s konstruktom <invoke>. Za zaporedno proženje storitev konstrukte <invoke>

zapišemo enega za drugim. Za vzporedno proženje storitev uporabimo konstrukt <flow>.

Shemi prikazujeta primer kode:

Za deklariranje partnerskih povezav BPEL uporablja <partnerLink>. Partnerske

povezave opišejo povezave do partnerjev, ki so lahko (14):

• storitve, sprožene s strani procesa

• storitve, ki prožijo proces

• storitve, ki imajo obe zgornji vlogi

Tip partnerske povezave (angl. partnerLinkType) deklarira, kako dve stranki komunicirata

in kaj ponuja vsaka stranka. Vsak tip mora imeti vsaj eno vlogo in največ dve vlogi. Za

vsako vlogo specificiramo portni tip (angl. portType), ki se uporablja pri interakciji. Tipi

partnerskih povezav so del dokumenta WSDL, ki opiše partnersko storitev ali proces

BPEL.

Za deklariranje spremenljivke BPEL uporablja <variable>. Spremenljivke shranijo

sporočila, ki so se izmenjala med procesnimi partnerji, ali shranijo podatke, ki opisujejo

stanje procesa. Pred uporabo je treba spremenljivko deklarirati. Spremenljivko deklariramo

<process ...> ...

<sequence>

<!—čakaj na zahtevo za začetek procesa--> <receive .../>

<!—sproži storitve vzporedno--> <flow> <invoke .../> <invoke .../> <invoke .../>

<flow> ...

</sequence> </process>

<process ...> ...

<sequence>

<!—čakaj na zahtevo za začetek procesa--> <receive .../>

<!—sproži storitve eno za drugo--> <invoke .../> <invoke .../> <invoke .../> ...

</sequence> </process>

Shema 2.3 – Zaporedno proženje storitev Shema 2.4 – Vzporedno proženje storitev



s specifikacijo njenega imena in tipa. Za specifikacijo tipa je treba določiti enega

naslednjih atributov:

• messageType: spemenljivka, ki shrani sporočilo WSDL

• element: spremenljivka, ki shrani shematični element XML

• type: spremenljivka, ki shrani shematični enostavni tip XML

Deklaracija spremenljivke je znotraj elementa <variables>.

Storitve in reference v SCA komunicirajo tudi na osnovi koncepta WS-BPEL partnerske

povezave (Slika 2.10). Zaradi tega je treba določiti, katero vlogo pošlje prvo sporočilo.

Enostavna statična analiza kontrolnega toka nam pomaga pri določitvi vloge (15).

Če statična analiza procesa določi, da bo prvo sporočilo partnerske povezave sprejeto v

aktivnosti <receive>, v elementu <onMessage> ali v elementu <onEvent>, potem

ima partnerska povezava storitev SCA v komponentnem tipu. Tip storitve je določen s

tipom partnerske povezave. Partnerska povezava specificira vlogo myRole, ki ponuja tip

storitve WSDL porta. Če ima partnerska povezava dve vlogi, potem partnerRole ponuja tip

WSDL porta vmesnika povratnega klica (angl. callback interface).

Če statična analiza procesa ne določi, da bo partnerska povezava imela storitev, potem je

partnerska povezava povezana z referenco SCA v komponentnem tipu. Partnerska

povezava specificira vlogo partnerRole, ki ponuja tip WSDL porta reference. Če ima

partnerska povezava dve vlogi, potem myRole ponuja tip WSDL porta vmesnika

povratnega klica.

storitev

A

referenca B

partnerLink A partnerLink B

receive

invoke

reply

WS-BPEL Proces

tok

Slika 2.10 – Komponenta SCA z implementacijo BPEL



2.2.5 Storitveni podatkovni objekt

Tako imenovani trikotnik resnice, prikazan na spodnji sliki (Slika 2.11), je enostaven način

pregleda pomembnih arhitekturnih konstruktov storitveno usmerjene arhitekture. Namreč,

potreben je način za predstavitev podatkov, ki si jih izmenjajo storitve, mehanizem za

proženje storitev ter način za kompozicijo storitev v veliki integrirani poslovni aplikaciji.

Dva konstrukta smo že obravnavali, in nam ostane še tretji konstrukt oziroma predstavitev

podatkov, ki ga obravnavamo v nadaljevanju.

Storitveni podatkovni objekt (angl. Service Data Object – SDO) je specifikacija11

SDO je ogrodje za podatkovni razvoj aplikacije, ki vključuje arhitekturo in API (17).

Ključne značilnosti takega ogrodja so:

modela

programiranja, ki unificira podatkovno programiranje v različne podatkovne vire, ponuja

robustno podporo za pogoste aplikacijske vzorce in omogoča aplikacijam, orodjem in

ogrodjem enostavnejše povpraševanje, pogled, vezavo, posodabljanje in preverjanje

podatkov (16).

• Poenoten dostop do heterogenih podatkovnih virov (Slika 2.12). Podatki, ki jih

uporabljajo aplikacije, pogosto prihajajo iz najrazličnejših virov, kot je relacijska

podatkovna baza, lastna podatkovna plast, spletne storitve, XML podatkovna

skladišča, JMS sporočila in EIS. Raznolikost tehnologij, modelov in API-jev pa

predstavlja resen izziv za razvijalce aplikacije (17). SDO omogoča predstavitev

11 Specifikacija je bila prvič predstavljena leta 2004 s strani IBM-a in BEA.

Slika 2.11 – Trikotnik resnice SOA



množic podatkov ne glede na tipe podatkovnih virov. Zagotavlja enostavnejši in

poenoten model programiranja za aplikacijskega programerja ter nove možnosti za

orodja in ogrodja za konsistentno delo s heterogenimi podatkovnimi viri.

• Poenotena podpora za statične in dinamične podatkovne API-je. Statični tipizirani

vmesniki nudijo enostaven programski model za programerje. SDO omogoča

statične podatkovne API-je za generiranje kod iz različnih metamodelov, kot so

sheme XML, sheme relacijskih podatkovnih baz, modeli UML (angl. Unified

Modeling Language) ipd. Ko statični vmesniki ne zadoščajo izvedbi, je treba

uporabiti dinamične netipizirane API-je. Uporaba takšnih API-jev je primerna, ko

so podatki definirani s strani izhoda povpraševanja v času njihovega transferja (npr.

XML povpraševanje proti XML viru).

• Podpora za orodja in ogrodja. Trenutne podatkovno-programske tehnologije ne

podpirajo orodij in ogrodij za različne tipe podatkovnih virov. Ogrodja se morajo

zanašati na poenoteno predstavitev podatkov, so generična za določene podatke in

zanje je bolj primerna uporaba dinamičnih API-jev ter morajo biti sposobni za

enostavno samopreverjanje (introspekcijo) podatkov.

• Podpora za prekinjene podatkovne modele. Veliko aplikacij ima prekinjen vzorec

za dostop do podatkov: aplikacija prebere množico podatkov, jo lokalno obdrži za

določen čas, manipulira s podatki in na koncu spremembe aplicira nazaj v

podatkovni vir. Kljub temu danes ni take tehnologije, ki ponuja prekinjen in

optimističen model, povezan z že omenjenimi značilnostmi (heterogen dostop,

enostavnost uporabe ipd.).

STRORITEV ZA DOSTOP DO PODATKOV

ODJEMALEC

XML DB

RDB

EJB

WS

JCA

SDO

Slika 2.12 – Heterogen dostop do podatkov



• Podpora za lastne plasti za dostop do podatkov na osnovi najpogostejših

načrtovalskih vzorcev. Vzorci se običajno uporabljajo, ko je treba izolirati

aplikacijo od fizičnih podatkovnih virov.

• Ločitev aplikacijske kode od kode podatkovnega dostopa.

Arhitektura SDO (Slika 2.13) temelji na konceptu prekinjenih podatkovnih vzorcev in

vključuje naslednje elemente (16):

• SDO jedro. Sestavljajo ga podatkovni objekti (angl. Data Objects), podatkovni grafi

(angl. Data Graphs) in metapodatki (angl. metadata).

• SDO storitve podatkovnega dostopa (angl. Data Access Services – DAS).

• SDO orodja, kot so generatorji kode, pretvorniki metamodelov, pretvorniki shem,

orodja za podatkovno modeliranje ipd.

• SDO izvajalna okolja in ogrodja, ki opravijo najrazličnejša opravila, kot je vezava

podatkov z UI komponentami.

V nadaljevanju obdelamo jedro SDO.

2.2.5.1 Podatkovni objekt

Podatkovni objekti predstavljajo poslovne podatke in jih držijo v lastnostih (angl.

properties) (18). Lastnosti lahko vključujejo primitivne vrednosti in reference na druge

podatkovne objekte. V primeru XML podatkovni objekt lahko predstavlja element, atribute

elementa, vrednosti enostavnih tipov otroških elementov ter reference na podatkovne

objekte, ki predstavljajo kompleksne tipe. V primeru relacijskih podatkov podatkovni

ODJEMALEC STORITEV ZA PODATKOVNI

DOSTOP

PODATKOVNI VIR

bere

sposodobi

Podatkovni objekt

Podatkovni graf

Metapodatki

Slika 2.13 – Komponente arhitekture SDO



objekt predstavlja eno vrstico podatkov. Tuji ključ bo predstavljen z referenco na drug

podatkovni objekt.

Vmesnik podatkovnega objekta ponuja dostop do poslovnih podatkov najpogostejših tipov

preko različnih dostopnih vzorcev. Za dostop do vrednosti lahko uporabimo ime lastnosti z

metodo get(String pot), z indeksom lastnosti ali direktno z objektom Property. Vrednosti v

DataObjektu nastavimo na podoben način z uporabo metode set(String pot), z indeksom ali

z objektom Property. Pot je lahko ime lastnosti ali izraz na osnovi XPath.

Za aplikacije, ki uporabljajo generirano kodo, se uporabijo generirani vmesniki, in ne

vmesniki podatkovnih objektov.

Podatkovni objekti podpirajo različne tipe povezav, kot so povezava 1 : 1, 1 : n in n : m.

Podatkovni objekt lahko upravlja s povezavami, med katere sodijo tudi inverzne povezave

(objekt A referencira objekt B in B ohrani inverzijo reference do A-ja; ko se povezava B iz

A-ja premakne v C se samodejno naredi povezava med A in C) (16).

Poslovni objekt (angl. business object) je temeljna podatkovna struktura za predstavitev

poslovnih podatkov v okolju IBM WebSphere Process Server in je direktno povezan s

podatkovnim objektom SDO. Poslovni objekti v IBM WebSphere Process Serverju so

predstavljeni v pomnilniku s SDO tipom commonj.sdo.DataObject. Obstajata dva tipa

poslovnih objektov: enostavni poslovni objekt, ki je sestavljen iz skalarnih lastnosti, ter

vsebovan (sestavljen) poslovni objekt, sestavljen iz atributov, ki referencirajo gnezdene

definicije poslovnih objektov. Za modeliranje oziroma definiranje poslovnih objektov se

uporablja shema XML (19).

2.2.5.2 Podatkovni graf

Podatkovni grafi predstavljajo množico podatkovnih objektov v obliki drevesnih struktur

(Slika 2.14). Podatkovni graf lahko obstaja sam zase ali pa je zavit z ovojnim objektom

DataGraph. Podatkovni graf, prikazan na spodnji sliki, vsebuje korenski podatkovni

objekt, ki neposredno ali posredno vsebuje vse ostale podatkovne objekte grafa. Če vsi

podatkovni objekti znotraj enega grafa referencirajo na podatkovne objekte znotraj istega

grafa, rečemo, da je podatkovni graf zaprt. Zaprtost je normalno stanje podatkovnih grafov

(18).



Podatkovni grafi so običajno enote, ki se prenašajo med komponentami. Pri tem

podatkovni grafi shranjujejo povzetke nastalih sprememb. Povzetek sprememb (angl.

Change Summary) je privzeto prazen in je napolnjen pri spremembi podatkovnega grafa.

Povzetek sprememb ponuja informacije o podatkovnih objektih, ki so bili dodani,

odstranjeni in posodobljeni.

Poslovni graf (angl. business graph) je koncept, povezan s podatkovnim grafom SDO. V

IBM WebSphere Process Serverju se poslovni graf uporablja za zavijanje poslovnih

objektov na najvišjem nivoju in ponuja pomembne sposobnosti, ki so povezane s hierarhijo

poslovnih objektov. Poslovni grafi se uporabijo v primeru prekinjenih modelov, ko je treba

zajemati spremembe, ki so nastale nad poslovnimi objekti pri komunikaciji med procesi.

Grafi se uporabijo tudi za podatkovno sinhronizacijo med različnimi EIS sistemi z uporabo

povzetka spremembe, povzetka dogodka (angl. event summary) in glagola (angl. verb).

Povzetek sprememb shrani spremembe nad poslovnimi objekti znotraj grafa. Prvi način je

eksplicitno posodabljanje sprememb tako, da se začne beleženje sprememb preko

vmesnika commonj.sdo.ChangeSummary. Drugi način spremljanja sprememb je

ekspliciten. Pri tem se uporablja poslovna objektna storitev (angl. business object service)

za direktno posodabljanje sprememb, ker pomeni dodatno funkcionalnost, ki je SDO ne

ponuja.

Glagol sporoča tip dogodka v času podatkovne sinhronizacije med EIS sistemi. Obstaja 5

standardnih glagolov, ki se uporabijo za poslovne grafe: create, update, delete,

POVZETEK SPREMEMB

KORENSKI OBJEKT

PODATKOVNI GRAF

...

...

...

Slika 2.14 – SDO podatkovni graf

34 | S t r a n 2.3 Vodenje SOA


updatewithdelete in retrieve. Povzetek dogodkov vsebuje nestandardne glagole za vsak

objekt v poslovnem grafu skupaj z enoličnim identifikatorjem (ObjectEventId) (19).

2.2.5.3 Metapodatki

Podatki so lahko opisani na različnih nivojih kot primerek podatkov, metapodatki

(podatkovna shema) in metamodel (model metapodatkov). SDO ponuja majhen

metapodatkovni API oziroma tanek metamodel. Metamodel ni celovit kot XML shema ali

SQL relacijskega modela, ampak ponuja odjemalcu esencialni pregled nad metapodatki.

Pomen tega je normalizirano samopreverjanje podatkov (16).

2.3 Vodenje SOA

Razdelek je namenjen kratki predstavitvi vodenja SOA (angl. SOA governance). Na

splošno vodenje predstavlja način vzpostavljanja in izvajanja skupnega delovanja.

Natančneje je vodenje vzpostavitev verige odgovornosti, meritev za merjenje

učinkovitosti, politike za vodenje organizacije k izpolnjevanju ciljev, kontrolnih

mehanizmov za zagotavljanje skladnosti in komunikacije za lažje obveščanje vseh

vključenih strani.

Vodenje določa, kdo je odgovoren za odločanje, katere odločitve je treba narediti in katere

politike so potrebne za dosledno odločanje. Vodenje se razlikuje od upravljanja, kajti

upravljanje predstavlja proces odločanja in implementacije, in ne načrtovanja potrebnih

odločitev (20).

Vodenje SOA je specializacija IT vodenja tako, da se ključne odločitve IT vodenja

odražajo na življenjskem ciklu storitvenih komponent, storitev in poslovnih procesov.

Vodenje SOA vodi razvoj ponovno uporabnih storitev, vzpostavlja način načrtovanja in

razvoja teh storitev ter način spreminjanja storitev. Vodenje vzpostavi sporazume med

ponudniki in odjemalci storitve, ki določajo, kaj naj odjemalci pričakujejo in kaj so

ponudniki dolžni zagotoviti.

Vodenje SOA ima več aspektov, ki jih naštevamo, a ne obravnavamo v podrobnosti (20):

• definicija storitve (obseg, vmesnik in meje storitve)

• življenjski cikel razporeditve storitve (stopnje življenjskega cikla)

2.3 Vodenje SOA S t r a n | 35


• storitvene različice

• migracija storitev (zaradi nasprotovanja)

• registri storitve (odvisnosti)

• storitveno sporočilni model (kanonični podatkovni modeli)

• spremljanje storitev (določanje problemov)

• lastništvo storitev (organizacija podjetja)

• testiranje storitev

• varnost storitev

IBM definira življenjski cikel vodenja SOA kot štirifazni proces (Slika 2.15). Prva faza

predstavlja načrtovanje, kjer se vzpostavi potrebo po vodenju in se ovrednotijo obstoječi

mehanizmi. Naslednja je faza definiranja, kjer se vzpostavi zaželjeno ogrodje vodenja,

vključno z novimi in spremenjenimi principi, procesi, organizacijskimi strukturami in

vlogami. V fazi omogočanja je vodstveno ogrodje predstavljeno znotraj podjetja. Zadnja

faza je merjenje, kjer se zbirajo meritve in analizirajo z namenom izboljšati proces vodenja

(21).

Načrtovanje Definiranje Omogočanje Merjenje

Razumeti trenutno strukturo vodenja

Ustvariti osnovno stanje IT vodenja

Definirati obseg vodenja

Izvesti anketo spremembe in pripravljenosti

Definirati in izpopolniti procese vodenja

Definirati organizacijske spremembe

Definirati IT spremembe v SOA razvoju

Implementirati prehodni načrt

Vpeljati SOA organizacijske spremembe

Zagon SOA centra odličnosti

Implementirati SOA infrastukturo

Meriti učinkovitosti procesov vodenja

Meriti učinkovitosti organizacijskih sprememb

Pregledati in izpopolniti operativno okolje

Definirati obseg vodenja: poslovno, razvojno vodenje, upravljanje storitev ali vse zgoraj navedeno

Definirati nove procese vodenja za storitve in SOA mehanizme vodenja

Začeti implementacijo SOA centra odličnosti, izboljšanje spretnosti, operacijske in infrastrukturne spremembe ipd.

Spremljanje izvedljivosti in prilagoditve kompozitne aplikacije; spremljanje učinkovitosti sprememb vodenja

Neprekinjen proces merjenja in izboljšanja

Določiti fokus vodenja Definirati model SOA vodenja

Implementirati model SOA vodenja

Izpopolniti model SOA vodenja

Slika 2.15 – IBM-ov življenski cikel SOA vodenja

36 | S t r a n 2.3 Vodenje SOA


The Open Group12

Ponujeno je ogrodje vodenja SOA, ki omogoča organizacijam definiranje in razporejanje

lastno fokusiranega in prilagojenega modela vodenja SOA. Ogrodje je sestavljeno iz

referenčnega modela vodenja SOA (angl. SOA Governance Reference Model – SGRM), kot

izhodišče in metoda vitalnosti vodenja SOA (angl. SOA Governance Vitality Method –

SGVM), kot proces, ki definira fokusiran in prilagojen režim vodenja SOA s pomočjo

podajanja povratnih informacij (22).

pravi, da vodenje SOA razširja IT in EA (angl. Enterprise Architecture)

vodenje in pri tem zagotavlja izpolnjevanje koristi, ki jih SOA predpisuje. To zahteva

vodenje ne samo vidikov izvajanja SOA, ampak tudi strateško načrtovalske aktivnosti.

SGVM je neprekinjena zanka izboljševanja, kjer se meri napredek in se po potrebi izvedejo

popravki ter posodabljanje. SGVM je primerljiv z zgoraj opisano IBM-ovo metodo

vodenja SOA.

Ko postaja SOA vse bolj razširjena, se poslovni in IT nosilci odločanja soočijo z dejstvom,

da so potrebne bolj robustne poslovne in IT zmogljivosti vodenja za usklajeno odločanje v

različnih podjetjih in z različnimi tehnologijami. To predstavlja poslovno vrednost vodenja

SOA – naredi SOA obljube in koristi realnost.

12 The Open Group je industrijski konzorcij, ki postavlja ponudniško in tehnološko nevtralne odprte standarde za računalniško infrastrukturo.

3 RAČUNALNIŠTVO V OBLAKU S t r a n | 37


3 3 RAČUNALNIŠTVO V OBLAKU

Računalništvo je transformirano v model, sestavljen iz storitev, ki so komodificirane13

Računalništvo v oblaku ima potencial transformirati velik del IT industrije tako, da napravi

programsko opremo bolj atraktivno kot storitev ter da oblikuje način zasnovanja in

nakupovanja IT strojne opreme. Razvijalci z inovativnimi idejami za nove storitve ne

zahtevajo več velikih kapitalnih izdatkov v strojni opremi za razporeditev te storitve ali

stroškov od človeških virov za njihovo upravljanje. Ni jim treba skrbeti o prekomerni

dobavitvi dragih sredstev za storitve, katerih popularnost ni izpolnila napovedi, in ne o

premali dobavitvi sredstev za storitve, ki so postale zelo popularne. Poleg tega lahko

podjetja z velikimi serijsko orientiranimi opravili dobijo povratne rezultate tako hitro, kot

njihovi programi zmorejo, kajti uporaba 1000 strežnikov za eno uro ne stane več kot

uporaba enega strežnika za 1000 ur. Ta elastičnost virov, brez plačila premije za velike

obsege, predstavlja primer brez precedensa v zgodovini IT-ja.

in

dobavljene podobno kot tradicionalne storitve – voda, elektrika, plin in telefonija. V

takšnem modelu uporabniki dostopajo do storitev ne glede na lokacijo, kjer te storitve

gostujejo, ali na način, kako so dobavljene. Nekaj računalniških paradigem je obetalo

izpolnitev te vizije storitvenega računalništva (angl. utility computing); mednje sodijo

računalništvo v gruči (angl. cluster computing), mrežno računalništvo (angl. grid

computing) in, v zadnjem času, računalništvo v oblaku (angl. cloud computing – CC).

13 Komodifikacija predstavlja transformiranje blaga in storitev v potrošno dobrino.

38 | S t r a n 3.1 Temelji računalništva v oblaku


V nadaljevanju je predstavljena osnova in temelji računalništva v oblaku. Podajamo

različne definicije in poskušamo umestiti pojem računalništvo v oblaku. Opišemo

komponente, ki sestavljajo oblačno arhitekturo, ter storitve, ki so neizogibni del vsake

oblačne infrastrukture. Poseben poudarek namenimo programski opremi kot storitvi. Na

koncu poskušamo objektivno identificirati ovire in priložnosti računalniškega oblaka.

3.1 Temelji računalništva v oblaku

Storitveno računalništvo ni nova ideja. Njegova popularnost se poveča z razširjanjem

modela v paradigmo računalništva v oblaku tako, da so ponujeni virtualni strežniki, do

katerih lahko dostopamo na zahtevo. Na začetku je bilo storitveno računalništvo

uporabljano zgolj za nekritične potrebe, danes pa se to hitro spreminja z reševanjem zadev

glede zaupnosti in zanesljivosti.

O računalništvu v oblaku se je govorilo, blogiralo, pisalo in je bilo predstavljeno na

različnih delavnicah, konferencah in v revijah. Kljub temu ostaja zmedenost o tem, kaj

natančno predstavlja in kdaj je uporabno. Za olajšano razumevanje računalništvo v oblaku

primerjamo z dvema znanima računalniškima paradigmama: računalništvo v gruči in

mrežno računalništvo. Poglejmo si najprej posamezne definicije. Pfistrova definicija pravi,

da je »gruča tip vzporednih in distribuiranih sistemov, ki je sestavljen iz množice

medsebojno povezanih samostojnih računalnikov, ki funkcionirajo kot enointegriran

računalniški vir«. Upoštevamo tudi Buyjevo definicijo o mrežah, ki pravi, da je »mreža tip

vzporednega in distribuiranega sistema, ki omogoča dinamično deljenje, izbiranje in

združevanje geografsko distribuiranih 'avtonomnih' virov v izvajalnem času v odvisnosti

od njihove razpoložljivosti, sposobnosti, izvedljivosti, cene in uporabnikovih kakovostnih

zahtev«. Obstajajo različne definicije, ki opisujejo računalništvo v oblaku. Ena izmed njih

pravi, da je »oblak tip vzporednega in distribuiranega sistema, sestavljen iz množice

medsebojno povezanih in virtualiziranih računalnikov, ki so dinamično rezervirani in

predstavljeni kot eden ali več poenotenih računalniških virov na osnovi pogodb, sklenjenih

s pogajanjem med ponudnikom storitve in uporabniki« (23).

3.1Temelji računalništva v oblaku S t r a n | 39


Na prvi pogled oblak predstavlja kombinacijo med gručami in mrežami. Kljub temu gre za

novo generacijo podatkovnih centrov z virtualiziranimi vozlišči preko virtualizacijske

tehnologije, dinamično rezerviranih na zahtevo kot personalizirana množica virov s

pomočjo pogajanja in dostopnih preko tehnologije spletnih storitev, kot sta SOAP in

REST. Oblačne platforme imajo lastnosti gruče in mreže s svojimi specialnimi atributi in

sposobnostmi. Naslednja preglednica prikaže razlike in podobnosti:

Preglednica 3.1 – Lastnosti gruče, mreže in oblaka

Lastnost Sistem Gruče Mreže Oblaki Populacija proizvodni (angl.

commodity computer) računalniki

hitri računalniki (strežniki, gruče)

proizvodni in hitri računalniki ter omrežno priloženo skladišče

Velikost/skalabilnost 100 razporejevalnikov

1000 razporejevalnikov od 100 do 1000 razporejevalnikov

Lastništvo eno več eno Operacijski sistem vsak standarden OS14 vsak standarden OS

(dominaten Linux)

(Linux, Windows) virtualizacija, na kateri teče več OS

Medomrežna povezava|hitrost

namenska, hitra, z nizko latenco in visoko pasovno širino

pretežno internet z visoko latenco in nizko pasovno širino

namenska, hitra z nizko latenco in visoko pasovno širino

Varnost/zasebnost Tradicionalno – prijava/geslo. Srednji nivo zasebnosti – odvisno od uporabniških privilegijev.

Avtentikacija s parom javnega/privatnega ključa. Uporabnik ima svoj račun. Omejena podpora zasebnosti.

Vsak uporabnik/aplikacija ima virtualni stroj. Zagarantirana je visoka varnost/zasebnost. Podpora za nastavitev dostopno- kontrolnega seznama (angl. Access Control List – ACL).

Odkritje članstvo storitve centralizirano indeksiranje in decentralizirane info storitve

članstvo storitve

Storitveno pogajanje omejeno da, na osnovi SLA15 da, na osnovi SLA Upravljanje uporabnikov

centralizirano decentralizirano in tudi virtualno organizirano

centralizirano ali delegirano tretji stranki

Upravljanje virov centralizirano distribuirano centralizirano/distribuirano Dodeljevanje/razporejanje

centralizirano decentralizirano centralizirano in decentralizirano

Standardi/interoperabilnost

na osnovi VIA (angl. Virtual Interface Architecture)

nekateri odprtomrežni standardi

spletne storitve (SOAP, REST)

Edina sistemska slika da ne da, opcijsko Kapaciteta stabilna in

zagarantirana spremenljiva, vendar visoka

rezervirana na zahtevo

Upravljanje odpovedi (samookrevanje)

omejeno (odpoveda-na opravila/aplikacije so pogosto ponovno začeta)

omejeno (odpovedana opravila/aplikacije pogosto so ponovno začeta)

Močna podpora za odpove-di in vsebinsko podvoje-vanje. VM (angl. Virtual Machine) lahko migrira iz enega vozlišča v drugo.

Cenitev storitev omejena, ni odprt prevladana z javnimi cenitev po uporabi, znižanje

14 OS – operacijski sistem (angl. Operating System). 15 SLA – sporazum o ravni storitve (angl. Service-Level Agreement).



market blagami ali privatno namenjena

za velike stranke

Medomreženje več gruč znotraj organizacije

omejen sprejem visok potencial, ponudniki lahko šibko povežejo storitve iz različnih oblakov

Aplikacijski gonilniki znanstveno, poslov-no, podjetniško raču-nalništvo, podatkovni centri

skupne znanstvene in visoko prepustne računalniške aplikacije

dinamična rezervacija zapu-ščinske in spletne aplikacije, dostava vsebin

Potencial za gradnjo tretje stranske ali vrednostno dodane rešitve

omejen zaradi toge arhitekture

omejen zaradi močne orientacije znanstvenega računalništva

visok potencial – lahko u-stvari nove storitve z dina-mičnim rezerviranjem raču-nanja, skladišča in aplikacij-skih storitev ter jih ponuja kot svoje lastne ali oblačno kompozitne storitve

Nekateri pravijo, da je računalništvo v oblaku »nov tip storitvenega računalništva, ki v

osnovi uporablja virtualne strežnike, ki so na razpolago tretji stranki preko interneta« (24).

Drugi podpirajo definicijo, da je CC »model, ki podpira idejo plačaj za uporabo (angl. pay-

per-use) in omogoča razpoložljiv in priročen dostop na zahtevo do porazdeljenih

konfiguracijskih računalniških virov, ki se hitro rezervirajo in sprostijo z minimalnim

upravljalnim trudom ali ponudnikovo interakcijo« (25).

Mi zagovarjamo idejo, da se računalništvo v oblaku nanaša na oboje, aplikacije,

dobavljene kot storitve preko interneta, ter strojno in sistemsko programsko opremo v

podatkovnih centrih, ki ponujajo te storitve. Strojni in programski opremi v podatkovnem

centru rečemo oblak (26).

Ko je oblak javno razpoložljiv v smislu »plačaj dokler uporabljaš«, ga imenujemo javni

oblak (angl. public cloud). Storitev, ki je prodana, je storitveno računalništvo. Pojem

privatni oblak (angl. private cloud) uporabljamo za podatkovne centre znotraj poslovne ali

druge organizacije, ki niso razpoložljivi javnosti.

V nadaljevanju opisujemo infrastrukturo oblaka.

3.1.1 Infrastruktura oblaka

Kot smo že omenili, je oblak sestavljen iz strojne in programske opreme. Slika 3.1 prikaže

vloge ljudi kot uporabnikov ali ponudnikov ustreznih plasti CC. Aplikacije, ponujene na

zahtevo kot storitve, se nanašajo na pojem programska oprema kot storitev (angl. Software



as a Service – SaaS). Prednosti SaaS-a za končne uporabnike in ponudnike storitve so

precej razumljive. Ponudniki storitve uživajo poenostavljeno nameščanje in vzdrževanje

programskih oprem in centraliziran nadzor rezerviranja. Končni uporabniki lahko

dostopajo do storitve kadarkoli in kjerkoli, sodelujejo enostavnejše, porazdelijo podatke in

jih varnostno hranijo v infrastrukturi. Računalništvo v oblaku omogoča ponudnikom

storitve več izbir glede razporejanja njihovih produktov kot SaaS brez rezervacije

podatkovnega centra. SaaS omogoča uporabniku reševanje problemov tako, da jih

posreduje ponudniku SaaS. Podobno se ponudnik SaaS lahko reši problemov tako, da jih

posreduje ponudniku oblaka. SaaS je podrobno opisan v naslednjem podpoglavju.

V praksi ponudniki oblačne storitve ponudijo storitve, ki jih združijo v treh kategorijah:

programska oprema kot storitev, platforma kot storitev (angl. Platform as a Service – PaaS)

in infrastruktura kot storitev (angl. Infrastrukture as a Service – IaaS). Te kategorije

dejansko grupirajo strojno in programsko opremo z določenim prekrivanjem. Čeprav

terminologija »x kot storitev (XaaS)« v znanstvenih okoljih ni najljubša (27) (26), na

kratko opišemo PaaS in IaaS.

V nekaterih literaturah je prisoten pojem platforma kot storitev kot plast programske

opreme, ki jo ponuja kot storitev za gradnjo višjenivojske storitve (27). Model PaaS

zagotavlja podporo za celoten življenjski cikel gradnje in dobave spletne aplikacije in

storitve preko spleta, brez prenašanja ali nameščanja programske opreme. Model razvoja je

hiter in cenovno učinkovit. Razvijalci PaaS-a se ukvarjajo le s spletnim razvojem, in ne z

uporabljenim OS. PaaS naj bi zagotavljal, da se uporabniki ukvarjajo z inovacijo, in ne s

kompleksno infrastrukturo (24).

Ponudnik oblaka

Ponudnik SaaS/ Uporabnik oblaka

Uporabnik SaaS

Spletne aplikacije

Storitveno računalništvo

Slika 3.1 – Uporabniki in ponudniki računalništva v oblaku



Model vključuje storitve za razvoj, testiranje, razporejanje, gostovanje in upravljanje

aplikacij (Slika 3.2). Orodje za kreiranje spletnega uporabniškega vmesnika ponuja

podporo za poenostavljeno ustvarjanje uporabniških vmesnikov (na osnovi HTML-ja,

JavaScripta ipd.). PaaS podpira večnajemniško arhitekturo (angl. multitenancy), kar

pomeni, da en primerek programske opreme teče na strežnik in streže več odjemalskim

organizacijam. Ponudniki PaaS vključijo storitve za upravljanje, skalabilnost, avtomatsko

preprečevanje sistemskih odpovedi (angl. failover) in varnost. Omogočena je integracija s

spletnimi storitvami z uporabo SOAP in podatkovnimi bazami.

Wikipedia pravi, da je infrastruktura kot storitev dostava računalniške infrastrukture,

običajno platformsko virtualizirano okolje, kot storitev (28). Povedano z drugimi

besedami, uporabljamo stroje ponudnika oblaka. Poleg tega IaaS vključuje vodenje,

aplikacijski razvoj, procesiranje aplikacije, varnost ipd. Vse, kar lahko najdemo v

tradicionalnih podatkovnih centrih, je lahko dobavljeno kot IaaS. Kljub temu je IaaS

osredotočen na model dobavljanja storitev – standardizirana infrastruktura, ustrezno

optimizirana za odjemalske aplikacije. Omogoča dostop do dragih virov preko sporazuma

Force.com je platforma kot storitev, ponujena s strani salesforce.com. Razvijalcem omogoča gradnjo

večnajemniških aplikacij, ki gostujejo na njihovih strežnikih kot storitev. Po poročilu Gartner Group iz

septembra 2009 ima Force.com več kot 1000 računov in še več deset tisoč strank, ki uporabljajo

Force.com v povezavi s salesforce.com. Platforma Force.com teče čez 8 podatkovnih centrov, vsaka

stranka pa uporablja en sam podatkovni center, ki je repliciran zaradi razpoložljivosti.

STORITVE

APLIKACIJE

VMESNA OPREMA

OPERACIJSKI SISTEM

VIRTUALNI STREŽNIKI

FIZIČNI STREŽNIKI

Spletne storitve

Flickr API Google Maps API

Spletne aplikacije

Google Apps Salesforce.com

Virtualno gostovanje. Uporaba rekonfiguriranega stroja ali lastnega programskega sklada

Najem rekonfiguriranega OS. Dodamo svoje lastne aplikacije

Najem virtualnega strežnika. Namestitev VM slike ali svojega lastnega programskega sklada

Najem izračunske mreže

HPC aplikacije

DNS server

PRO

GRAM

SKA&

STRO

JNA

OPR

EMA

INFRASTRU

KTURA O

BLAKA

Slika 3.2 – Infrastruktura oblaka



o ravni storitve (angl. Service-Level Agreement – SLA), kar pomeni prihranek kapitala

podjetja.

Ponudnik IaaS običajno ponudi naslednje komponente (24):

• računalniška strojna oprema (običajno kot mreža za masivno horizontalno

skalabilnost)

• računalniško omrežje (usmerjevalniki, požarni zidovi ipd.)

• internetna povezava

• platformsko virtualizacijsko okolje za odjemalske virtualne stroje

• SLA

• storitveno računalniško zaračunavanje

Naslednja preglednica prikaže primerjavo ponudnikov računalništva v oblaku z njihovimi

ponudbami za virtualizirane vire, zagotavljanje skalabilnosti in razpoložljivosti teh virov

(26):

Preglednica 3.2 – Ponudniki računalništva v oblaku

Amazon Web Services Microsoft Azure Google AppEngine Model računanja (angl.

computation model)

- x86 ISA (Instruction Set Architecture) preko Xen VM - elastičnost računanja omo-goča skalabilnost, razvijalec pa mora zgraditi stroje

- Microsoft Common Language Runtime VM - skupna vmesna oblika, izvedena v upravljanem okolju - stroji so rezervirani na osnovi deklarativnega opisa; avtomatsko izenačevanje obremenitev

- vnaprej definirana aplika-cijska struktura in ogrodje; programerji dobijo »uprav-ljalce (angl. handlers)« na-pisane v Python; vse trajno stanje je shranjeno v MegaStore - avtomatska skalabilnost računanja in skladiščenja; dosleden s trinivojsko apli-kacijsko strukturo

Model skladiščenja (storage model)

- razpon modelov – od bločne shrambe (ESB) do nadgrajenih ključev/blob shramb (SimpleDB) - avtomatska skalabilnost vari-ira od brezskalabilnosti (ESB) do celotne avtomatske (SimpleDb,S3) - doslednost jamstva je odvis-na od uporabljenega modela - API variira od standardnega (ESB) do lastnega

- SQL Data Services - Azure Storage Service

- MegaStore/BigTable

Model omreženja (networking model)

- deklarativna specifikacija topologije na nivoju IP - Security Groups omogočajo omejevanje uporabe komuni-kacijskih vozlišč

- avtomatski na osnovi deklarativnih opisov aplikacijskih komponent s strani programerja

- fiksna topologija za u-mestitev 3-nivojske apli-kacijske strukture - skalabilnost je avtomatska in nevidna za



- elastični IP naslovi ponujajo trajno usmerjevalno omrežno ime

programerja

Z vidika strojne opreme so v CC trije novi aspekti (26):

• iluzija neskončnih računalniških virov, ki so razpoložljivi na zahtevo, s čimer se

odpravi potreba uporabnikov oblaka po vnaprejšnjem načrtovanju rezervacij

• odprava vnaprejšnjih obveznosti uporabnikov oblaka, kar omogoča podjetjem

začetek z malimi sredstvi in povečanje strojnih virov samo, kadar se poveča

potreba po njih

• možnost za plačilo uporabe računalniških virov na kratkoročni osnovi po potrebi

(npr. procesorji na uro, skladišče na dan) in njihovo sprostitev po potrebi, pri čemer

je ponujeno ohranjanje z odstranjevanjem strojev in skladišč, ko niso več uporabni

3.1.2 Virtualizacija

Računalništvo v oblaku poveča nivo abstrakcije tako, da so vse komponente abstrahirane

oziroma virtualizirane in se lahko uporabljajo za hitrejše sestavljanje višjenivojskih

aplikacij ali platform. Če komponenta svojem odjemalcem ne zagotavlja dosledne in trajne

abstrakcijske plasti, ni primerna za računalništvo v oblaku.

Virtualizacija je način vodenja več neodvisnih navideznih operacijskih sistemov na enem

fizičnem računalniku (29). Virtualizacija, kot prikaže Slika 3.3, je način doseganja večje

gostote strežnikov. Ta pristop maksimizira vrnitev investicij za računalnik in zmanjša

nabavo velikega števila strojnih oprem ter tudi vzdrževalne stroške.

Veltejeva in Elsenpeter navajata dva tipa virtualizacije. Prvi tip je popolna virtualizacija

(angl. full virtualization), kjer se vsa programska oprema izvaja na virtualnem stroju. Poleg

Slika 3.3 – Virtualizacija



različnih aplikacij popolna virtualizacija podpira tudi namestitev različnih operacijskih

sistemov. Uspešnost popolne virtualizacije je zagotovljena zaradi porazdeljevanja

računalniškega sistema med več uporabnikov, medsebojnega izoliranja uporabnikov in

posnemanja strojne opreme na drugem stroju.

Drugi tip virtualizacije predstavlja paravirtualizacija (angl. paravirtualization), ki

omogoča istočasno izvajanje več operacijskih sistemov na eni strojni opremi z bolj

učinkovito uporabo sistemskih virov. Pri paravirtualizaciji upravljalni modul operira z

operacijskim sistemom, ki teče na virtualnem stroju. Paravirtualizacija je običajno boljša,

ker ni treba virtualizirati vseh elementov (BIOS, pogon ipd.). Paravirtualizacija je tudi bolj

fleksibilna. Na primer, če popolna virtualizacija zahteva 10% izkoriščanje procesorja za

vsak gostiteljski primerek, potem se lahko izvaja največ 5 sistemov (50 %). Nasprotno pa

paravirtualizacija zahteva 2% izkoriščanje procesorja za vsakega gostitelja in omogoča

izvajanje 8 sistemov.

Paravirtualizacija je najbolj primerna pri okrevanju sistema po izpadu, migraciji k novemu

sistemu in upravljanju kapacitete (30).

Pojem virtualizacija se lahko sklicuje na pojem virtualni stroj (angl. Virtual Machine –

VM). Virtualni stroji so postali prevladujoč način abstrakcije, ker predstavljajo najmanjši

skupni vmesnik med ponudniki storitve in razvijalci. Uporabljanje virtualnih strojev kot

razvojnih objektov je zadostno za 80 % uporabe, kar pomaga pri zadovoljevanju potreb po

hitri dobavi aplikacij. Virtualni stroj, ki vključuje programsko opremo, ki je delno ali

celotno konfigurirana za izvedbo specifičnih opravil, imenujemo virtualni aparat (angl.

virtual appliance). Virtualni aparat izboljša možnosti hitrejšega ustvarjanja in dobavljanja

aplikacije. Kombinacija virtualnih strojev in aparatov kot standardnih dobavnih objektov

predstavlja ključno lastnost računalništva v oblaku (27).

V računalništvu v oblaku je pomembno vzdrževanje modela ustvarjanja slik virtualnih

strojev, ker so slike zgrajene na osnovi modela. Slike virtualnih strojev se bodo ves čas

spreminjale zaradi potreb po popravljanju, posodabljanju in rekonfiguriranju programskih

oprem. Nespremenljiv ostane proces ustvarjanja slik virtualnih strojev.

Uporaba standardov in standardne konfiguracije zmanjša vzdrževalne in namestitvene

stroške. Standardi lahko vključujejo (27) (31):



• tipe virtualnih strojev. Treba je upoštevati vpliv virtualnega stroja na aplikacijo, ki

jo bo podpiral. Za aplikacije socialnih mrež, kjer je potrebna varnostna izolacija in

visokonivojska abstrakcija, se predlaga uporaba virtualnih strojev tipa II (goščen,

angl. hosted VM). Za računsko in vizualizacijsko zahtevne aplikacije, kjer je

potreben direkten dostop do strojne opreme za doseganje izredne zmogljivosti, se

predlaga uporaba virtualnih strojev tipa I (domoroden, angl. native VM).

• rekonfigurirane operacijske sisteme. Programska oprema na virtualnem stroju mora

biti vzdrževana enako kot na fizičnem strežniku. Mala in standardna množica

podprtih konfiguracij bo razvijalcem omogočila uporabo trenutno podprtega

virtualnega stroja. Pri posodabljanju podprtih konfiguracij je potreben model

prilagajanja, ki bo na novem virtualnem stroju omogočil enostavno vnašanje

sprememb.

• orodja in jezike. Velika podjetja lahko standardizirajo uporabo programskega jezika

Java in Ruby; mala podjetja lahko standardizirajo PHP kot prioritetno orodje za

gradnjo aplikacije. Ko so ti standardi dovolj zreli za računalništvo v oblaku,

oblikujejo naslednji nivo – platformo kot storitev.

Hitra prilagoditev virtualizacije je prinesla potrebo po standardnem načinu pakiranja in

distribucije virtualnih strojev. V ta namen je nastal standard Open Virtualization Format16

OVF formatirani virtualni stroji imajo naslednje lastnosti in prednosti (32):

(OVF), ki poenostavi interoperabilnost, varnost in upravljanje življenjskega cikla VM s

predpisom odprtega, varnega, prenosnega, učinkovitega in razširljivega formata za

pakiranje in distribuiranje virtualnih strojev (24). OVF omogoča učinkovito, fleksibilno in

varno distribuiranje programske opreme, olajša prenosljivost virtualnih strojev in ponuja

odjemalcem platformsko in ponudniško neodvisnost. Uporabniki lahko namestijo OVF

formatiran virtualni stroj na virtualno platformo po lastni izbiri.

16 Specifikacija OVF V1.0.0 je bila izdana v septembru 2008 s strani Dell, HP, IBM, Microsoft, VMware in XenSource.

3.2 Programska oprema kot storitev S t r a n | 47


• optimizacija distribucije – podpira vsebinsko verifikacijo in preverjanje integritete

na osnovi infrastrukture s standardnim javnim ključem ter ponuja osnovno shemo

za upravljanje programskega licenciranja

• optimizacija enostavne in avtomatske uporabniške izkušnje – podpira validacijo

celotnega paketa in vsakega virtualnega stroja v namestitveni fazi življenjskega

cikla VM; zapakira tudi uporabnikovo informacijo o ustreznem stroju, ki bi lahko

bila uporabna za virtualizacijsko platformo pri namestitvi

• podpira eno ali več VM konfiguracij – standardne enotne VM pakete ali pakete, ki

vsebujejo večnivojske storitve, zgrajene z več neodvisnih VM

• prenosno VM pakiranje – OVF je platformsko nevtralen format; podpira

najrazličnejše formate trdih diskov, ki danes obstajajo, in je razširljiv za bodoče

formate

• ponudniško in platformsko neodvisen – OVF se ne zanese na uporabo določenih

gostujočih platform, virtualizacijskih platform ali gostujočega operacijskega

sistema (znotraj VM)

• razširljiv – je oblikovan, da bo razširljiv z razvojem virtualnih tehnologij

• lokalizacija – podpira več jezikovnih opisov za uporabnike in lokalizacijo

interkativnih procesov v času namestitve VM

• odprt standard

3.2 Programska oprema kot storitev

Pojem programska oprema kot storitev (SaaS) je v industriji programske opreme prisoten

že nekaj časa. Natančna in poenotena definicija SaaS-a ne obstaja. Čeprav SaaS obeta

veliko, je danes na voljo zelo malo smernic za doseganje le-ta.

Microsoft verjame, da bo SaaS imel ključen vpliv na industrijo programske opreme, ker bo

programska oprema kot storitev spremenila način gradnje, prodaje, nakupa in uporabe

programske opreme (33).

48 | S t r a n 3.2 Programska oprema kot storitev


SaaS kot učinkovit mehanizem za dostavo programske opreme ustvarja priložnost za IT

oddelke, da lahko spremenijo svoj fokus iz namestitve in podpore aplikacije v upravljanje

storitev, ki te aplikacije nudijo. V nadaljevanju razvijemo filozofijo SaaS, predstavljamo

ključne karakteristike pri uporabi in ponujanju SaaS, opisujemo zrelostni model SaaS ter

navajamo pomembne lastnosti glede varnosti pri uporabi SaaS-a.

3.2.1 Filozofija

Obstaja nekaj temeljnih principov, ki naredijo programsko opremo kot storitev drugačno

od tradicionalno zapakirane programske opreme na eni strani in enostavnih spletnih strani

na drugi. Rittinghouse in Ransome v svoji knjigi pravita, da je SaaS »programsko

distribucijski model, v katerem so aplikacije goščene s strani prodajalca ali ponudnika

storitev in so dostopne odjemalcem preko omrežja, običajno interneta« (24). Če se

izrazimo z Microsofovimi besedami, SaaS je »programska oprema, nameščena kot goščena

storitev in dostopna preko interneta« (33). Če povzamemo, obe definiciji ne opišeta nobene

ustrezne aplikacijske arhitekture, specifičnih tehnologij ali protokolov in ne zahtevata

določenega poslovnega modela. Z namenom izogibati se posplošenosti definicij

identificiramo dve poglavitni kategoriji SaaS-a:

• Poslovno usmerjene storitve (angl. line of business – LOB), ki so ponujene

podjetjem in organizacijam vseh velikosti. Storitve LOB so običajno velike in

prilagodljive poslovne rešitve, ki olajšajo poslovne procese (finance, upravljanje

oskrbovalnih verig in upravljanje odnosov s strankami (angl. Customer Relationship

Management – CRM)). Te storitve se strankam prodajajo na osnovi naročnine.

• Odjemalsko usmerjene storitve, ki so ponujene javnosti. Odjemalsko usmerjene

storitve so lahko prodane na osnovi naročnine, čeprav so bolj običajno ponujene

odjemalcem brezplačno.

SaaS aplikacija ne zahteva razvoja velike infrastrukture na odjemalski lokaciji, kar pomeni

odpravljanje ali bistveno zmanjšanje finančnih sredstev. Prav tako SaaS aplikacije lahko

načrtujemo in izvajamo z minimalnim trudom in uvedbenimi aktivnosti, kar pomeni, da bo

investicija povrnjena v najkrajšem možnem roku. Tako so prodajalci SaaS omogočili

testiranje programske opreme na določeno periodo, običajno 30 dni, da bi zmanjšali

tveganja pred nakupom. Dostop do aplikacije SaaS je običajno omogočen z uporabo



najemniškega modela (angl. subscription model), kjer stranke plačajo trajno pristojbino za

uporabo aplikacije. Pristojnostne strukture so različne od aplikacije do aplikacije; nekateri

ponudniki zaračunajo pavšalni znesek za neomejen dostop do nekaterih ali vseh funkcij

aplikacije, dokler drugi zaračunajo zneske na osnovi uporabe.

V pravi obliki ponudnik SaaS centralno gosti aplikacijo in ponuja več odjemalcem dostop

do nje preko interneta za določeno pristojbino. V praksi so določljive značilnosti med

lokalno nameščenimi in SaaS aplikacijami razporejene v treh dimenzijah: kako je

programska oprema licencirana, kje je locirana in kako je upravljana (Slika 3.4). Vsako

dimenzijo lahko prikažemo kot kontinuum, kjer je lokalna programska oprema na eni

strani, SaaS na drugi ter dodatne kombinirane opcije med njima (34):

• Licenciranje: lokalno nameščene aplikacije so običajno s stalno licenco ali so v

popolni lasti. SaaS aplikacije so običajno licencirane s transakcijskim modelom na

osnovi uporabe, kjer se stranki zaračuna samo za transakcije uporabljenih storitev.

Vmes je že znani časovni naročniški model, kjer stranka plača pavšalno pristojbino

za določeno časovno obdobje (en mesec ali četrtletje) in v tem obdobju neomejeno

uporablja storitve.

• Lokacija: SaaS aplikacije so nameščene na lokaciji SaaS gostitelja, medtem ko so

lokalne aplikacije nameščene v našem lastnem okolju. Vmes je model namenske

naprave, v katerem prodajalec priskrbi strojno/programsko opremo kot »črno

škatlo«, ki je namesto na prodajalski nameščena na naši lokaciji.

• Upravljanje: tradicionalno, IT oddelek je odgovoren za ponudbo IT storitev

uporabnikom, kar pomeni, da mora biti IT oddelek seznanjen z omrežjem,

strežnikom in aplikacijsko platformo, nuditi mora podporo in odpravljanje težav,

Lastništvo/ stalna licenca

Pavšalna naročnina

Izračunana naročnina

Lokalno Namenska naprava Oblak

Korporacijski IT Ponudnik

aplikacijskih storitev (ASP)

Sporazum o ravni storitve

(SLA)

Licenciranje

Lokacija

Upravljanje

Tradicionalno »čisto« SaaS

Slika 3.4 – SaaS kontinuumi



reševati probleme varnosti, zanesljivosti, izvedljivosti in razpoložljivosti. Ker gre

za veliko delo, IT oddelki posredujejo nekatere upravljalske odgovornosti tretjim

strankam, ki so specializirane za IT upravljanje. Po drugi strani so SaaS aplikacije

celotno upravljane s strani prodajalca ali SaaS gostitelja; implementacija

upravljalskih opravil in odgovornosti je odjemalcu neznana. Sporazum o ravni

storitve vodi kakovost, razpoložljivost in podpira obveznosti, ki jih dobi naročnik s

strani ponudnika.

Programska oprema kot storitev temelji na konceptu več najemnikov (angl. multi-tenant)

hkrati na enem primerku aplikacije (angl. single instance), kar ponuja funkcijsko bogate

izkušnje v primerjavi z že znanimi lokalno nameščenimi (angl. on-premises) aplikacijami.

Zaradi tega se morajo ponudniki osredotočiti na tri med seboj povezana področja: poslovni

model, arhitektura aplikacije in operativna struktura, kot prikaže Slika 3.5:

V nadaljevanju opišemo vsako izmed področij posebej, osredotočimo pa se na aplikacijsko

arhitekturo.

3.2.2 Poslovni model

Navaditi se moramo na poslovni model, kjer je lastništvo programske opreme premaknjeno

od odjemalca k zunanjemu ponudniku. Odgovornosti odjemalca glede tehnološke

infrastrukture in upravljanja so vsekakor prerazporejene na ponudnika. Pri tem ponudnik

zmanjša stroške ponujanja programskih storitev tako, da cilja na »dolg rep« majhnih

podjetij.

SaaS

POSLOVNI MODEL

OPERATIVNA STRUKTURA

APLIKACIJSKA ARHITEKTURA

Slika 3.5 – Področja delovanja ponudnikov SaaS-a



V organizaciji se IT proračun običajno potroši na treh področjih:

• programska oprema – aktualna programska oprema in podatki, ki jih organizacija

uporablja za računanje in procesiranje informacij

• strojna oprema – namizni računalniki, strežniki, omrežne komponente in prenosne

naprave, ki uporabnikom omogočajo dostop do programske opreme

• profesionalne storitve – ljudje in institucije, ki skrbijo za nenehno delovanje in

razpoložljivost sistema

V okolju, kjer se programska oprema razvija na osnovi lokalnega nameščanja, je večina

proračuna potrošena za strojno opremo in profesionalne storitve ter majhen del za

programsko opremo (Slika 3.6). Proračun programske opreme je porabljen za licencirane

izvode programskih oprem in prilagajanje programske opreme poslovanju. Proračun

strojne opreme je porabljen za namizne in prenosne računalnike, strežnike za gostovanje

podatkov in aplikacij ter omrežne komponente. Proračun za profesionalne storitve plača

osebje za razvoj in podporo programske opreme, prav tako tudi svetovalce in razvojne vire

za načrtovanje in gradnjo lastnih sistemov (33).

V SaaS okolju prodajalec gosti aplikacije in podatke na centralnih strežnikih na oblačni

lokaciji ter vzdržuje strojno in programsko opremo z določenim podpornim osebjem.

Končni rezultat je večji odstotek proračuna, namenjen za programsko opremo, običajno v

obliki naročniške pristojbine (Slika 3.7).

Ideja »dolgega repa« (angl. long tail) pove, zakaj so spletni trgovci, kot je amazon.com, v

privilegiranem položaju glede izpolnjevanja velikih povpraševanj v primerjavi s

tradicionalnimi trgovci, ki takih povpraševanj ne morejo stroškovno učinkovito izpolniti.

Programska oprema

Strojna oprema

Profesionalne storitve

Programska oprema

Profesionalne storitve

Strojna oprema

Slika 3.7 - Proračun za okolje SaaS Slika 3.6 – Proračun za tradicionalno okolje



LOB programske rešitve poskušajo biti prilagodljive potrebam strank in običajno zahtevajo

namensko strežniško opremo in podporno osebje. Stroški zagotavljanja takšnih sredstev

prispevajo k minimalni ceni, po kateri si prodajalec lahko privošči prodajanje svoje

programske opreme. Zaradi tega je programska oprema običajno tržena večjim podjetjem,

ki si lahko privoščijo plačilo le-te (Slika 3.9). Kljub temu za vsako veliko podjetje, ki kupi

rešitev LOB, obstaja veliko število manjših in srednje velikih podjetij, ki bi lahko imela

korist od takih rešitev, vendar si jih ne morejo privoščiti.

Prodajalci SaaS lahko ponudijo programske rešitve z nižjimi stroški kot tradicionalni

prodajalci, ne samo v denarnih izrazih, ampak tudi v smislu zmanjšanja kompleksnosti IT

infrastrukture. Tako SaaS dobi izključnI dostop do povsem novega razpona potencialnih

kupcev, ki so prej bili nedostopni za tradicionalne prodajalce zaradi stroškovne

neučinkovitosti (Slika 3.8) (33).

3.2.3 Arhitektura aplikacije

Z arhitekturnega vidika je dobro oblikovana SaaS aplikacija skalabilna, večnajemniška in

nastavljiva. Skalabilnost pomeni maksimiziranje sočasnosti in uporabljanje aplikacijskih

virov bolj učinkovito – optimizacija trajanja zaklepanja, vzdržljivo stanje med

transakcijami (angl. statelessness), porazdeljevanje niti in omrežnih povezav ipd.

Večnajemništvo je najbolj pomemben paradigmični premik, ki ga mora napraviti

tradicionalni arhitekt. Takšna arhitektura maksimizira porazdeljevanje virov med

najemniki, hkrati pa je zmožna ločiti pripadajoče podatke različnih odjemalcev. Seveda

prilagajanje aplikacije za vsakega posameznega odjemalca ni najboljša rešitev. Namesto

Naslovljiv trg Zmanjšani stroški zagotavljanja

programske opreme na eno stranko

Nov trg Pr

ihod

ek n

a st

rank

o

Število strank

Stroški zagotavljanja programske opreme na eno stranko

Naslovljiv trg Nenaslovljiv trg (dolg rep)

Prih

odek

na

stra

nko

Število strank Slika 3.9 – Tržna linija za LOB prodajalce Slika 3.8 – Nižji stroški SaaS-a odprejo nov trg



tega vsak odjemalec uporablja metapodatke za konfiguracijo svoje aplikacije. Naloga

arhitekta je zagotoviti odjemalcem enostavno konfiguriranje aplikacij.

Zrelostni model aplikacije SaaS lahko poseduje samo enega ali dva od teh atributov, in še

vedno izpolni potrebne poslovne zahteve. Zrelost aplikacije SaaS Microsoft predstavi z

uporabo modela s štirimi različnimi ravnmi. Vsaka raven se razlikuje od predhodne z

dodajanjem enega izmed atributov (Slika 3.10) (33).

Prva raven predstavlja arhitekturo po meri (angl. ad-hoc) in je podobna tradicionalnemu

modelu, dostavljenemu s strani ponudnika aplikacijskih storitev. Vsak odjemalec ima svojo

lastno prilagojeno različico goščene aplikacije in izvaja lasten primerek aplikacije na

strežnikih gostitelja. Edina razlika je v tem, da se uporabniki znotraj organizacije povežejo

na enem primerku, ki se izvaja na strežniku in primerek v celoti neodvisen od ostalih

primerkov, ki tečejo pri gostitelju. Običajno je tradicionalne odjemalec-strežnik aplikacije

mogoče premakniti k modelu SaaS na prvem zrelostnem nivoju z relativno malim

razvojnim trudom in brez celotne gradnje arhitekture.

Konfigurabilnost (angl. configurable) je naslednja raven zrelosti, kjer prodajalec gosti

ločene primerke aplikacije za vsakega odjemalca (najemnika). Vsi primerki uporabijo isto

implementacijsko kodo, vendar prodajalec ponudi odjemalcem podrobne konfiguracijske

Najemnik 1 Najemnik 2 Najemnik 3 Najemnik 1 Najemnik 2 Najemnik 3

Najemnik 1 Najemnik 2 Najemnik 3 Najemnik 1 Najemnik 3 Najemnik 2

Primerek 1 Primerek 2 Primerek 3 Primerek Primerek Primerek

Primerek Primerek Primerek Primerek

Najemniški izenačevalec obremenitve

1 2

3 4

Slika 3.10 - SaaS zrelostni model



opcije, ki omogočajo odjemalcem spreminjanje aplikacijskega izgleda in obnašanja. Pri

tem načinu je vsaka sprememba kode enostavno preslikana do vseh odjemalcev istočasno,

brez dodatnih posodabljanj posameznih primerkov. Premostitev tradicionalne aplikacije na

drugem nivoju modela SaaS zahteva večji arhitekturni trud v primerjavi s prvem nivojem.

Druga raven zahteva od prodajalca zadostno strojno in skladiščno opremo za podporo

potencialno velikega števila aplikacijskih primerkov, ki se izvajajo istočasno.

Naslednja raven podpira nastavljivost in večnajemniško učinkovitost. Prodajalec izvaja

eno instanco, ki streže vsakega odjemalca s konfigurabilnimi metapodatki in ponuja

edinstveno uporabniško izkušnjo in množico funkcij. Avtorizacija in varnostne politike

zagotavljajo, da so vsi odjemalski podatki shranjeni ločeno od ostalih odjemalcev ter da ni

znamenja, ki bi kazalo, da je aplikacijski primerek porazdeljen med več najemnikov. Ta

pristop omogoča bolj učinkovito uporabo računalniških virov, kar pomeni nižje stroške.

Slabost tega pristopa je omejena skalabilnost. Skalabilnost aplikacije je možna le z njenim

premikom na močnejši strežnik, dokler je to stroškovno sprejemljivo.

Četrta in zadnja zrelostna raven predstavlja skalabilnost, kofigurabilnost in

večnajemništvo hkrati. Prodajalec gosti več odjemalcev z identičnimi, izenačeno

obremenjenimi primerki. Vsakemu odjemalcu se podatki hranijo ločeno in so ponujeni

konfigurabilni metapodatki. Sistem SaaS je skalabilen za poljubno veliko število strank,

ker se lahko število strežnikov in primerkov po potrebi povečuje ali zmanjšuje brez

dodatne arhitekturne spremembe aplikacije.

3.2.4 Operativna struktura

Operativna struktura aplikacije določa, kaj je potrebno za dostavo aplikacije do odjemalcev

ter kako obdržati aplikacijo razpoložljivo in izvedljivo na stroškovno učinkovitem nivoju.

Ponudba programske opreme kot storitve zahteva vključitev dodatnega nivoja pri sklenitvi

pogodb gostovanja. Običajno je potreben sistem merjenja in plačevanja za:

• natančno sledenje odjemalske uporabe ter zaračunavanje za uporabljen čas ali vire

• omejevanje ali dušenje dostopa v določenih obdobjih dneva

• spremljanje dostopa in izvedbo spletne strani za zagotovitev pogojev SLA

• izvedbo drugih funkcij z namenom zagotavljanja gladke izkušnje odjemalcem



Sistem, ki izvede te funkcije, je znan kot deljene storitve (angl. shared services). Dalje

lahko deljene storitve klasificiramo v dveh podkategorijah (33):

• operativno podporne storitve (angl. operational support services) – upravljanje z

operacijskimi zadevami, kot so aktivacija računa, rezervacija, storitveno zagotovilo,

uporaba in merjenje

• poslovno podporne storitve (angl. business support services) – podpora

zaračunavanja (izdajanje računov, ocenitev, obdavčitev in zbirke) in upravljanje

odjemalcev (naročanje prijave, odjemalske storitve, oskrba odjemalcev in CRM)

Sporazum o ravni storitve (SLA) določa operativne standarde, ki jih mora prodajalec

spoštovati. Ker so SLA pravno zavezujoče pogodbe, lahko neizpolnjevanje pomeni

značilno izgubo prihodkov in škodo ugledu. Spremljanje aplikacijske arhitekture za

kakršnokoli težavo predstavlja bistveno orodje za odkrivanje in reševanje težav, preden

rezultirajo v določeno degradacijo.

Spremljanje razpoložljivosti bi moralo biti najpomembnejša prioriteta vsakega prodajalca

SaaS. Prekinitev omrežja ali elektrike lahko povzroči značilno izgubo podatkov in

produktivnosti za velik odstotek odjemalcev. Priporočljiva je podpora osnovnih tehnik, kot

je spremljanje srčnega bitja in mehanizmov opozarjanja (33).

Spremljanje izvedljivosti je naslednji izziv za prodajalca. Odjemalec pričakuje izvedljiv

dostop do aplikacije. Čeprav SLA do neke mere podpira takšno pričakovanje, se zgodi, da

odjemalci zaznajo počasno in neodzivno aplikacijo, in nato prekličejo obnovo naročanja.

Nasprotno pa hitra in vitka aplikacija lahko prinese odjemalcem zadovoljstvo. Za visoko

raven izvedljivosti je najboljša rešitev podpora števcev izvedljivosti. Prav tako pride v

poštev postavitev pragov izvedljivosti za CPU uporabo in odzivni čas aplikacije ter

sprožitev ustreznih opozoril.

3.2.5 Varnost

Pri vsaki programski opremi je varnost pomemben vidik. Enako velja za programsko

opremo kot storitev. Varnost SaaS predstavlja glavno skrb odjemalcev in najvišjo prioriteto

aplikacijskih arhitektov. Z avtentikacijo in avtorizacijo si lahko pomagamo pri zagotovitvi



nadzora privatnih podatkov. Obstajajo tudi druge varnostne zadeve, ki so pomembne,

vendar jih ne obravnavamo v sklopu tega diplomskega dela.

Ponudnik SaaS običajno vsakemu najemniku delegira odgovornost ustvarjanja in

vzdrževanja uporabniškega računa. Pri delegiranju administracije je odjemalec odgovoren

za svoj račun, vendar ponudnik izvede avtentikacijo. Uporabljata se dva splošna pristopa

avtentikacije: centraliziran avtentikacijski sistem in decentraliziran avtentikacijski sistem

(33).

V centraliziranem avtentikacijskem sistemu ponudnik upravlja centralno podatkovno bazo

z uporabniškimi računi in streže vsem najemnikom aplikacije. Vsakemu administratorju

najemnika je dodeljeno dovoljenje za ustvarjanje, upravljanje in brisanje uporabniških

računov v imeniku uporabniških računov. Uporabniški podpis ponuja pooblastilo za

aplikacijo, ki se avtenticira v centralnem imeniku in omogoča dostop, če je pooblastilo

veljavno. Pristop zahteva relativno preprosto avtentikacijsko infrastrukturo, ki je enostavna

za načrtovanje in implementacijo in ne zahteva dodatnih sprememb najemniške

infrastrukture. Slabost tega pristopa je težavna implementacija enkratne prijave (angl.

single sign-on), kjer aplikacija sprejme pooblastila, ki jih je uporabnik že vpisal za

zagotovitev dostopa (33).

V decentraliziranem avtentikacijskem sistemu najemnik namesti federativno storitev, ki

komunicira s svojo (najemnikovo) storitvijo o imeniku računov. Ko uporabnik aplikacije

poskuša dostopati do aplikacije, federativna storitev lokalno avtenticira uporabnika in izda

varnostni žeton, ki ga avtentikacijski sistem ponudnika SaaS sprejme in omogoči

uporabniku dostop do aplikacije. Pristop je primeren, ko je pomembna enkratna prijava,

ker se avtentikacija obravnava »za kulisami« in od uporabnika ne zahteva pomnjenja in

vnašanja specialnih pooblastil.

Možen je tudi hibridni pristop, kjer ponudnik uporablja centraliziran pristop za

avtentikacijo uporabnikov manjših najemnikov, in federativni pristop za večja podjetja.

Avtorizacija oziroma dostop do aplikacijskih virov in poslovnih funkcij je upravljana z

uporabo vlog. Vsaki vlogi je dodeljeno dovoljenje, ki omogoča uporabnikom izvedbo akcij

v soglasju z ustreznimi poslovnimi pravili. Vloge omogočajo upravljanje znotraj same

aplikacije SaaS; vsebujejo lahko posamezne uporabniške račune ali uporabniške skupine.

3.3 Vrednost računalništva v oblaku S t r a n | 57


Posameznim računom in skupinam je lahko dodeljenih več različnih vlog. V odvisnosti od

dodeljene vloge uporabnik dobi eno ali več dovoljenj za izvedbo ustreznih operacij. Eno

dovoljenje je lahko dodeljeno eni ali več vlogam (33).

Aplikacije lahko nadzirajo dostop do akcij in virov na bolj rahlem nivoju z uporabo

poslovnih pravil. Poslovna pravila predstavljajo pogoje, ki morajo biti izpolnjeni pred

zagotovitvijo dostopa.

Nadzor dostopa je upravljan na nivoju obsega (angl. scope level). Vsak obseg deduje vloge,

dovoljenja in poslovna pravila iz starševskega obsega in jih lahko spreminja, dodaja in

briše.

3.3 Vrednost računalništva v oblaku

Področje, vredno razmišljanja, predstavlja dejanska vrednost, ki jo prinaša računalništvo v

oblaku. V tem podpoglavju poskušamo odgovoriti na največkrat postavljena vprašanja v

zvezi z določitvijo pravilne infrastrukture, računanjem donosnosti naložbe za ustrezno

formacijo oblaka ter potencialnimi ovirami in priložnostmi, ki jih prinaša oblačna rešitev.

3.3.1 Infrastrukturne možnosti

Poleg oblačne infrastrukture imamo na izbiro še dva IT pristopa:

• notranja IT infrastruktura in podpora

• zunanje upravljanje storitev

V primeru notranje infrastrukture ima ponudnik svojo strojno opremo in osebje, ki upravlja

z njo. Pri tem potencialno finančno korist predstavlja varčevanje denarja za nakup opreme.

Ko pa kakšen stroj odpove, povzročeni strošek plača ponudnik sam.

Pri zunanjem upravljanju storitev imamo podobne pridobitve, le da plačamo fiksno

pristojbino drugemu ponudniku, ki ima v lasti strežnik in skrbi zanj. Če strežnik odpove, je

podjetje tisto, ki skrbi za njegovo takojšnjo zamenjavo.

58 | S t r a n 3.3 Vrednost računalništva v oblaku


S pomočjo naslednje preglednice (Preglednica 3.3), ki primerja notranji IT pristop, pristop

z upravljanjem storitev in oblačni pristop, lahko sklepamo, da je oblačna infrastruktura

najbolj primerna, čeprav je ponudnik upravljalskih storitev tik za njo (35).

Preglednica 3.3 – Primerjava infrastrukturnih pristopov

Notranji IT pristop Pristop upravljanja storitev Oblačni pristop Kapitalna naložba Pomembna Zmerna Zanemarljiva

Koliko denarja je treba vložiti za vzpostavitev svoje infrastrukture? Z notranjim IT pristopom je treba plačati strojne potrebe, preden jih potrebujemo. Pri upravljanju storitev se običajno zahteva plačilo zmerne pristojbine. V oblaku ni vnaprejšnjih stroškov in obveznosti.

Tekoči stroški Zmerni Pomembni Na osnovi uporabe Notranji IT pristop ima stroške za osebje in/ali pogodbenike za upravljanje infrastrukture ter tudi za prostor pri ponudniku gostovanja in/ali nepremičnine in javne službe. Izredni variabilni stroški se zabeležijo pri pogodbenikih, ko se zgodijo izredni dogodki. Čeprav so upravljalske storitve precej drage, je mesečni znesek običajno znan in redko spremenljiv. Oblak zna biti drag ali poceni, odvisno od potreb. Njegova ključna prednost je, da se plača samo tisto, kar se uporablja, in nič več. Stroški za osebje so večji v primerjavi z upravljalskim pristopom in manjši od notranjega pristopa.

Rezervacijski čas Pomemben Zmeren Ni Kako dolgo traja dodajanje nove komponente v infrastrukturi? Pri notranjem in upravljalskem pristopu je treba vnaprej načrtovati, naročiti, počakati na prihod komponente, in nato jo namestiti v podatkovnem skladišču. V oblaku se nov operativen »strežnik« dobi v nekaj minutah.

Fleksibilnost Omejena Zmerna Fleksibilen Kako prilagodljiva je infrastruktura na nepričakovane zahteve virov? Notranji IT pristop ima fiksno kapaciteto, ki se poveča edino z dodatno kapitalno naložbo. Pri upravljanju storitev je možen kratkoročen dostop do alternativnih virov. V oblaku je možna nastavitev avtomatskega dodajanja kapacitete po potrebi in njeno odstranjevanje, ko ni več potrebna.

Zahteve znanja osebja

Pomembne Omejene Zmerne Kakšna ekspertiza je potrebna za podporo okolij? Za notranjim pristop je potrebno osebje ali pogodbeniki, ki znajo upravljati s strojno in programsko opremo. Prednost ima upravljalski pristop, kjer ni potrebno nobeno znanje o IT-ju. Oblak lahko zahteva veliko ali malo znanja, odvisno od načina uporabe.

Zanesljivost Variira Visoka Zmerna do visoka Kako razpoložljive bodo storitve 24/7? Možnost razvoja visoko razpoložljive infrastrukture z notranjim pristopom je funkcija nivoja znanja osebja in znesek naložbe v infrastrukturi. Ponudnik upravljalskih storitev je najvarnejša in najbolj dokazana alternativa, vendar nima lokacijske odpravnine oblaka. Oblak ima značilne lokacijske odpravnine, vendar nima dokazane stabilnosti.

3.3.2 Ekonomija oblačnega računalništva

Sedaj se lahko posvetimo opazovanju ekonomskih modelov računalništva v oblaku, in

sicer:

• Finozrnati ekonomski modeli omogočajo bolj tekoče tržne odločitve. Elastičnost, ki

jo oblaki ponujajo, služi za premostitev tveganja (angl. shifting the risk).



• Čeprav stroški strojne opreme padajo, padajo z različnimi razmerji; npr.

računalniški in skladiščni stroški padajo hitrejše kot stroški WAN. Računalništvo v

oblaku lahko sledi tem spremembam bolj učinkovito, kot pa lastni podatkovni

center.

• Pri odločanju o tem, ali premakniti obstoječe storitve na oblak, je treba preučiti

pričakovano povprečno in maksimalno izkoriščanje virov, še posebej, če ima

aplikacija visoko spremenljive zahteve virov, praktične omejitve pri realni uporabi

kupljenih oprem in različne operativne stroške, ki se razlikujejo glede tipa

oblačnega okolja.

Začnimo z elastičnostjo. Ključna ugotovitev je, da ima računalništvo v oblaku sposobnost

finozrnatega dodajanja ali odstranjevanja virov v nekaj minutah. Dejansko izkoriščanje

strežnikov in podatkovnih centrov je v razponu od 5 do 20 %, ker za veliko storitev

maksimalno delovanje presega povprečje z dejavnikom od 2 od 10. Nekateri uporabniki

namerno rezervirajo vire manj, kot maksimalno pričakujejo, in morajo zaradi tega narediti

dodatno rezerviranje. Večja kot je variacija, več je odpadkov. Elastičnost omogoča

zmanjšanje teh odpadkov (26).

Primer elastičnosti: predpostavimo, da ima naša storitev predvidljivo dnevno

povpraševanje, kjer maksimum zahteva 500 strežnikov opoldne ter minimum samo 100

strežnikov opolnoči (Slika 3.11 a). Dokler se povprečno izkorišča 300 strežnikov čez dan,

dejansko, je izkoriščanje 300 x 24 = 7200 strežniških ur. Kljub temu smo rezervirali

maksimalno 500 strežnikov in plačamo 500 x 24 = 12000 strežniških ur, kar pomeni

dejavnik 1,7 več, kot je treba. Zaradi tega lahko, dokler je strošek na strežniško uro za

določeno obdobje (npr. 3 leta) 1,7-krat manjši od stroška za nakup strežnika, uporabimo

storitveno računalništvo.

Čeprav primer podceni elastičnost, še vedno predstavlja najbolj učinkovit način uporabe

virov. Pri prvem primeru manjše rezervacije (Slika 3.11 b) je žrtvovan potencialni

prihodek nepostreženih uporabnikov. Pri drugem primeru (Slika 3.11 c) bodo uporabniki

zapustili storitev, dokler je maksimalna uporabniška obremenitev enaka kapaciteti

podatkovnega centra, na kateri uporabniki spet dobijo dostopno rešitev, vendar je število

potencialnih uporabnikov manjše.



Še en primer iz realnega sveta. Ko je Animoto ponudil svoje storitve preko Facebooka, je

doživel porast povpraševanja, ki je povzročil povečanje števila strežnikov s 50 na 3500 v

treh dneh. Četudi bi bilo povprečno izkoriščanje vsakega strežnika nizko, nihče ni mogel

predvideti, da se bodo potrebe po virih nenadoma podvojile vsakih 12 ur v treh dneh. Ko je

bil maksimum dosežen, je promet padel na nivo, ki je bil precej pod maksimumom. V tem

primeru povečanje elastičnosti ni predstavljalo optimizacije stroškov, ampak operativno

zahtevo, ter je zmanjšanje elastičnosti omogočilo, da se stroški stabilnega stanja bolj

ujemajo z delovno obremenitvijo stabilnega stanja.

Tveganje pri napačni oceni delovne obremenitve je premeščeno k oblačnemu prodajalcu.

Prodajalec lahko zaračuna premijo za prevzem tega tveganja. Strokovnjaki iz Berkeleyja

predlagajo enačbo (3.1), ki je posplošena za vse primere. Predpostavka je, da se uveljavi

zaračunavanje po uporabi, kjer odjemalci plačajo sorazmerno s količino uporabljenega

časa in virov. Prav tako je predpostavka, da je odjemalski prihodek direktno sorazmeren s

skupnim številom uporabniških ur.

𝑼𝑼𝑼𝑼𝑼𝑼𝑼𝑼𝑼𝑼𝑼𝑼𝑼𝑼𝑼𝑼š𝒌𝒌𝒌𝒌𝑼𝑼𝑼𝑼𝒌𝒌𝑼𝑼𝑼𝑼𝒐𝒐𝑼𝑼𝒌𝒌 𝒙𝒙 (𝑼𝑼𝑼𝑼𝑼𝑼𝒑𝒑𝑼𝑼𝒑𝒑𝒌𝒌𝒌𝒌− 𝑺𝑺𝑺𝑺𝑼𝑼𝑼𝑼š𝒌𝒌𝒌𝒌𝑼𝑼𝑼𝑼𝒐𝒐𝑼𝑼𝒌𝒌) ≥ 𝑼𝑼𝑼𝑼𝑼𝑼𝑼𝑼𝑼𝑼𝑼𝑼𝑼𝑼𝑼𝑼š𝒌𝒌𝒌𝒌𝑼𝑼𝑼𝑼𝒌𝒌𝑼𝑼𝑼𝑼𝒑𝒑𝑼𝑼𝑺𝑺𝒌𝒌𝑼𝑼𝒑𝒑𝑼𝑼𝑼𝑼𝒑𝒑𝒌𝒌𝑼𝑼𝑺𝑺𝒌𝒌𝑼𝑼 𝒙𝒙 �𝑼𝑼𝑼𝑼𝑼𝑼𝒑𝒑𝑼𝑼𝒑𝒑𝒌𝒌𝒌𝒌−

𝑺𝑺𝑺𝑺𝑼𝑼𝑼𝑼š𝒌𝒌𝒌𝒌𝑼𝑼𝑼𝑼𝒑𝒑𝑼𝑼𝑺𝑺𝒌𝒌𝑼𝑼𝒑𝒑𝑼𝑼𝑼𝑼𝒑𝒑𝒌𝒌𝑼𝑼𝑺𝑺𝒌𝒌𝑼𝑼𝑰𝑰𝑰𝑰𝒌𝒌𝑼𝑼𝑼𝑼𝑼𝑼šč𝒌𝒌𝑼𝑼𝑼𝑼𝒆𝒆𝑺𝑺

� (3.1)

Viri

Kapaciteta

Kapaciteta

Zahteva Zahteva

Viri

Viri

Kapaciteta

Zahteva

1

1

1

2 3

2 3 2 3 Čas (dni)

Čas (dni)

Čas (dni) a. Rezervacija za maksimalno obremenitev b. Manjša rezervacija 1

c. Manjša rezervacija 2

Slika 3.11 – Elastičnost rezervacije



Leva stran enačbe pomnoži neto prihodek na uporabniško uro s številom uporabniških ur,

kar predstavlja pričakovani dobiček uporabe računalništva v oblaku. Desna stran enačbe

izvede isti izračun za podatkovni center s fiksno kapaciteto, pri tem pa upošteva dejavnik

povprečnega izkoriščanja. Stran z večjo vrednostjo predstavlja priložnost za večji dobiček

(26).

Če je izkoriščenost enaka 1, obe strani izgledata enaki. Vendar se v teoriji, ko se

izkoriščenost bliža 1, sistemski odzivni čas bliža neskončnosti. V praksi je uporabna

kapaciteta podatkovnega centra običajno med 0,6 in 0,8.

Z ekonomskega vidika lahko primerjamo prej omenjene IT infrastrukturne rešitve. Imamo

transakcijsko spletno aplikacijo z izenačevalcem obremenitve, dva aplikacijska strežnika in

dva podatkovna strežnika. Uporabimo podatke priloženi v Reesejevi knjigi (35):

Preglednica 3.4 – Primerjava stroškov različnih pristopov

3.3.3 Ovire in priložnosti

Pomagamo si lahko s člankom iz Berkeleyja, v katerem so strokovnjaki identificirali deset

ovir. Vsaki oviri je pridružena priložnost oziroma način premagovanja ovire (Preglednica

3.5). Prve tri predstavljajo tehnične ovire pri sprejemu računalništva v oblaku, naslednjih

pet je tehničnih ovir pri rasti računalništva v oblaku po njegovem sprejemu in zadnji dve

oviri sta politična ter poslovna ovira pri sprejemu oblačnega računalništva.

17 Cene v knjigi so podane v ameriških dolarjih. Pretvorili smo jih po tečaju 1 $ = 0,7314 €.

Notranji IT pristop Pristop upravljanja

storitev

Oblačni pristop

Kapitalna naložba 29.256 €17 0 € 0 €

Namestitveni stroški 7.314 € 3.657 € 731 €

Mesečne storitvene pristojbine 0 € 2.925 € 1.755 €

Mesečni stroški osebja 2.340 € 0 € 731 €

Neto stroški v treh letih 108.981 € 94.353 € 77.530 €



Preglednica 3.5 – Ovire in priložnosti za sprejem in rast računalništva v oblaku

Ovira Priložnost

1 Razpoložljivost storitev Uporaba več oblačnih ponudnikov, ki bodo zagotovili

poslovno kontinuiteto; uporaba elastičnosti za obrambo

proti porazdeljeni ohromitvi storitev (DDoS).

2 Zaklenitev podatkov Standardizacija API-jev; narediti združljivo programsko

opremo, ki bo zmožna omogočiti rast računalništva.

3 Zaupnost in preglednost podatkov Postaviti enkripcijo, VLAN-e in požarne zidove;

prilagoditi nacionalno pravo preko zemljepisne podatkovne

hrambe.

4 Ozka grla prenosa podatkov FedEx diski; varnostna kopija podatkov/arhiviranje; nižji

stroški WAN usmerjevalnika; LAN stikala z višjo pasovno

širino.

5 Nepredvidljivost izvedljivosti Izboljšana podpora virtualnih strojev; bliskovni pomnilnik;

skupinsko razvrščanje VM-jev za HPC aplikacije.

6 Skalabilno skladišče Izumiti skalabilno hrambo.

7 Programske napake v veliko

skalabilnih distribuiranih sistemih

Izumiti razhroščevalnik, ki se zanese na distribuirane VM.

8 Hitra skalabilnost Izumiti avtomatsko skalabiranje, ki se zanese na učenja

strojev; trenutni posnetki za spodbujanje konzervativcev

računalništva v oblaku.

9 Ugled usodnega deljenja18 Ponudba storitev, ki bodo varovale reputacijo (kot pri

elektronski pošti).

10 Licenciranje programske opreme Licence »plačaj za uporabo«; prodaja za množično

uporabo.

Razpoložljivost storitev. Obstoječe SaaS programske opreme so postavile visok standard:

če gredo ljudje iskat po Googlu, ki v tistem trenutku ni na voljo, bodo pomislili, da je

prekinjena internetna povezava. Uporabniki pričakujejo podobno razpoložljivost od novih

storitev, kar pa je težko omogočiti. Preglednica 3.6 prikaže izpade in razloge zanje za

Amazon Simple Storage Service (S3), AppEngine in Gmail v 2008:

18 Usodno deljenje (angl. fate-sharing) – načrtovalska filozofija, kjer so povezani deli sistema vpreženi skupaj tako, da bodo odpovedali skupaj ali pa sploh ne bodo odpovedali.



Preglednica 3.6 – Izpadi AWS, AppEngine in Gmail

Storitev in izpad Trajanje Datum

Izpad S3: preobremenitev avtentikacijske storitve 2 uri 12. 2. 2008

Izpad S3: napaka enega bita je razgnala opravljalski protokol 6–8 ur 20. 7. 2008

AppEngine, delni izpad: programska napaka 5 ur 17. 6. 2008

Gmail: nerazpoložljivost spletne strani zaradi izpada kontaktnega sistema 1,5 ure 11. 8. 2008

Strokovnjaki Berkeleyja menijo, da je uporaba več ponudnikov računalništva v oblaku

verjetno edina rešitev z visoko razpoložljivostjo. Najboljša možnost za neodvisne sklade

programske opreme je, da so ponujeni s strani različnih podjetij, kajti eno podjetje lahko

ima precej težav z uskladitvijo ustvarjanja in ohranjanja dveh skladov v imenu

zanesljivosti programske opreme (26).

Druga ovira so napadi porazdeljene ohromitve storitev (angl. Distributed Denial of Service

– DDoS). Kriminalci lahko grozijo SaaS ponudnikom, da bodo prekinili njihove prihodke

tako, da bodo naredili njihovo storitev nerazpoložljivo, pri tem pa izsilijo nekaj deset tisoč

evrov plačila za preprečitev začetka DDoS napada. Računalništvo v oblaku nudi SaaS

ponudnikom priložnost za obrambo proti DDoS napadom s hitrim povečanjem

skalabilnosti.

Zaklenitev podatkov. API-ji za računalništvo v oblaku so še vedno lastniški, kar pomeni,

da niso standardizirani. Tako odjemalci ne morejo z lahkoto izvleči svojih podatkov in

programov iz ene spletne strani in jih izvajati na drugi. Zaklenitev možnosti odjemalcev je

lahko privlačna za ponudnike CC, vendar so uporabniki občutljivi na to, kar prinaša

zaklenitev – povečanje cen, zanesljivostne težave in celo ponudnike, ki prenehajo

poslovati.

Očitna rešitev je standardizacija API-jev tako, da razvijalci SaaS razporedijo storitve in

podatke na več ponudnikov CC, kar pomeni, da odpoved enega podjetja ne bo povzročila

uničevanja vseh odjemalskih podatkov. Standardizacija API-jev omogoča uporabo novega

modela, v katerem je ista infrastruktura programske opreme uporabljena v privatnem in

javnem oblaku. Takšna možnost omogoča rast računalništva (angl. surge computing), kar

pomeni, da je javni oblak uporabljen za zajemanje dodatnih opravil, ki jih ni možno



enostavno izvesti v podatkovnih centrih (ali privatnih oblakih) zaradi težkih delovnih

obremenitev (26).

Zaupnost in reviznost podatkov. Danes je večina oblakov javnih omrežij, kar izpostavlja

sistem več napadom. Obstajajo tudi zahteve za revizije, ki so potrebne pri preselitvi

podjetniških podatkov v oblaku.

Ni temeljnih ovir, da okolje računalništva v oblaku ne bi bilo enako varno kot notranje IT

okolje. Potrebno je dobro razumevanje tehnologij, kot je šifrirano skladišče, virtualno

lokalno omrežje (angl. Virtual Local Area Network – VLAN) in omrežne zadeve (požarni

zidovi, paketni filtri). Na primer, šifriranje podatkov pred postavljanjem na oblaku je celo

varnejše kot nešifrirani podatki v lokalnem podatkovnem centru. Preglednost je lahko

dodatna raven izven dosega virtualiziranih OS, ki zagotavlja dokazljivo bolj varne objekte

v primerjavi s tistimi v sami aplikaciji.

Računalništvo v oblaku daje ponudnikom in uporabnikom SaaS večjo svobodo za

umestitev hramb. Na primer, Amazon ponuja S3 storitve fizično locirane v Združenih

državah in v Evropi tako, da je izbira ponudnikov prostovoljna.

Ozka grla prenosa podatkov. Aplikacije postanejo podatkovno bolj intenzivne. Prenos

enega terazloga (angl. terabyte) stane med 75 in 110 €, in ti stroški se lahko hitro povečajo.

Uporabniki in ponudniki oblaka morajo razmisliti o posledicah umestitve in prenosa

podatkov na vsakem nivoju, seveda, če želijo minimizirati stroške (26).

Ena priložnost za zmanjšanje stroškov internetnih prenosov je odpošiljanje diskov.

Najcenejši način pošiljanja veliko podatkov je fizično pošiljanje diskov (ali celo

računalnikov) preko nočnih dostavnih storitev. Druga priložnost je arhiviranje podatkov

oziroma varnostno kopiranje podatkov. Ko so arhivirani podatki v oblaku, je možno

ustvarjanje novih storitev, ki bodo omogočile druge funkcije nad ahriviranimi podatki.

Tretja priložnost predstavlja hitrejše zmanjšanje stroškov pasovne širine WAN. Izračunali

so, da dve tretjini stroškov pasovne širine WAN predstavlja strošek za hitre

usmerjevalnike, in samo ena tretjina za optiko.

Nepredvidljivost izvedljivosti. V računalništvu v oblaku si lahko več virtualnih strojev

zelo dobro deli centralno procesno enoto (angl. Central Processing Unit) in glavni



pomnilnik, vendar je I/O (vhodno/izhodno) deljenje problematično. Slika 3.12a prikaže

povprečno pomnilniško prepustnost za primerke 75 EC2. Srednja prepustnost je 1335 MB

na sekundo s standardnim odklonom samo 53 MB/s, kar je manj kot 4 % povprečja. Slika

3.12b prikaže povprečno diskovno prepustnost za primerke 75 EC2, kjer vsak primerek

zapiše 1 GB datoteke na lokalnem disku. Srednja prepustnost pisanja diska je 55 MB/s s

standardnim odklonom 9 MB/s, kar je več kot 16 % povprečja. To kaže na problem I/O

vmešavanja med virtualnimi stroji (26).

Ena priložnost je izboljšanje arhitektur in operacijskih sistemov za bolj učinkovito

virtualizacijo prekinitev in I/O kanalov. Druga možnost je zmanjševanje I/O vmešavanja z

bliskovnim pomnilnikom. Bliskovni pomnilnik lahko podpira več I/O na sekundo na

gigazlog kot diski, kar pomeni, da več virtualnih strojev dela brez medsebojnega

vmešavanja.

Druga ovira skrbi za razvrščanje virtualnih strojev za nekatere razrede paketnih obdelav,

kot je visoko zmogljivo računalništvo (angl. high performance computing – HPC).

Priložnost premagati oviro predstavlja »skupno razvrščanje« (angl. gang scheduling) za

računalništvo v oblaku.

Skalabilno skladišče. Najpomembnejše lastnosti računalništva v oblaku že poznamo:

kratkoročna uporaba (zmanjšanje in povečanje skalabilnosti), ni vnaprejšnjih stroškov in

0%

20%

80%

1000 1200 1400

a. Preizkusni rezultati zmogljivosti pomnilnika

Delež (MB/s)

% sk

upne

ga š

tevi

la d

elež

a (M

B/s)

0%

25%

5%

10%

15%

20%

5 15 35 45 55 65 25 75

b. Zmogljivost diska pri pisanju 1 GB datotek

% sk

upne

ga š

tevi

la d

elež

a (M

B/s)

Delež (MB/s)

Slika 3.12 – Histograma zmogljivosti



neomejena kapaciteta na zahtevo. Njihova uporaba pri računanju je jasna, manj jasna pa je

njihova korist pri trajnem skladiščenju.

Med odgovore lahko sodi bogatost povpraševalnih in skladiščnih API-jev, ponujena

jamstva izvedljivosti in zapletenost podatkovnih struktur, ki so direktno podprte s strani

skladiščnega sistema. Priložnost v raziskavi predstavlja ustvarjanje skladiščnega sistema,

ki bo izpolnjeval te zahteve in jih kombiniral z oblačnimi prednostmi – upravljanje

skalabilnosti, trajnost podatkov in visoka razpoložljivost.

Programske napake v veliko skalabilnih distribuiranih sistemih. Eden izmed

najtežavnejših izzivov je odstranjevanje napak v veliko skalabilnih distribuiranih sistemih.

Pogost pojav je, da teh napak ni možno reproducirati v manjših konfiguracijah, kar

pomeni, da se mora razhroščenje zgoditi v proizvodnih podatkovnih centrih.

Ena priložnost je zanašanje na virtualne stroje v CC.

Hitra skalabilnost. Način plačaj-dokler-uporabljaš zagotovo velja za hrambo in omrežje.

Pri računanju je ta način nekoliko drugačen, odvisen od nivoja virtualizacije. Priložnost je

avtomatsko povečanje in zmanjšanje skalabilnosti kot odgovor obremenitve z namenom

prihranka denarja, vendar brez kršitve sporazuma o ravni storitev. Drugi razlog za

skalabilnost je ohranitev virov. Nedejavni (angl. idle) računalnik uporablja dve tretjini moči

zaposlenega računalnika. Hitro in enostavno orodje za posnemanje trenutnega stanja ter

ponovnega zagona je lahko rešitev za ohranjanje računalniških virov.

Ugled usodnega deljenja. Ugled se ne da virtualizirati. Slabo vedenje ene stranke lahko

vpliva na oblak kot celoto. Priložnost bi bila ustvaritev storitev za varovanje ugleda, ki so

podobne zaupnim elektronskim poštam (angl. trusted email) (26).

Licenciranje programske opreme. Trenutne licence programske opreme omejujejo

izvajanje programskih oprem na določenih računalnikih. Veliko ponudnikov CC se zanaša

na odprtokodno programsko opremo, ker licenčni model ni najboljša rešitev za CC.

Primarna priložnost je nadaljna uporaba odprtokodnih rešitev. Za komercialne cilje naj

podjetje spremeni svojo licenčno strukturo, da se bolj ujema s standardi računalništva v

oblaku.

4 KONVERGENCA STORITVENO USMERJENE ARHITEKTURE IN RAČUNALNIŠTVA V OBLAKU S t r a n | 67


4 4 KONVERGENCA STORITVENO USMERJENE ARHITEKTURE IN


Dve sili, ki imata znano velikost in usmerjenost delovanja ter vplivata z istim namenom na

objekt, dajeta očiten rezultat. Dejanska vrednost računalništva v oblaku predstavlja

zmožnost uporabe storitev, podatke in procese, ki lahko obstajajo zunaj požarnega zida v

nekem podatkovnem centru. Storitveno usmerjena arhitektura pa ponuja arhitekturno

ozadje za učinkovito načrtovanje teh storitev, podatkov in procesov. Določiti je treba še,

katere storitve, informacije in procesi so ustrezni kandidati za obstoj v oblaku. Tako SOA v

kombinaciji z računalništvom v oblaku ponuja utemeljen poslovni predlog.

Okolje oblaka, kot že vemo, ponuja potencialne prednosti znotraj podjetja (npr. privatni

oblak za upravljanje testiranja produktov) ter zunaj podjetja (npr. javni oblak za hitrejše

ponujanje novih funkcionalnosti in agilnost). Prednosti se lahko nanašajo na skalabilnost,

fleksibilnost, plačaj-dokler-uporabljaš ter časovno hitrejšo pridobitev vrednosti.

Veliko strokovnjakov se strinja s tem, da premik k oblaku zahteva konkretno storitveno

usmerjeno arhitekturo za zagotovitev potrebne infrastrukture za učinkovito oblačno

implementacijo.

Strinjamo se, da je oblak dober način za razporeditev storitev v okolju SOA. SOA in oblak

se medsebojno podpirata, vendar ne podpirata iste ideje: računalništvo v oblaku je

namestitvena arhitektura, in ne arhitekturni pristop za načrtovanje IT, kot je SOA.

68 | S t r a n 4.1 SOA za računalništvo v oblaku


Neposredno korist kombinacije SOA in CC predstavlja čas. Doseg oblaka za poslovne ali

tehnične sposobnosti omogoča pobudi SOA stisniti čas v vrednost (Slika 4.1). Dolgoročni

pomen je izboljšano sodelovanje, odjemalsko zadovoljstvo in rast poslovanja.

Kot rezultat združevanja računalništva v oblaku in SOA se pojavi pojem podjetniško

računalništvo v oblaku (angl. Enterprise Cloud Computing). Podjetniško računalništvo v

oblaku predstavlja uporabo komercialnih in internetnih oblačnih tehnologij, ki so

osredotočene na računalniške potrebe enega podjetja (36). Takšno računalništvo je

nadzorovano in notranje mesto, ki ponuja hitro in fleksibilno rezerviranje računalniške

moči, shrambe, programske opreme in varnostnih storitev.

V nadaljevanju prikažemo, kako se računalništvo v oblaku in SOA medsebojno

dopolnjujeta, opišemo prekrivanje med SaaS in SOA ter predstavimo, kako SOA uporablja

računalništvo v oblaku za doseganje bolj učinkovitih rešitev.

4.1 SOA za računalništvo v oblaku

Storitvena arhitekturna rešitev je sestavljena iz povezanih množic poslovnih storitev, ki

realizirajo končni poslovni proces. Gledano z višjega nivoja SOA omogoča izboljšano

upravljanje, vidnost in metrike za poslovne procese. Preden so storitve ponujene v oblaku,

je treba izpolniti določene zahteve z namenom doseganja prednosti uporabe računalništva

v oblaku. V primeru že implementirane SOA je večina odločitev že narejenih (37) (24)

(25):

Slika 4.1 – Vrednost medsebojnega delovanja SOA in CC

€

4.1 SOA za računalništvo v oblaku S t r a n | 69


• Virtualizacija trenutnega okolja z namenom doseganja najbolj stroškovno

učinkovitega okolja. Virtualizacija se nanaša na vodoravni pogled storitev v SOA

čez organizacijo. O podrobnosti in prednosti virtualizacije smo že pisali.

• Podpora ponovne uporabe, kar pomeni, da storitev uporablja več odjemalcev

istočasno. Priporočljiva je uporaba konsistentne namestitvene metodologije za

obravnavo storitev.

• Vodenje in upravljanje storitev. Vodenje je temeljni del arhitekture in je s strani

računalništva v oblaku na splošno prezrt. Nadzor in implementacija politik je

poslovni imperativ, ki mora biti obravnavan pred sprejemom računalništva v

oblaku v podjetje. Zmožnost postavljanja politik okoli storitev in upravljanja

sprememb teh storitev predstavlja kritični faktor uspešnosti. SOA lahko upravlja

spremembe s SOA vodenjem, vendar bi del vodenja moral prihajati s storitvami, ki

prihajajo iz oblaka.

• Razširjanje arhitekture. SOA ponuja ogrodje za uporabo virov računalništva v

oblaku in v svetu oblaka, viri na zahtevo predstavljajo začetno točko. V tem smislu

je najpomembnejše razširjanje SOA iz arhitekture v tehnologijo izven požarnih

zidov podjetja

• Varnost in nadzor dostopa. Zahteva je: dobro definirana varnost in politike

nadzorovanja dostopa (npr. IBM Tivoli Security Policy Manager).

• Poračun in cenitev storitev. Ta oblačna zahteva je tudi ključno SOA področje:

poračun in cenitev storitev z uporabo standardnega industrijskega procesa, kot je

SOA metoda za vodenje in upravljanje (angl. SOA Governance and Management

Method).

Za izvajanje in izkoriščanje storitev v oblaku je seveda treba tudi izpolniti določeno

množico zahtev. Cilj izpolnjevanja zahtev je zagotovo doseganje pričakovane vrednosti

oblaka (37) (25):

• Načrtovanje storitev. Potreben je dober storitveni načrt. Veliko SOA projektov je

naklonjenih gradnji storitev, ki so preveč grobo granularne, preveč fino granularne

ali nasploh niso dobro oblikovane. V praksi se bodo slabo definirane in načrtovane

storitve slabo prodajale na zahtevo.

70 | S t r a n 4.2 IaaS kot infrastruktura za SOA


• Razširljivost storitev. Oblačne storitve so oblikovane tako, da bodo po potrebi

razširljive. Zmožnost razširjanja storitev znotraj SOA je običajno boleč in drag

proces.

• Enostaven dostop do storitev. Ključen vrednostni predlog za oblak, ki je ponujen

preko uporabniškega vmesnika (npr. IBM WebSphere Portal).

• Visoka razpoložljivost storitev. Uporaba storitev mora biti hitra in visoko

razpoložljiva z nižjimi stroški.

• Odkritost storitev. Za uporabo storitev je najprej potrebna odkritost te storitve, ki

predstavlja ključno sposobnost, ponujeno z registrskim produktom (npr. IBM

WebSphere Service Registry and Repository).

• Varnost in privatnost podatkov. Ključna zahteva je tudi vzpostavitev varnosti in

privatnosti podatkov (npr. IBM WebSphere DataPower SOA Appliance).

Tako smo zagotovili, da oblak in SOA delujeta skupaj, s čimer ponudita vidnost in vodenje

storitev. Znotraj SOA razlikujemo vodenje v času načrtovanja (definiranje politik za

storitve) in vodenje v času izvajanja (dejanska uporaba politik v prometu). Enako je pri

uporabi storitev iz oblaka. Vidnost in vodenje storitev bosta ponudili odkritost storitev

znotraj oblaka in SOA vodenje za upravljanje življenjskega cikla storitev, razpoložljivih v

oblaku.

4.2 IaaS kot infrastruktura za SOA

V osnovi se infrastruktura kot storitev osredotoča na zagotavljanje IT virov – procesiranje

moči, shramba, podatkovni center, storitve ipd. – na zahtevo. IaaS omogoča podjetju

močno prednost pred konkurenco, ne da bi izgubilo nadzor nad okoljem. V kontekstu SOA

prednost uporabe IaaS pomeni:

• znižanje stroškov strojne opreme

• znižanje stroškov vzpostavitve in vzdrževanja podatkovnih centrov

• olajšano nameščanje SOA infrastrukture

• odpravljanje težav z zagotavljanjem skalabilnosti

4.2 IaaS kot infrastruktura za SOA S t r a n | 71


• izločitev možnosti okvare in neizkoriščenosti strojne opreme

Cilj je poravnati IT z jedrom poslovne strategije. Prvi korak k temu cilju je kontrola

stroškov. Z uporabo IaaS-a in njegovih spremenljivih, vendar mesečno predvidljivih

operativnih stroškov se prihodki bolj natančno ujemajo z mesečnimi IT stroški, namesto s

stroški na letni osnovi.

IaaS omogoča popolnoma nov in bolj pregleden način zagotavljanja sredstev za IT. Danes

je IT »enovrstični element« – znano je, kaj je porabljeno na vseh strežnikih, vse delovne

sile za ohranitev teh strežnikov, vse moči ipd. Vse seštejemo in dodelimo po poslovni

enoti. V modelu IaaS so natančna uporaba in stroški transparentni na ravni virov –

strežniki, operacijski sistemi, licence in shramba. Ker so ta sredstva modularna in

transparentna, lahko IT uporabo bolj tesno poveže z računom, ki ga prejme vsaka poslovna

enota. To ustvarja tesnejšo povezavo med tem, kar poslovna enota potroši, in »storitvijo«,

ki jo prejmejo.

Ena izmed napačnih predstav o IaaS je, da gre, ko se odločamo za takšno izkoriščanje

zunanjih virov, za trajno in »vse ali nič« odločitev. Predstavljamo si, da moramo razširiti

našo infrastrukturo za 10 ali 20 odstotkov v 20 dneh. Če smo se odločili, da bomo kot

pomoč uporabili ponudnika IaaS, nismo niti trajno obtičali v tem načinu niti nismo

postavili precedens za prihodnost. Eden izmed ključnih predlogov infrastrukture kot

storitve predstavlja ne samo hitro povečanje obsega, temveč tudi zmanjšanje ali celotno

odstranjevanje uporabe virov, brez da bi se zavezali kakšnim dolgoročnim pogodbam. Na

kratko, IaaS omogoča (24):

• pripravljen dostop do prekonfiguriranih okolij

• uporabo najnovejše tehnologije za infrastrukturno opremo

• zaščitene računalniške platforme, ki se varnostno spremljajo zaradi vdorov

• ni potreb po kapitalnih investicijah

• zmanjšane stroške, čas in kompleksnost pri dodajanju novih funkcionalnosti in

sposobnosti

Dostop do strežnikov je možen preko navideznih zasebnih strežnikov (angl. Virtual Private

Server – VPS). Z VPS je vse, kar je abstrahirano, strojna oprema. Potencialni problem

navideznih zasebnih strežnikov oziroma infrastrukture kot storitve je nesposobnost



prenašanja varnostne revizije, zaradi česar je neprimerna za funkcije, ki zahtevajo visoko

varnost. Med varnostne izzive sodijo:

• virtualizacija – »break-out« napadi na virtualne stroje, ki so zastrašujoči, vendar

redki

• porazdeljena infrastruktura – porazdeljeno skladišče, ki ga je treba, izprazniti

preden ga spet komu dodelimo, in porazdeljena CPE/RAM, ki ne sme biti

prekomerno dodeljena

Ponudniki IaaS nudijo osnovno zaščito (fizična varnost, perimetrični požarni zidovi,

izenačevanje obremenitve ipd.) ter majhno število ponudnikov, ki se trudijo zagotoviti

večjo stopnjo varnosti. Čeprav prodajalci IaaS težijo k varnejšemu okolju, se varnostna

odgovornost nahaja v samem načinu poslovanja. Pogodba za stranke, ki jo nudi Amazon

Web Services, je glede tega povsem jasna:

»7.2. Varnost. Prizadevamo si, da hranimo Vašo vsebino varno, vendar glede na naravo

interneta ne moremo zagotoviti, da bomo v tem uspešni. V skladu s tem se strinjate, da

izključno Vi nosite odgovornost za ustrezno varnost, zaščito in varnostno kopijo Vaše

vsebine in aplikacij.«

Poleg tega je vprašanje izguba kontrole. Ponudniki, kot je Amazon, zadržijo pravico za

izklop strežnika brez predhodnega obvestila. To pomeni, da so posledice še hujše kot pri

neoblačnem strežniku.

Za primera, ki ponujata IaaS model za učinkovito SOA rešitev, vzemimo Amazon Elastic

Compute Cloud (Amazon EC2) in Amazon Simple Storage Service (Amazon S3). Amazon

EC2 predstavlja preprost vmesnik spletne storitve, ki omogoča pridobitev in konfiguracijo

zmogljivosti z minimalnim trudom. Ponuja popoln nadzor nad računalniškimi viri in

omogoča izvajanje na preizkušenem računalniškem okolju Amazona. Amazon EC2

zmanjša čas, potreben za pridobitev in zagon novih primerkov strežnika, kar omogoča hitro

spreminjanje zmogljivosti. Pri uporabi Amazon EC2 plačamo samo za dejansko uporabo

zmogljivosti. Amazon EC2 ponuja različne močne značilnosti za gradnjo skalabilnih,

poslovnih in na odpovedi odpornih aplikacij, kot jih prikaže Preglednica 4.1.

4.2 IaaS kot infrastruktura za SOA S t r a n | 73


Preglednica 4.1 – Značilnosti Amazon EC2

Značilnost Opis Amazon elastično bločno skladišče (angl. Amazon Elastic Block Store)

Zagotavlja bločne skladiščne prostornine za uporabo s primerki Amazon EC2. Prostornine Amazon EBS so shrambe, ki obstajajo neodvisno od primerkov. Ponuja visoko razpoložljive in zanesljive skladiščne prostornine, ki se lahko navežejo na tekoči Amazon EC2 primerek in izpostavijo kot naprava znotraj primerka. Amazon ESB je še posebej primerna za aplikacije, ki zahtevajo podatkovno bazo ali datotečni sistem.

Več lokacij (angl. Multiple Locations)

Amazon EC2 ponuja možnost za postavitev primerkov na več lokacijah. Lokacije Amazon EC2 so sestavljene iz regij in con razpoložljivosti. Cone razpoložljivosti so ločene lokacije, ki so načrtovane, da bodo izvzete iz napak na drugih conah razpoložljivosti, in omogočajo poceni ter nizkolatenčno povezljivost z drugimi conami v isti regiji. Trenutno je Amazon EC2 razpoložljiv v štirih regijah: ZDA Vzhod (Severna Virginija), ZDA Zahod (Severna Kalifornija), EU (Irska) in pacifiška Azija (Singapur)

Elastični IP naslovi (angl. Elastic IP Addresses)

Elastični IP naslovi so statični IP naslovi, namenjeni za dinamično računalništvo v oblaku. Elastični IP naslov je povezan z računom, in ne z določenim primerkom, kar omogoča nadzor naslova, dokler se ne odločimo za eksplicitno sprostitev. Za razliko od tradicionalnih statičnih IP naslovov elastični IP naslovi omogočajo maskiranje primerka ali izpadov cone razpoložljivosti tako, da programsko usmerijo naš javni IP naslov do katerega koli primerka na našem računu.

Amazon navidezni zasebni oblak (angl. Amazon Virtual Private Cloud)

Amazon VPC je varen in brezhiben most med obstoječo IT infrastrukturo podjetja in AWS (angl. Amazon Web Services) oblakom. Amazon VPS podjetjem omogoča povezati njihovo obstoječo infrastrukturo z množico izoliranih AWS virov preko povezave navideznega zasebnega omrežja (angl. Virtual Private Network) in razširiti njihove sposobnosti upravljanja.

Amazon oblačno opazovanje (angl. Amazon CloudWatch)

Predstavlja spletna storitev za spremljanje AWS oblačnih virov, začenši z Amazon EC2. Strankam zagotavlja vpogled v uporabo virov, operativnih izvedljivosti in vseh povpraševalnih vzorcev – merjenje CPE izkoriščenosti, diskovno pisanje in branje ter omrežni promet.

Samodejna skalabilnost (angl. Auto Scaling)

Omogoča samodejno spreminjanje zmogljivosti Amazon EC2 v skladu s pogoji, ki jih sami določamo. Z uporabo AS zagotovimo, da se število primerkov poveča, ko je povpraševanje veliko in želimo ohraniti izvedljivost aplikacije, ter samodejno zmanjša, ko je povpraševanje nizko in želimo zmanjšati stroške.

Elastično izenačevanje obremenitve (angl. Elastic Load Balancing)

Samodejno distribuira prihajajoči promet aplikacije čez več primerkov Amazon EC2. Elastično izenačevanje obremenitve omogoča večjo toleranco napak v aplikaciji tako, da ponuja potrebno količino zmogljivosti kot odgovor na prihajajoč aplikacijski promet.



Amazon S3 ponuja preprost vmesnik spletne storitve, ki omogoča shranjevanje in

pridobitev katere koli količine podatkov, kadar koli, kjer koli na spletu. Vsem razvijalcem

daje dostop do iste visoko razširljive, zanesljive, hitre in poceni infrastrukture za

shranjevanje podatkov, ki jo Amazon uporablja za svoje globalno omrežje. Storitev stremi

k temu, da maksimizira koristi skalabilnosti in jih prenese razvijalcem. Amazon S3 temelji

na ideji, da je mora biti zagotovljena kakovost internetne shrambe. Funkcionalnost

Amazon S3 je enostavna in robustna: varno in poceni shraniti katero koli količino

podatkov, hkrati pa zagotoviti, da bodo podatki razpoložljivi, ko jih potrebujemo. Amazon

S3 izpolni naslednje načrtovalske zahteve (38):

• Skalabilnost – Amazon S3 je lahko skalabilen v smislu shrambe, deleža zahtev in

uporabnikov in podpira neomejeno število spletnih aplikacij. Skalabilnost je

prednost: dodajanje vozlišč sistemu poveča (ne zmanjšuje) njegovo razpoložljivost,

hitrost, pretok, zmogljivost in robustnost.

• Zanesljivost – trajno shranjuje podatke z 99,99% razpoložljivostjo. Vse odpovedi

mora sistem tolerirati ali popraviti brez kakršnih koli časovnih zastojev.

• Hitrost – Amazon S3 mora biti dovolj hiter, da podpira visoko zmogljive aplikacije.

Latenca na strani strežnika mora biti relativno zanemarljiva v primerjavi z

internetno latenco. Vsako ozko grlo izvedljivosti je enostavno popravljeno z

dodajanjem vozlišč v sistem.

• Poceni – Amazon S3 je zgrajen iz strojne opreme, ki je poceni. Kot rezultat tega je

pogosta odpoved vozlišča norma, in ne sme vplivati na celoten sistem. Mora biti

strojno agnostičen tako, da so prihranki zajeti, ko Amazon nadaljuje z znižanjem

infrastrukturnih stroškov.

• Enostavnost – gradnja visoko skalabilne, zanesljive, hitre in poceni shrambe je

težka. Narediti tako, da bo enostavna za uporabo za katero koli aplikacijo kjer koli,

je še težje. Amazon S3 mora storiti oboje.

Infrastruktura kot storitev ni samo za javne oblake – lahko je osnova za notranjo strategijo

IT dobave. Vse dokler imajo podjetja platformo, kot je VMware za virtualizacijo, notranja

infrastruktura izgleda identično z IaaS ponudnikom. Če želimo odstraniti 30–50 strojev iz

podatkovnega centra za 90 dni, jih zlahka pripeljemo nazaj, ker imamo isto virtualno

4.3 SOA in SaaS prekrivanje S t r a n | 75


platformo. Ta tip hibridnega okolja je okreten, stroškovno učinkovit in zagotavlja pravo

mero nadzora na obeh straneh brez tveganja zaklepa s strani prodajalca (angl. vendor-lock-

in).

Javni oblak je običajno uporabljen za procesiranje moči in shrambe, dobavljenih odjemalcu

na osnovi »plačaj-dokler-uporabljaš«. Privatni oblaki vsebujejo arhitekture, ki so

načrtovane po meri odjemalcev, ki imajo specifične performančne, skladnostne in

skalabilnostne zahteve. Privatni oblak zahteva minimalno visokonivojsko konfiguracijo,

kjer odjemalci sami po potrebi dodajo virtualne stroje. Takšen oblak je ustrezen za

aplikacije in vsebine, ki zahtevajo visoko izvedljivost, skladnost, varnost. Nasprotno pa

statični in netransakcijski podatki niso smiselni za privatne oblake.

V poslovnem svetu priložnost implicira spremembo in sprememba je lahko vedno izziv.

IaaS omogoča hitro spreminjanje, ker omogoča podjetjem hitro dodajanje ali

odstranjevanje infrastrukture in storitev. Medtem ko lahko hitre spremembe vplivajo na

stabilnost, lahko z uporabo IaaS-a dodamo našemu IT okolju takšne moči, ki so že stabilne

in pripravljanje za uporabo.

4.3 SOA in SaaS prekrivanje

Filozofijo SaaS-a smo že odkrili. Rečemo lahko, da so postavitve SaaS generatorji

prihodkov poslovanja in so neposredno namenjene končnim uporabnikom, medtem ko so

postavitve SOA ustvarjene znotraj IT okolij in so storitve, ponujene aplikacijam, in ne

končnim uporabnikom. SaaS in SOA sta si v naravi zelo komplementarni. Dejansko ne

moreta obstajati ena brez druge.

Če povzamemo iz prejšnjega poglavja, vsaka SaaS platforma bi morala imeti naslednje

poglavitne elemente: večnajemništvo, naročanje in rezerviranje, avtentikacija in

avtorizacija uporabnikov, katalog storitev in cenitev, spremljanje storitev, SLA

upravljanje, merjenje uporabe, zaračunavanje in plačila. Poleg tega SaaS podpira tudi

običajne poslovne funkcije, kot so trženje, prodaja, podpora odjemalcev, upravljanje

prihodkov in financ, poslovna inteligenca in ipd.

76 | S t r a n 4.3 SOA in SaaS prekrivanje


Za platformo SOA lahko trdimo, da je sestavljena iz ponudnikov in odjemalcev storitev.

Ponudniki ponujajo storitve, ki jih uporablja več odjemalcev. Tukaj je pomembno omeniti

storitveno vodilo, komunikacijske protokole (SOAP), definicijo vmesnikov storitev

(WSDL), storitveno odkritje (angl. Universal Description Discovery and Integration) ipd.

Razumljivost spremljanja, upravljanja in vodenja storitev seveda ni zadosten pogoj v

podjetniških okoljih. Pri tem so pomembni stroški, povezani z gostovanjem in

izpostavljanjem storitev, kar zahteva ustrezno upravljanje. Prav tako so pri javnem

izpostavljanju storitev prisotne varnostne zadeve. Vse to pripelje do potrebe upravljanja

storitvenega kataloga, rezervacije, avtentikacije, avtorizacije ipd. Ti elementi pa so del

platforme SaaS (Slika 4.2). Takoj, ko postavitev SOA odraste, se pojavi potreba po

funkcijah platforme SaaS (39).

Vsaka platforma SaaS potrebuje možnost za dodajanje novih storitev in spreminjanje

obstoječih z minimalnimi spremembami arhitekture. Vse osnovne funkcije SaaS-a bi

Slika 4.2 – Prekrivanje med SaaS in SOA

SaaS

SOA

Večnajemništvo

Katalog storitev Rezerviranje

Spremljanje storitev in

Upravljanje naročil

Avtentikacija in avtorizacija

Upravljanje

Zaračunavanje

Merjenje Poravnava

Abstrakcija

Vodenje

Storitveno vodilo

Ponovna uporaba

Dinamično odkritje

Orkestracija

Register

Definicija vmesnikov

Plačila

Upravljanje prodaj

Upravljanje prihodkov in financ Podpora odjemalcev

Poslovna inteligenca

Trženje

Zbirke Kanali

4.4 Elementarna metodologija za razvoj SOA rešitev v oblaku S t r a n | 77


morale biti ponovno uporabljene za druge kompleksne storitve. Vsekakor ponovna uporaba

zahteva platformo SOA. Nadalje, SOA zagotavlja fleksibilnost in s tem tudi nižje stroške.

Intuitivno, večina kompleksnih arhitektur, vključno z arhitekturo SaaS, bo zaslužila z

uporabo sposobnosti SOA, vendar ni tako intuitivno, da platforma SOA potrebuje

sposobnosti SaaS-a. Z namenom uresničevanja vseh koristi veliko skalabilnih postavitev

SOA je treba imeti upravljalsko storitev, kot je SaaS. To je točka, kjer lahko SOA in SaaS

omogočita koncept »IT kot storitev« in korak naprej k evoluciji IT-ja (39).

4.4 Elementarna metodologija za razvoj SOA rešitev v oblaku

Dajanje informacij, storitev in procesov zunaj podjetja brez jasne strategije ni najbolj

produktivno. Elementarna metodologija, ki razširja arhitekturo za oblak, vključuje

definiranje podatkov, storitev, procesov in vodenje. Izmed njih je treba določiti kandidate,

ki bodo obstajali v oblaku, in tiste, ki bodo vzdrževani lokalno.

4.4.1 Definiranje podatkov

Najprej moramo imeti dobro arhitekturno osnovo, da lahko SOA uporablja računalništvo v

oblaku. Razumevanje podatkov zahteva definiranje vseh ustreznih metapodatkov znotraj

kandidatne aplikacije, bodisi nove bodisi stare, ki jo želimo dodati v oblak. Definirati je

treba, kje se podatki trenutno nahajajo, podatkovno strukturo, logični in fizični model,

varnostne zadeve ipd. Tako dobimo metapodatkovni nivo in skupni informacijski model

(Slika 4.3). Definiranje informacijskega modela je zapleteno delo, ker je veliko obstoječih

sistemov zastarelih ali lastninskih. V drugem primeru se bomo mogoče ukvarjali s sistemi,

ki niso še zgrajeni, vendar potrebujejo enako analizo.

Zelo pomembna je identifikacija semantike in metapodatkov. Aplikacijska semantika

določa način in obliko obnašanja določene aplikacije do lastnosti poslovnega procesa.

Metapodatki pa predstavljajo podatke o podatkih. Odgovorijo, kako so podatki opisani,

posedovani, zaščiteni in vodeni v različnih sistemih.

78 | S t r a n 4.4 Elementarna metodologija za razvoj SOA rešitev v oblaku


Ustvarjanje informacijskega

modela Razumevanje

ontologij

Razumevanje podatkov

Ustvarjanje kataloga podatkov

Gradnja informacijskega

modela

Zapuščinski metapodatki

Zunanji metapodatki

Informacijski model

Katalog podatkov

Ontologij

Podatkovni slovar in metapodatki

Ukvarjati se s SOA, ki uporablja računalništvo v oblaku, pomeni, da se ukvarjamo z veliko

kompleksnostjo. Ontologije pomagajo pri pripravi generalizacij, ki naredijo problemsko

področje bolj razumljivo. Za razliko od abstrakcije generalizacija ne upošteva veliko

podrobnosti in poda splošne ideje. Z ontologijo dejansko definiramo razmerje med

koncepti oziroma podatki (25).

Ena izmed prednosti uporabe ontologije je razumevanje in sistematično povezovanje

ustreznih informacij ne glede na lokacijo, kjer so shranjene. Prikazovanje podatkov na

smiselni način omogoča arhitektu razumevanje pomena in konteksta informacije v celoti.

Implementacija oblačne rešitve zahteva več kot premik in vzdrževanje podatkov znotraj

sistemov problemskega področja. Uspešna rešitev zahteva določitev načina, kako

informacije tečejo skozi podjetja in kako so informacije povezane s ključnimi storitvami

in poslovnimi procesi. Zaradi tega potrebujemo podrobnosti za obstoječe podatke ali za

podatke, ki so del novega informacijskega sistema. Potrebujemo osnovno znanje za

odločitev, ali naj informacije in sistem bivajo v oblaku.

Podatkovni slovar in katalog sta del informacijskega modela. Podatkovni slovar predstavlja

centraliziran repozitorij informacij o podatkih, kot so pomen, razmerje do drugih podatkov,

poreklo, uporaba in format. Večjo izvedbo podatkovnega slovarja predstavlja podatkovni

katalog. Razlika med njima je, da podatkovni slovar zajema podatke za en sistem ali

aplikacijo, podatkovni katalog pa zajema vse sisteme znotraj problemske domene.

Slika 4.3 – Proces ustvarjanja informacijskega modela



Informacijski model predstavlja zadnjo fazo gradnje naše podatkovne arhitekture za SOA,

ki uporablja računalništvo v oblaku. Informacijski model lahko izrazimo z ustvarjanjem

logičnega in fizičnega modela, ki sta tehnološko in platformsko neodvisna.

4.4.2 Definiranje storitev

Razumevanje storitev smo že obravnavali, vendar se moramo tukaj odločiti, katere storitve

bodo v oblačnem sistemu in katere bodo shranjene v lokalnem sistemu (Slika 4.4).

Definirati je treba spletne storitve, transakcije ali API-je, ki so izražene v obstoječem

kandidatnem sistemu. Dobimo seznam vseh storitev, podrobno jih analiziramo ter

dokumentiramo in povežemo z informacijskim modelom.

V začetnem stanju arhitekture identificiramo in razumemo vse storitve ter jih »gostimo«

lokalno oziroma oblak je prazen (Slika 4.5). Seznam identificiranih storitev imenujemo

Slika 4.5 – Proces gradnja storitvenega modela

Ustvarjanje storitvenega

modela Razumevanje

storitev

Informacije za storitve

Gradnja storitvenega

modela

Podatkovni katalog

Informacijski model

Storitveni model

Kandidatne storitve

Storitve za informacije

Slika 4.4 – Lokalne in oblačne storitve



kandidatne storitve. Storitve in informacije ustvarijo povezave med kandidatnimi

storitvami in podatki, ki so vezani na storitve. Podatke o storitvah imenujemo metastoritve.

Metastoritve so potrebne za lažje upravljanje, razumevanje in sledenje storitev. Poleg

osnovne informacije, ki nam zagotavlja WSDL, za upravljanje potrebujemo še dodatne

podatke, kot so cilj, avtentikacija, pravila, logika, lastnik, semantika ipd. Ti atributi so

dokumentirani v imeniku storitev. Imenik storitev je začetna točka SOA repozitorja.

Naslednje identificiramo storitve, ki so dobri kandidati za premostitev v oblak, in tiste, ki

lahko ostanejo lokalno. Rezultat je storitveni model (25).

Ko želimo zgraditi rešitve na osnovi SOA in računalništva v oblaku, najboljši pristop

predstavlja šibko sklopljena arhitektura. Treba je razumeti vrednost računalništva v oblaku

in šibke sklopljenosti ter narediti prave odločitve z namenom zagotoviti arhitekturo, ki se

ujema s poslovnimi cilji. Šibko sklopljena arhitektura omogoča zamenjavo ali spremembo

komponent brez dodatnih sprememb drugih komponent arhitekture. Če je arhitektura SOA,

ki uporablja računalništvo v oblaku, pravilno zgrajena, izpad ene same komponente ne bi

smel zavleči kake druge komponente sistema. Šibka sklopljenost se lahko nanaša na

lokacijsko, komunikacijsko in varnostno neodvisnost in neodvisnost primerka.

4.4.3 Definiranje procesov

Razumevanje procesov je potrebno zaradi definiranja visokonivojskih mehanizmov

interakcije. Procesi so lahko avtomatizirani ali delno avtomatizirani in povežejo storitve z

namenom rešiti poslovne probleme. Predpostavimo, da se vsi procesi lokalno vzdržujejo.

Treba je določiti kandidatne procese za oblak in tiste, ki ostanejo lokalno (Slika 4.6).

Slika 4.6 – Lokalni in oblačni procesi



Premostitev procesov je enostaven koncept, kjer se spreminja samo lokacija gostovanja

procesov. Veliko zahtevnejše pa je določanje, katere procese premakniti in kje jih odložiti.

Procesi vplivajo na samo konfiguracijo, in ne na programski pristop definiranja tega

obnašanja, kar pomeni, da je lažje ponovno definirati procese kot storitve. Naslednji korak

metodologije predstavlja proces definiranja procesnega modela. Razumevanje procesov

pomeni njihovo definiranje na višjem nivoju znotraj problemskega področja in dodajanje

na seznam kandidatnih procesov. Definiranje storitev za procese je korak, kjer vežemo

predhodno definirane storitve s procesi z namenom oblikovanja poslovnih rešitev. Gradnja

procesnega modela predstavlja sestavljanje temeljnega pristopa definiranja in gradnje

procesov (Slika 4.7).

Procesi so temelj vrednosti SOA; možnost vstaviti stvari (ki se sčasoma spreminjajo) na

konfiguracijski nivo omogoča poenostavljeno spreminjanje ključnih poslovnih procesov.

Oblačne platforme predstavljajo možnost, kjer ti procesi in storitve lahko bivajo.

4.4.4 Definiranje vodenja

Sedaj se lahko na kratko posvetimo vodenju v računalništvu v oblaku s pomočjo konceptov

storitveno usmerjene arhitekture. Pomen vodenja v svetu SOA smo opisali v drugem

poglavju. Politike v kontekstu SOA in računalništva v oblaku predstavljajo deklarativna

elektronska pravila, ki definirajo, kaj in kdo lahko stori storitvam (25):

• kdo lahko dostopa do storitve

• kaj ji lahko nekdo naredi

Ustvarjanje procesnega

modela Razumevanje

procesov

Storitve za procese

Gradnja procesnega

modela

Podatkovni katalog

Informacijski model

Procesni model

Kandidatski procesi

Storitve za procese

Storitveni model

Slika 4.7 – Proces gradnje procesnega modela



• kako spremembe storitve vplivajo na druge storitve

• kako spremembe storitve vplivajo na aplikacije

• kako vodenje deluje z varnostjo

• kako se vodenje poveže s testiranjem storitev

• kako vodenje deluje z odkritostjo storitev

• kako vodenje deluje z dostavo storitev

• kako postaviti in upravljati ustrezne nivoje storitve

• kako upravljati napake in izjeme

• kako omogočiti spletno posodabljanje in verzioniranje

• kako izvesti validacijo storitve

• kako izvesti revizijo in beleženje

SOA razlikuje dva načina vodenja. Vodenje storitev v času načrtovanja (angl. design time

governance) ponuja integriran register/repozitorij, ki poskuša upravljati storitev od njenega

načrtovanja do njene namestitve. Vodenje storitev v času izvajanja (angl. runtime

governance) predstavlja uveljavljanje in implementiranje politik v času izvajanja storitev.

Vodenje v času izvajanja je pravzaprav proces ustvarjanja politik in njihovo

implementiranje na ustrezno platformo, ki spremlja in nadzira storitve pri izvajanju. Proces

definiranja, načrtovanja in implementiranja politik lahko prikažemo z modelom vodenja

(Slika 4.8).

Ustvarjanje vodenjskega

modela Definiranje

politik

Načrtovanje politik

Implementacija politike

Procesni model

Informacijski model

Vodenje v času izvajanja

Definirane politike

Politični načrti

Storitveni model

Slika 4.8 – Proces gradnje modela vodenja

4.5 IBM prinaša SOA k oblaku S t r a n | 83


Pravila za postavljanje podatkov, storitev ali procesov v oblaku ne obstajajo. Treba je

analizirati atribute in pri tem upoštevati, kateri najbolj ustrezajo za arhitekturo in, seveda,

za poslovanje. Računalništvo v oblaku najbolj ustreza:

• ko so procesi, aplikacije in podatki v veliki meri neodvisni (šibko skopljeni)

• ko so točke integracije dobro definirane

• ko je zadosten nižji nivo varnosti

• ko je jedrna podjetniška arhitektura zdrava

• ko je brskalnik želen uporabniški vmesnik

• ko je denar tesen

• ko so aplikacije ali/in storitve nove

Ko že vemo, kateri podatki, storitve in procesi bodo v oblaku in kateri bodo ostali lokalno,

se osredotočimo na implementacijo fizične arhitekture. Pri tem izberemo ustrezne

platforme, jih testiramo, da bi zagotovili izpolnjevanje naših zahtev, in premaknemo in/ali

ustvarimo procese, storitve in podatke v oblak.

Sklepamo lahko, da obstaja sinergija med SOA in računalništvom v oblaku, ker je

računalništvo v oblaku razširitev SOA na oblačne platforme. SOA, ki uporablja

računalništvo v oblaku, predstavlja najboljši arhitekturni pristop, ki ponuja zmožnost

uporabe računalniških virov z uporabo najboljše možne konfiguracije.

4.5 IBM prinaša SOA k oblaku

IBM ponuja različne programske produkte, ki omogočajo gradnjo učinkovitih SOA rešitev.

Na podatkovnem nivoju ima pomembno vlogo v SOA XML in integracija XML podatkov

v informacijsko infrastrukturo. IBM DB2 V9 omogoča informacijsko osredotočen pristop

do implementacij storitveno usmerjene arhitekture. DB2 dostavlja informacije kot storitev

v SOA okolju. DB2 V9 ponuja hibridno relacijsko/XML shrambo, kjer DB2 obravnava

XML domorodno (angl. natively). Po govoru IBM pureXML kaže na domorodno

obravnavanje XML podatkov v svoji hierarhični strukturi, in ne kot navadno besedilo ali

pretvorjen relacijski format (40). Na vrhu obeh shramb (relacijska in XML) se nahaja

84 | S t r a n 4.5 IBM prinaša SOA k oblaku


hibriden podatkovni stroj, ki lahko procesira XQuery, XPath, SQL in SQL/XML.

Shranjevanje relacijskih in XML podatkov zagotavlja fleksibilnost in dosledno hitro

izvedljivost (41).

Za gradnjo storitvenih in procesnih modelov IBM ponuja IBM WebSphere Integration

Developer V7 (WID). WID poenostavi integracijo in pospeši sprejem SOA tako, da

interpretira trenutna IT sredstva kot storitvene komponente za ponovno uporabo in

učinkovitost. WID predstavlja razvojno okolje za gradnjo integriranih aplikacij na osnovi

SOA in SCA. IBM WebSphere Integration Developer ima dve primarni vlogi (Preglednica

4.2). Pomembna koncepta integracijskega razvijalca (angl. Integration Developer) sta

modul in knjižnica. Modul je projektni tip poslovne integracije za gradnjo aplikacije na

osnovi SCA. Modul je tudi osnovna namestitvena enota v izvajalnem okolju. Modul lahko

vsebuje SCA vire, J2EE in Java projekte, odvisne knjižnice in druge poslovno integracijske

artefakte (BPEL, vmesnike, XSD ipd.). Knjižnica je projektni tip poslovne integracije za

shrambo artefaktov, ki so porazdeljeni med več modulov. Knjižnica ni namestitvena enota

in lahko vsebuje: vmesnike, poslovne objekte, razmerja in spletne storitve.

Preglednica 4.2 – Vlogi IBM WebSphere Integration in Application Developerja

Vloga Opis

Integration Developer

• osredotoča se na gradnjo storitveno usmerjenih rešitev

• pričakuje avtorska orodja za poenostavitev in abstrakcijo naprednih

implementacijskih podrobnosti

• seznanjen z osnovnimi programskimi koncepti

o zanke, pogoji, manipulacija z nizi ipd.

Application Developer

• pozna eno ali več razvojnih platform aplikacije (J2EE)

• osnovno razumevanje SOA, koreografija procesov, delovni tok,

koncepti WSDL in BPEL

• implementira ustrezno poslovno logiko za integrirane rešitve

• izpostavlja aplikacijsko logiko kot storitev

Implementacija SCA v različici 7 se je značilno spremenila, vključno s pakiranjem,

namestitvijo, generiranjem kode in validacijo. Eden izmed ciljev spremembe je pridobitev

večje kompenzacije znotraj SCA aplikacije tako, da je ponujena paradigma plačaj-dokler-

uporabljaš. Najbolj pomemben cilj je izboljšava celotne izvedljivosti.



Ozadje delovanja IBM WebSphere Integration Developer skupaj z IBM WebSphere

Process Serverjem smo predstavili v drugem poglavju.

IBM ponuja učinkovito oblačno okolje za SOA rešitve. Ideja je odjemalcem ponuditi

oblak, ki je sestavljen iz treh komponent, ki jim omogočajo premik storitveno ustvarjalnih

okolij v upravljalskih okoljih. WebSphere oblak kombinira fleksibilnost SOA in

prilagodljivost oblačnih storitev. Takšna rešitev podjetjem omogoča bolj učinkovito

upravljanje zapletenih aplikacij in storitev ter doseganje stroškovne uravnoteženosti s

konsolidacijo in upravljanje obstoječih virov in aplikacij v temeljih SOA.

WebSphere oblak je sestavljen iz treh komponent (42):

• IBM WebSphere Application Server Hypervisor Edition virtualne slike. Vsaka

Hypervisor Edition slika vsebuje operacijski sistem in nameščen ter konfiguriran

primerek aplikacijskega strežnika. Slike so uporabljene s strani naprave za

ustvarjanje virtualnih strojev in njihovo razporeditev na oblaku. Virtualne slike so

shranjene v formatu OVF, o katerem smo že pisali.

• WebSphere CloudBurst je strojna naprava, ki skrbi za IBM WebSphere Application

Server (WAS) topologije na oblačno virtualizirani strojni opremi. Naprava vsebuje

slike in vzorce WAS-a. Upravljamo jo z uporabo brskalnika ali ukaznih orodij.

• Privatni oblak gosti virtualne sisteme, ki so upravljane s strani WebSphere

CloudBursta.

IBM WebSphere Application Server Hypervisor Edition (WASHE) razvijalcem in IT

arhitektom ponuja inovativen in aplikacijsko izvedljiv temelj za gradnjo, namestitev ter

upravljanje robustnih, agilnih in ponovno uporabnih storitev in SOA aplikacij. WASHE

inteligentno in aktivno upravlja z aplikacijsko infrastrukturo in hkrati optimizira stroške.

Ponuja vse robustne značilnosti družine WebSphere Application Server:

• Inovacijska osnova – obsežna množica odprtostandardnih programskih modelov:

Web 2.0, Session Initiation Protocol (ISP), SCA, SDO in Java Persistence API.

WASHE je zgrajen na osnovi inovativnega modela virtualne naprave. Virtualna

naprava je slika virtualnega stroja, ki teče na virtualizacijsko platformo (Vmware

ESXi). Z virtualno napravo se izogibamo namestitvenih, konfiguracijskih in

vzdrževalnih stroškov.



• Visoka izvedljivost – WASHE ponuja hitro, varno, skalabilno in zanesljivo okolje.

Nadalje, izboljša izvedljivost s povečanjem učinkovitosti podatkovnih centrov

preko konsolidacije delovnih obremenitev.

• Poenostavljen razvoj – poenostavi razvojno okolje in poveča produktivnost

razvijalcev. Ponuja izboljšano podporo za standarde, nastajajoče tehnologije in

izbiro razvojnih ogrodij.

• Inteligentno upravljanje – fleksibilen in učinkovit nadzor aplikacije. Inteligentno

upravljanje vključuje: rezerviranje v izvajalnem času in OSGi (angl. Open Service

Gateway) tehnologijo za dinamično označevanje le potrebnih funkcij, izboljšano

administracijo, izboljšano upravljanje večkomponentnih aplikacij s pomočjo

WebSphere Business Level Application (WBLA) ipd.

Preglednica 4.3 – Značilnosti in prednosti WAS Hypervisor Edition

Značilnost Prednost

Predhodno konfigurirana virtualna slika, ki

vključuje operacijski sistem Novell SUSE Linux

• namestitev WebSphere Application Serverja ni

potrebna

• nabava in namestitev operacijskega sistema ni

potrebna

• upravljan in podprt s strani IBM-a

Podpora standarda OVF • takoj zagnan v vrhovnem nadzorniku (angl.

hypervisor)

Vmware ESX, ESXi podpora • izkoriščati vodilni nadzornik za industrijsko

standardne strežnike x86

Podpora za različici V7 in V6.1 WebSphere

Application Serverja

• prosta izbira

IBM WebSphere CloudBurst Appliance je fizična naprava, ki namesti in upravlja

virtualizirana okolja. Administrativne sposobnosti naprave so porazdeljene v štiri razdelke:

katalog, vzorci, oblak in virtualni sistemi (Slika 4.9). Katalog naprave shrani tri tipe

vsebine: virtualne slike, nujni popravki in skriptni paketi. Ti deli so uporabljeni kot

gradniki za ustvarjanje in prilagajanje namestitvenih topologij WebSphere Application

Serverja. Na razpolago so Hypervisor Edition virtualne slike za različici V7.0 in V.61

aplikacijskega strežnika. Vsaka slika definira namestitveni upravljalec, prirejeno vozlišče

ali samostojni aplikacijski strežnik, ki so uporabljeni za gradnjo vzorcev. Slika vsebuje



operacijski sistem, binarne datoteke aplikacijskega strežnika, informacije profila in HTTP

strežnik. Slike so prilagodljive, kar pomeni, da lahko vključimo lastno prirejene datoteke

ali namestimo dodatno programsko opremo. Proces prilagajanja imenujemo slikovna

razširitev. Nujni popravki predstavljajo vzdrževalne pakete, ki jih lahko uporabijo virtualni

sistemi s pomočjo naprave. Ponujeni so paketi nujnih popravkov za aplikacijski strežnik in

obstoječi operacijski sistem virtualne slike. Če je treba uporabiti prilagojene vzdrževalne

pakete, lahko ustvarimo lastne generične pakete popravkov in jih upravljamo z

vzdrževalnim mehanizmom naprave. Skriptni paketi so uporabljeni za prilagajanje

namestitvenih vzorcev WebSphere Application Serverja. Vsebujejo lahko skripte wsadmin,

skripte operacijskega sistema ali kakšne druge programe (42).

Vsebina iz kataloga je uporabljena za ustvarjanje vzorcev, ki opišejo topologije

aplikacijskega strežnika, ki jih želimo namestiti na oblaku. Osnova vzorca je virtualna

slika, zgrajena iz skupine delov virtualne slike. Deli so definirani v virtualni sliki, kot je

namestitveni upravljalec, prirejeno vozlišče ali samostojni aplikacijski strežnik. Ko so deli

virtualne slike dodani v vzorec, jih lahko prilagodimo z uporabo skriptnih paketov.

Administrator strežnika

Odejmalec strežnika

Spremljanje in upravljanje

Katalog Vzorci Oblak Virtualni sistemi

Namestitveni upravljalec Namestitveni

upravljalec

Namestitveni upravljalec Namestitveni

upravljalec

Namestitveni upravljalec

Prirejeno vozlišče Prirejeno

vozlišče

Prirejeno vozlišče

Prirejeno vozlišče Prirejeno

vozlišče




Samostojni strežnik

Samostojni strežnik

Upravljalec posla

Admin agent HTTP strežnik

HTTP strežnik HTTP strežnik

HTTP strežnik

Virtualne slike

Prednaloženi vzorci

Prilagojeni vzorci

V7.0

V6.1

Nujni popravki

Skriptni paketii

Virtualen sistem

Definiranje virov

Namestitev

Slika 4.9 – Namestitveni model WebSphere CloudBurst



Naprava vsebuje nekaj prednaloženih vzorcev, ki predstavljajo standardne industrijske

najboljše prakse, kot je recimo gručenje. Na sliki sta prikazana dva vzorca. Zgornji vzorec

je eden izmed prednaloženih vzorcev in je običajno uporabljen za testiranje v gručnem

okolju; vsebuje namestitveni upravljalec, ki upravlja dve prirejeni vozlišči. Spodnji vzorec

je prirejen vzorec, ki vsebuje HTTP strežnik in skriptni paket v povezavi z namestitvenim

upravljalcem.

Viri oblaka – vrhovni nadzorniki, omrežni viri, IP naslovi in pomnilnik – obstajajo zunaj

naprave, vendar jih definiramo v konfiguraciji naprave. Obstajajo tri oblačne komponente,

ki je treba definirati: IP skupine, vrhovni nadzorniki in oblačne skupine. Oblačna skupina

je množica vrhovnih nadzornikov. Oblačna skupina mora biti povezana z IP skupino –

bazen razpoložljivih IP naslovov, ki so lahko dodeljeni virtualnem sistemu –, preden

namestimo kak vzorec. Ko nameščamo vzorec, izberemo oblačno skupino kot cilj

nameščanja. Potem naprava samodejno postavi virtualne sisteme na ustreznem vrhovnem

nadzorniku znotraj te oblačne skupine in dodeli IP naslove iz povezane IP skupine na

virtualnem sistemu.

Ko je vzorec nameščen, je ustvarjen virtualni sistem. Virtualni sistemi so sestavljeni iz

več virtualnih strojev, ki tečejo na vrhovnih nadzornikih v oblaku. Virtualni sistem

predstavlja popolno funkcionalno in konfigurirano okolje WebSphere Application

Serverja. Primer na sliki prikaže namestitev prirejenega vzorca, sestavljenega iz

namestitvenega upravljalca s skriptnim paketom, dveh prirejenih vozlišč in primerka

HTTP strežnika. Ko je že nameščen, vsi deli virtualne slike dobijo svoj primerek v

virtualnih strojih. HTTP strežnik je konfiguriran, da prestreza promet, ki prihaja v

namestitveni upravljalec. Prirejeni vozlišči sta združeni v celici namestitvenega

upravljalca. Ko so virtualni stroji že ustvarjeni, namestitveni upravljalec izvaja z njim

povezane skriptne pakete. Naprava ponuja spremljanje in upravljanje sposobnosti

nameščenih virtualnih sistemov ali pa standardni način administracije preko

administrativne ukazne mize.

5 STORITEV ZA ZDRAVSTVENO OSKRBO PACIENTOV S t r a n | 89


5 5 STORITEV ZA ZDRAVSTVENO OSKRBO PACIENTOV

»Bona valetudo melior est quam maximae divitae.«19

Zdravstvena oskrba ima diagnozo za svoje težave: neučinkovitost. Toda ozdravitev ni tako

enostavna. Čeprav organizacije postajajo bogate z informacijami, ostanejo še vedno revne

z znanjem, brez ustreznih orodij za boljšo integracijo podatkov v klinične, operativne,

raziskovalne in finančne sisteme. Vendar si raje domišljamo, kako narediti pametnejši

sistem za zdravstveno oskrbo, kot da bi se osredotočili na iskanje napak v zdravstveni

oskrbi.

Pametnejši pristop za zdravstveno oskrbo je uporaba informacije za ustvarjanje realnega

vpogleda v oskrbo pacienta in učinkovitost organizacije. Pametnejše delo vključuje

ustvarjanje razumljivih in celovitih pogledov v pacientove podatke.

Inovatorji vlagajo veliko truda, da povežejo zdravnike, paciente in zavarovatelje z

namenom gladkega in varnega medsebojnega deljenja informacij. To pomeni, da je

pametnejši sistem zdravstvene oskrbe optimiziran okoli pacienta z namenom povečati

učinkovitost, zmanjšati stroške, doseči kakovostnejše rezultate in rešiti več življenj.

Naša storitev za zdravstveno oskrbo streže tej viziji. V nadaljevanju opisujemo konkretno

problemsko področje, gradnjo arhitekturne rešitve in delne implementacije storitve

oziroma aplikacije.

19 Dobro zdravje je več vredno kot največjo bogatstvo.

90 | S t r a n 5.1 Problemsko področje


5.1 Problemsko področje

Raziskovanje se je začelo s področjem Zdravje 2.0 (angl. Health 2.0), ki predstavlja

povezavo med zdravstveno oskrbo, elektronskim zdravjem in Splet 2.0 (angl. Web 2.0).

Ožja definicija pravi, da je Zdravje 2.0 specifična množica spletnih orodij (blogi,

predvajanja, označevanja, Wikipedia ipd.), uporabljena s strani zdravnikov, pacientov in

znanstvenikov z namenom generiranja vsebin z njihove strani in s pomočjo spleta tako, da

personalizirajo zdravstveno oskrbo, medsebojno sodelujejo ter spodbujajo zdravstveno

izobraževanje (43). Iz tega vidika je nastal osrednji kocept našega področja – pacient in

njegovo opolnomočenje.

Opolnomočenje pacienta predstavlja spodbujanje državljanov k aktivnemu sodelovanju pri

upravljanju njihovega zdravja. Opolnomočenje smatramo kot filozofijo zdravstvene

oskrbe, ki izhaja iz vidika, da so optimalni rezultati zdravstvenih intervencij doseženi, ko

postanejo pacienti aktivni udeleženci v procesu zdravljenja. Zaradi tega smo idejno

razmišljanje usmerili k pacientu in njemu koristnim funkcionalnostim.

5.2 Ideja

Ideja je ponuditi pacientu možnost za aktivno in lastno vodenje različnih evidenc

njegovega zdravstvenega stanja, elektronsko ustvarjanje lastnega zdravstvenega zapisa,

pregled zgodovinskih podatkov o zdravju, sodelovanje v skupnosti, elektronsko

komunikacijo z različnimi zdravniki ipd. Ideja je ponuditi interoperabilno in inteligentno

rešitev, ki bo prispevala k pametnejšemu zdravstvenemu sistemu.

Projekt smo poimenovali heJump, z razlago, da gre za storitev za zdravstveno oskrbo

pacienta (angl. Patient Healthcare Service). Storitev je osredotočena na pacienta,

neposreden rezultat pa je kakovostnejše življenje pacienta: opremljenost z znanjem za

upravljanje lastnega stanja, omogočena izbirnost glede samopomoči ter spoštovanje teh

izbir, usposobljenost, pacient kot strokovnjak, ki lahko izboljša svoje zdravstveno stanje in

stanje ostalih z ocenjevanjem, lažje spoprijemanje s splošnimi značilnostmi kroničnih

5.2 Ideja S t r a n | 91


bolezni ter manjša odvisnost od bolnišnične oskrbe. Zasnova heJumpa predstavlja miselni

premik, pri čemer ima zdravje osrednjo vlogo (Slika 5.1). Osnovne funkcionalnosti, ki jih

omogoča storitev heJump, so:

• registriranje, ustvarjanje in posodabljanje osebnega zdravstvenega zapisa (angl.

Personal Health Record – PHR)

o registracija zagotavlja varno in zanesljivo ohranjanje lastnih podatkov

o ustvarjanje osebnega zdravstvenega zapisa z vnašanjem zgodovinskih

podatkov o lastnem in družinskem zdravju

o posodabljanje zapisa z novejšimi podatki

• ustvarjanje urnika jemanja zdravil

o organiziranje zdravil, ki jih je treba jemati

• ustvarjanje koledarja z dogodki

• pošiljanje opomnikov za jemanje zdravil in dogodkov

o na elektronsko pošto

o preko SMS

• pregled podatkov

o povzetek zdravstvenih podatkov

o pregled urnika jemanja zdravil

Opremljenost

Omogočenost

Usposobljenost

Izraženost

Izobraženost

Strokovnost

INFO

RMAC

IJA

ZNAN

JE

Slika 5.1 – heJump poslovni vidik

92 | S t r a n 5.3 heJump arhitektura


o pregled koledarja z dogodki

• izvoz zdravstvenega zapisa

o XML oblika

o PDF oblika

• vključevanje v skupnosti

o ustvarjanje zdravstvenih primerov

o podajanje mnenj

o podajanje povratnih informacij

o ocenjevanje mnenj ali primerov

• posredovanje informacij zdravniku

Storitev za zdravstveno oskrbo pacienta je zamišljena kot spletna aplikacija, ki bo dostopna

neodvisno od lokacije in časa dostopa. Vse informacije so organizirane na enem mestu in

centralno shranjene v oblaku. Na takšen način je pacientu ponujeno idealno mesto za

enkratno shranjevanje podatkov in njihovo večkratno uporabo ter informirano odločanje o

lastnem zdravju.

Rešitev je zasnovana na konceptih storitveno usmerjene arhitekture in njena arhitektura v

celoti obstaja v oblaku.

5.3 heJump arhitektura

Arhitektura aplikacije je bila oblikovana na treh nivojih (Slika 5.2). Prvi nivo predstavlja

uporabniški vmesnik, kjer so definirani moduli, ki omogočajo učinkovito interakcijo med

uporabnikom in poslovno logiko. Vsak modul predstavlja določeno funkcionalnost

aplikacije tako, da je omogočeno učinkovito operiranje in kontrola podatkov. Fleksibilnost

aplikacije je zagotovljena z naslednjim nivojem – nivo poslovne logike, ki loči poslovno

logiko od ostalih nivojev, kot sta podatkovni in uporabniški nivo. Poslovna logika je

predstavljena s funkcionalnimi algoritmi za obdelavo in izmenjavo podatkov, z usmeritvijo

in metodami, s katerimi je zagotovljen dostop do poslovnih objektov. Komponente v

poslovni logiki so medsebojno povezane in omogočajo celovito delovanje storitve. Tretji

nivo pa vsebuje storitve, ki omogočajo poenostavljen dostop do podatkov v podatkovni

5.3 heJump arhitektura S t r a n | 93


bazi. Storitve oziroma metode, ki jih nivo ponuja, abstrahirajo podatkovne klice in s tem

zagotavljajo varnost dostopa ter zaščito podatkov.

V A

R N

O S

T

U P R A V L J A N

J E O P E R A C I J

Modul za registriranje

Modul za ustvarjanje in posodabljanje PHR

Modul za ustvarjanje urnika z dogodki

Modul za pregled PHR

Modul za ustvarjanje urnika za jemanje zdravil

Modul za izvoz podatkov

Modul za pregled urnikov

Modul za upravljanje krvnega tlaka

Modul za upravljanje skupnosti

Modul za komunikacija z zdravnikom

Modul za uvoz podatkov

Upravljanje pacientov

Administracija sistema

Administracija podatkov

Upravljanje urnikov

Obdelava opominov

Upravljanje primerov

Obdelava dogodkov

Upravljanje PHR

Obdelava zdravil

P O S L O V N I O B J E K T I

Pregled podatkov

Uvoz/izvoz podatkov

Pošiljanje obvestila

Obdelava krvnega tlaka

Upravljanje skupnosti

Upravljanje zdravnikov

Komunikacija z zdravnikom

Upravljanje mnenj

Ocenjevanje mnenj

PB

Prezentacijski nivo

Nivo poslovne logike

Podatkovni nivo

Podatkovne storitve

Slika 5.2 – heJump arhitektura



5.3.1 Podatkovni model

Praktični razvoj arhitekturnega načrta začnemo z ustvaritvijo podatkovnega modela.

Pomensko je podatkovni model sestavljen iz dveh delov: pacient in skupnost. V

nadaljevanju opisujemo posamezni del modela.

Zdravje 2.0 se zanaša na interoperabilnost zdravstvenih podatkov. Zaradi tega mora biti

osebni zdravstveni zapis zgrajen na osnovi standarda. Po definiciji je PHR zapis z

zdravstvenimi informacijami, ki ga ustvari in vzdržuje posameznik. Običajno vsebovane

informacije so:

• alergije in neželeni učinki zdravil

• zdravila (vključno z odmerkom in pogostostjo jemanja)

• bolezni in sprejemi v bolnišnici

• operacije in drugi postopki

• cepljenje

• rezultati laboratorijskih testov

• družinska zgodovina

• opazovanje vsakdanjega življenja

Standardizacijo smo izvedli s podmnožico CCR (angl. Continuity Care Record)

standarda20

CCR je sestavljen iz treh delov: glava (angl. header), noga (angl. footer) in telo (angl. body).

Glava vsebuje podatke o uporabljenemu jeziku, različici standarda in datumu ustvarjanja

zapisa. Noga vsebuje osnovne podatke o akterju oziroma pacientu. Mi se osredotočimo na

telesni element, kajti le-ta predstavlja jedro zdravstvenega zapisa. Prilagojena XML shema

CCR standarda je prikazana na naslednji sliki (

. Standard predstavlja množico ključnih podatkov za najpomembnejša

administrativna, demografska in klinična dejstva za zdravstveno oskrbo pacienta. CCR je

pripravljen, prikazan in posredovan na papirju ali v elektronski obliki. Za strukturirani

elektronski format je uporabljena XML shema.

Slika 5.3).

20 Standard je razvit s strani ASTM International, Massachusetts Medical Society, Healthcare Information and Management Systems Society, American Academy of Familiy Physicians, American Academy of Pediatrics idr.



Podrobnosti zdravstvenih podatkov so vsebovane v elementu <Body>. Otroški element

<FunctionalStatus> opiše trenutno zdravstveno stanje uporabnika aplikacije (npr.

noseča, zlomljena noga ipd.) in morebitne rezultate testov. Element <Problems> vsebuje

seznam vseh stanj in simptomov pacienta, vključno z opisom in datumom nastanka stanja.

Naslednji otroški element <SocialHistory> vsebuje podelement, ki navede raso

pacienta. Element <Alerts> vsebuje seznam alergijskih opozoril ter <Medications>

seznam zdravil, ki jih pacient jemlje ali je jemal. Element zdravila vsebuje podatke o

produktu, količini, usmeritvi za uporabo ipd. Imunizacijski element upravlja z

imunizacijami. Elementa <VitalSigns> in <Results> vsebujeta rezultate ustreznih

testov pacienta. Zadnji otroški element <Procedures> vsebuje seznam opisanih

postopkov (operacij), ki so bili izvedeni pacientu.

Definirati je bilo treba ustrezno množico besed, ki jih uporabljamo za standardno

opisovanje določenih atributov zapisa. Dobili smo seznam besednjakov, kot je besednjak o

možnih alergijah, krvnih skupinah, stanjih družine, imunizacijah ipd. Primere besednjakov

prikazuje naslednja preglednica (Preglednica 5.1):

Slika 5.3 – XML shema CCR zapisa



Preglednica 5.1 – Primeri besednjakov

Besednjak Atributi

Allergen Type Animal Medication Food

Environment Plant

Blood Types

A– AB+ O–

A+ B– O+

AB– B+

Family History Conditions

Allergies Diabetes Smoking

Alzheimer's Disease Epilepsy Stroke

Anxiety Eye Condition Substance Abuse

Arhritis High Blood Pressure Suicide

Asthma Heart Disease Tuberculosis

Blood Disorder Lung Disease Ulcer

Cancer Osteoporosis

Depression Psyhiatric Disorder

Za shranjevanje podatkov uporabimo hibridno podatkovno bazo IBM DB2 V9. Osebni

zdravstveni zapis hranimo v XML obliki z ustrezno XSD (angl. XML Schema Definition)

validacijo. Podatke, ki se nanašajo na krvni tlak, urnike in komunikacijo z zdravnikom,

hranimo v tabelarični obliki. Medsebojne povezave prikaže prvi del podatkovnega modela

(Slika 5.4). Modeliranje podatkovnega modela izvedemo z uporabo IBM InfoSphere Data

Architect 7.5.2, ki omogoča tudi transformacijo logičnega modela v fizični model. Fizični

Slika 5.4 – Prvi del podatkovnega modela



model baze prav tako upravljamo z IBM InfoSphere Data Architect.

Podatkovni model skupnosti je v celoti oblikovan kot relacijska podatkovna baza. Sestavlja

ga pet entitet, ki vsebujejo ustrezne podatke o kategoriji razprave, razpravi, pripombah,

uporabnikih skupnosti in njihovih vlogah (Slika 5.5).

Povezava med procesnim nivojem in podatkovno bazo je izvedena s pomočjo storitve

DatabaseService. V nadaljevanju predstavljamo storitveni model naše aplikacije.

5.3.2 Komponentni model

Razvoj arhitekture smo nadaljevali z ustvaritvijo in povezovanjem SCA komponent.

Glavni proces je heJumpProcess, ki je izpostavljen kot fasada aplikacije. Proces ima

partnersko povezavo za vsako poslovno storitev. Identificirali smo devet poslovnih

storitev, ki predstavljajo SCA komponente z javansko implementacijo (Slika 5.6).

Slika 5.5 – Drugi del podatkovnega modela

Slika 5.6 – Sestavni model heJump storitve



Opis funkcionalnosti vsake komponente je podan v spodnji preglednici (Preglednica 5.2):

Preglednica 5.2 – Opisi funkcionalnosti SCA komponente

Komponenta Opis funkcionalnosti komponente

heJumpService Proces predstavlja najpomembnejšo komponento. Izpostavljena

je kot spletna storitev, ki jo kličejo uporabniki. Proces orkestrira

in koreografira operacije k ustreznim storitvam ter skrbi za

pravilen pretok podatkov med uporabnikom in sistemom.

PHRService Storitev v celoti skrbi za upravljanje zdravstvenih podatkov

pacienta. Njen vmesnik vsebuje operacije, ki omogočajo

ustvarjanje, posodabljanje, brisanje in pregled zdravstvenih

podatkov. Podatki so obravnavani v XML obliki.

BloodPressureService Storitev je namenjena krvnemu tlaku. Vhodne podatke ustrezno

obdela in s pomočjo upravljalca podatkovne baze shrani v bazo.

Poleg tega izvede določene analize podatkov o krvnem tlaku in

jih posreduje procesu.

LoginService Storitev je nadzornik dostopa do funkcionalnosti aplikacije.

Upravlja registracijo in prijavo uporabnika. Brez ustrezne

prijave uporaba aplikacije ni možna.

SecondOpinionService Storitev skrbi za zdravstvene primere pacienta. Primer je

posredovan v bazo s pomočjo upravljalca podatkovne baze.

Vprašanja, ki se nanašajo na določen primerek, se prav tako

shranijo v bazo in posredujejo zdravniku. Storitev obravnava

diagnoze, ki jih zdravniki dajejo kot odgovor na vprašanja.

SchedulerService Storitev ustvarja urnike za zdravila in dogodke. V odvisnosti od

zahteve storitev posreduje podatke opomniku. V vsakem

primeru storitev shrani podatke v bazo.

ReminderService Storitev je upravljalec opomnikov za določena zdravila in

dogodke. Občasno preverja stanje opomnika in pacientu pošlje

obvestila v obliki elektronske pošte ali SMS sporočila.

MailService Storitev pomaga upravljalcu opomnikov pri pošiljanju

elektronskih pisem pacientu.



SMSService Storitev pomaga upravljalcu opomnikov pri pošiljanju SMS

sporočil pacientu. Za pošiljanje sporočil je potrebna uporaba

zunanje storitve.

DatabaseService Storitev je pomembna komponenta naše aplikacije. Upravlja z

vsemi podatki, ki jih je treba shraniti v podatkovno bazo.

Vsebuje vse operacije, ki zagotavljajo ustrezno obdelavo

podatkov.

Proces uporablja uvoz DiscussionService, ki predstavlja posebej definirano spletno

storitev. Arhitekturna rešitev vsebuje proces heJumpDiscussionProcess, ki skrbi za

pravilno procesiranje operacij in podatkov, ki se nanašajo na razprave v skupnosti. Proces

ima tudi partnersko povezavo z vsako storitvijo v diagramu. Identificirali smo šest storitev,

ki tudi v tem primeru predstavljajo Java komponente (Slika 5.7). Opis funkcionalnosti

posamezne storitve o skupnosti izpostavimo.

Slika 5.7 – Sestavni diagram heJumpDiscussion storitve

SCA komponente manipulirajo s podatkovnimi objekti v obliki poslovnih objektov. V naši

poslovni rešitvi smo ustvarili poseben modul heJumpLibrary, ki vsebuje določeno

strukturo poslovnih objektov in vmesnikov. Struktura poslovnih objektov nam zagotavlja

razumljivejše in lažje načrtovanje in implementacijo poslovne logike. Struktura je

sestavljena iz osnovnih poslovnih objektov, ki predstavljajo zbirke podatkov iz

podatkovnega modela in poslovnih objektov, ki ovijajo osnovne poslovne objekte. Z

uporabo ovijanih poslovnih objektov zagotovimo spoštovanje poslovnih pravil in

neodvisnost od sprememb v podatkovnem modelu. Primere poslovnih objektov prikažemo

v naslednjem razdelku.



Vsaka komponenta pripada določenemu imenskemu prostoru. V našem primeru je osnovni

imenski prostor http://hejump.cloud.si. Komponente v modulu heJumpLibrary imajo

imenski prostor http://hejump.cloud.si/heJumpLibrary, ki je še razdeljen na tri dele

(/Object, /Wrappers in /Interfaces), s čimer zagotovimo dodatno strukturiranje komponent

oziroma unikatnost imen elementov in atributov.

Vmesnik SCA komponente je neizogiben element, kajti vsebuje vse operacije, potrebne za

praktično uporabo storitve. V našem arhitekturnem načrtu skoraj vsaka operacija vsebuje

tri atribute: vhode, izhode in napako. Objekt napake je tipa BusinessExceptionWrapper, ki

vsebuje dva atributa o imenu napake in njenem opisu.

Vmesnik heJumpInterface storitve heJumpService ima veliko operacij, med katerimi so:

• checkUserCredentials – avtenticira uporabnika

• getPersonInfo – sistem vrne osnovne informacije o avtenticirani osebi

• getProfileEntry – sistem vrne podatke o zdravstvenem profilu uporabnika

• getScheduleList – sistem vrne seznam urnikov

• setBloodPressureEntry – sistem poskrbi za vstavljanje primerka krvnega tlaka

• setMedicationReminder – sistem poskrbi za nastavitev opomnika o zdravilu

• sendQuestion – sistem poskrbi za pošiljanje vprašanja

BloodPressureInterface vsebuje operacijo insertReading, ki sprejme in obdela potrebne

podatke o krvnem tlaku, in analyzeReadings, ki izračuna povprečno sistolično in

diastolično vrednost tlaka ter naredi ustrezne analize. Storitev LoginService ima vmesnik

LoginInterface, ki vsebuje operaciji za registracijo in avtentikacijo uporabnika.

SecondOpinionInterface definira tri operacije: generateCase, ki ustvari zdravstveni primer

o pacientu, askQuestion, ki procesira vprašanje v bazi in ga posreduje zdravniku, ter

retrieveDiagnose, ki poišče ustrezno diagnozo za vprašanje o določenem primeru. Storitev

SchedulerService ima vmesnik SchedulerInterface, ki vsebuje operaciji za ustvarjanje

urnika in sestavljanje seznama vseh aktivnih urnikov. ReminderInterface vsebuje operacijo

setReminder, ki nastavi opomnike za vse dogodke in zdravila, ki obstajajo v pacientovem

5.4 Storitev PHRService S t r a n | 101


Profilu, in občasno preverja, če je treba sprožiti obvestilo. MailInterface in SMSInterface

omogočata pošiljanje kratkih obvestilnih sporočil preko elektronske pošte in SMS sporočil.

Storitev DatabaseService ima vmesnik DatabaseInterface, ki definira vse potrebne

operacije za ustvarjanje, branje, posodabljanje in brisanje zapisov v bazi.

5.4 Storitev PHRService

Za dostop do baze smo uporabili standardni način povezovanja do baze DB2, ki je

prikazan na spodnji izvorni kodi (Izvorna koda 5.1). Naš podatkovni vir je poimenovan

heJumpDS.

Storitev PHRService skrbi za osebni zdravstveni zapis. Storitev ima vmesnik

PHRInterface, ki vsebuje štiri operacije (Slika 5.8). Operacija generatePHR sprejme

vhodni podatek PHRWrapper, ki vsebuje zdravstvene podatke. Za obravnavo XML

Slika 5.8 – Definicija vmesnika PHRService

try{ //get a database connection javax.naming.InitialContext ctx = new javax.naming.InitialContext(); javax.sql.DataSource ds = (javax.sql.DataSource)ctx.lookup("heJumpDS"); java.sql.Connection con = ds.getConnection(); }catch (NamingException e){ System.out.println("Naming exception: "+e.toString()); }catch(SQLException e){ System.out.println("SQL exception: "+e.toString()); } ...

Izvorna koda 5.1 – Povezava do podatovne baze

102 | S t r a n 5.4 Storitev PHRService


vsebine smo uporabili model DOM (angl. Document Object Model). S pomočjo

DocumentBuilderFactory in DocumentBuilder smo ustvarili naš DOM dokument. Nato

smo ustvarili korenski element ContinuityOfCareRecord in razgradili XML drevo s

potrebnimi elementi (Izvorna koda 5.2). DOM podatke smo zapisali v datoteko s pomočjo

uporabe specifičnega Xerces razreda XMLSerializer. Uporabimo ukaz INSERT za vnos

XML datoteke v bazo. Ustvarili smo FileInputStream, kjer posredujemo lokacijo in

dolžino XML datoteke. Tok je posredovan metodi setBinaryStream(), ki učinkovito postavi

vsebino XML datoteke v stolpec xmlphr. Operacija izračuna BMI (angl. Body Mass Index)

s pomočjo formule in podatek posreduje v bazo. Odgovor operacije

predstavlja bodisi uspešno bodisi neuspešno ustvarjanje zapisa.

Naslednja operacija modifyPHR z uporabo izjave UPDATE ustrezno spremeni podatke, ki

jih je pacient dodal k svojemu profilu. Pri tem je bilo treba validirati XML dokument.

Zaradi tega smo najprej smo morali registrirati XML shemo z bazo DB2. Z uporabo

čarovnika je bil proces registracije dokaj enostaven. Registrirana XML shema je bila

HEJUMP.CCRSCHEMA. Nato smo k stavku INSERT dodali funkcijo XMLValidate, ki

validira vnosni XML dokument z našo shemo CCRSchema (Izvorna koda 5.3). Če DB2

določi, da se XML dokument ne ujema z XML shemo, se bo sprožila napaka.

Operacija retrievePHR sprejme pacientovo identifikacijsko številko, preveri, ali obstaja

profil pacienta, in vrne njegove zdravstvene podatke. V našem primeru operacija vrne vse

try{ //getting a document builder DocumentBuilderFactory DBFactory = DocumentBuilderFactory.newInstance(); DocumentBuilder documentBuilder = DBFactory.newDocumentBuilder(); Document document = documentBuilder.newDocument(); //creating the XML tree //create the root element, its attribute and add it to the document Element CCR = document.createElement("ContinuityOfCareRecord"); CCR.setAttribute("xmlns","urn:astm-org:CCR"); document.appendChild(CCR); //create the element of ID object of this CCR document Element CCRDocumentOID = document.createElement("CCRDocumentObjectID"); CCR.appendChild(CCRDocumentOID);

Text CCRDocumentOIDText = document.createTextNode(Integer.toString(phr.getInt("patientID")));

CCRDocumentOID.appendChild(CCRDocumentOIDText); //create the Language element and its text element Element language = document.createElement("Language");

Izvorna koda 5.2 – Ustvaritev DOM dokumenta

5.4 Storitev PHRService S t r a n | 103


podatke profila ustrezno preslikane v poslovne objekte. Uporabljene so enostavne

XMLQuery izjave, ki izberejo podatke za določenega pacienta.

Zadnja operacija removePHR odstrani osebni zdravstveni zapis pacienta z uporabo SQL

stavka DELETE, kjer ima stavek WHERE vrednost identifikacijske številke pacienta.

Pomemben poslovni objekt, s katerim manipulirajo operacije, je PHRWrapper, ki vsebuje

poslovni objekt tipa PHR (Slika 5.9). Objekt PHR zajema vse podatke, ki se nanašajo na

zdravje pacienta, kot so teža, višina, funkcije, alergije, imunizacije, družinska zgodovina

zdravja ipd.

Slika 5.9 – Definicija poslovnega objekta PHR

String sql = "INSERT INTO PHR (phr) VALUES " + "(XMLVALIDATE(? ACCORDING TO XMLSCHEMA ID HEJUMP.CCRSCHEMA))"; PreparedStatement insert = con.prepareStatement(sql); ...

Izvorna koda 5.3 – Validacija XML strukture

104 | S t r a n 5.4 Storitev PHRService


S prikazanim primerom smo praktično potrdili storitveno komponentno arhitekturo, ki smo

jo opisali v drugem poglavju. Za gradnjo programskega modela smo uporabili IBM

WebSphere Integration Developer V7.0 in IBM WebSphere Process Server V7.0. Pri sami

implementaciji smo uporabili različne tehnologije in jezike. Naslednja stopnja gradnje

našega sistema bi bili varnostna in prezentacijska faza, ki ju v tem diplomskem delu ne

obravnavamo.

6 SKLEP S t r a n | 105


6

6 SKLEP

Je računalništvo v oblaku možno brez storitveno usmerjene arhitekture? Seveda, vendar ne

smemo pričakovati, da se bodo stvari gladko premaknile. Je storitvena arhitektura možna

brez računalništva v oblaku? Seveda, toda ne moremo pričakovati ravno zagona v smeri

šibke sklopljenosti modela, ki ga gradimo.

Podamo lahko veliko število ugotovitev v tej smeri, vendar sinergija obeh, računalništva v

oblaku in storitveno usmerjene arhitekture, prinese vrednost podjetju. Nasvet je, da morajo

podjetja vzpodbujati in vlagati v razvoj SOA spretnosti z namenom v celoti izkoristiti

prednosti nastanka infrastrukture računalništva v oblaku.

Razumeti moramo implikacije uporabe obeh paradigem. Glavni razlog, zakaj podjetja

uporabljajo SOA, predstavlja obljuba ponovne uporabnosti storitve in agilnosti. Nedvomno

SOA in s tem storitveno komponentna arhitektura (SCA) predstavlja dober način za

ustvarjanje učinkovitih arhitektur, ki odgovarjajo na poslovne potrebe podjetja na

stroškovno in časovno učinkovit način.

Računalništvo v oblaku pa ponuja vse kot storitev. Storitve so dobavljene na zahtevo in se

podpirajo na virtualizacijskih tehnologijah za njihovo večjo skalabilnost. Kljub temu ne

moremo reči, da oblak lahko zamenja SOA, kajti pojem storitve v oblaku je širši od tistega

v SOA. SOA storitev se zagotovo ujema s storitvijo v oblaku, še posebej v primeru

programske opreme kot storitev (SaaS). Zaradi tega lahko SaaS izkoristi prednosti, ki jih

ponuja SOA.

106 | S t r a n 6 SKLEP


Predpostavlja se, da bo vrednost računalništva v oblaku v letu 2012 dosegla 42 milijard

dolarjev. Za primerjavo, v letu 2008 je bila vrednost 16 milijard dolarjev, kar pomeni 27%

rast (44). Z vidika odjemalca računalništvo v oblaku pridobi vrednost zaradi ekonomije –

hitrejša, enostavnejša in cenejša uporaba oblačnih arhitektur. Ekonomija skriva vrednost

tudi z vidika ponudnika: manjši stroški za dostavo in podporo aplikacij, lažje doseganje

novih odjemalcev, zmanjšanje operativnih stroškov podatkovnega centra ipd.

IBM platforma poveže SOA in računalništvo v oblaku. S svojimi orodji IBM ponuja

podjetjem lažji način za usmeritev njihovih SOA naložb v sferi računalništva v oblaku.

WebSphere CloudBurst daje podjetjem prostor za shranjevanje SOA slik in vzorcev, ki so

nato prenešeni v oblačno okolje.

SOA in računalništvo v oblaku bosta verjetno konvergirala v enotno arhitekturno ogrodje,

kar pomeni poenotenje računalniških okolij notranjega in vmesnega poslovanja.

Arhitekturno ogrodje mora obravnavati pomembno število zadev, kot je integracija

zunanjih in notranjih storitev, optimizacija, upravljanje in vodenje zapletenih storitvenih

okolij, načrtovanje in oblikovanje zunanjih in notranjih storitev ter poravnava arhitekturnih

in organizacijskih storitvenih modelov.

7 LITERATURA S t r a n | 107


7

7 LITERATURA

1. Storitvene arhitekture, ki temeljijo na modelih. Jurič, Matjaž B. Maribor: Objektna

tehnologija v Sloveniji OTS'2003, 2003.

2. Jurič, Matjaž B., in drugi. SOA Approach to Integration. Birmingham: Packt Publishing

Ltd., 2007. ISBN 978-1-904811-17-6.

3. MacKenzie, Matthew C., in drugi. Reference Model for Service Oriented Architecture

1.0. OASIS Open. [Elektronski] 16. October 2006. [Navedeno: 22. 2. 2010]

http://docs.oasis-open.org/soa-rm/v1.0/.

4. High, Rob, Kinder, Stephen in Graham, Steve. IBM's SOA Foundation: An

Architectural Introduction and Overview. [Elektronski] November 2005. [Navedeno: 22. 2.

2010] http://download.boulder.ibm.com/ibmdl/pub/software/dw/webservices/ws-soa-

whitepaper.pdf.

5. Storitvena arhitektura (SOA) – zgolj kompozicija spletnih storitev? Jurič, Matjaž B.

Maribor: Objektna tehnologija v Sloveniji OTS'2005, 2005.

6. Selvage, Mei, Wolfson, Dan, in Handy-Bosma, John. Information management in

Service-Oriented Architecture, Part 2: Explore the different approaches to information

management in SOA. IBM developerWorks. [Elektronski] IBM, 10. June 2005. [Navedeno:

24. 2. 2010] http://www.ibm.com/developerworks/webservices/library/ws-soa-

ims2/index.html.

108 | S t r a n 7 LITERATURA


7. Beisiegel, Michael, Blohm, Henning in Booz, Dave. Building Systems using a Service

Oriented Achitecture. Progress Software. [Elektronski] November 2005. [Navedeno: 25. 2.

2010] http://www.iona.com/devcenter/sca/SCA_White_Paper1_09.pdf.8. Barcia, Roland,

in Brent, Jeff. IBM WebSphere Developer Technical Journal: Building SOA solutions with

the Service Component Architecture -- Part 1. IBM developerWorks. [Elektronski] IBM,

25. October 2005. [Navedeno: 25. 2. 2010]

http://www.ibm.com/developerworks/websphere/techjournal/0510_brent/0510_brent.html.

9. Edwards, Mike. Composing Business Solutions Using SCA. Open SOA Collaboration.

[Elektronski] 2008. [Navedeno: 25. 2. 2010]

http://www.osoa.org/download/attachments/250/Composing_Business_Solutions_Using_S

CA.pdf?version=1.

10. Chappell, David. Introducing SCA. SCA Resources. [Elektronski] July 2007.

[Navedeno: 25. 2. 2010] http://www.davidchappell.com/articles/Introducing_SCA.pdf.

11. Beisiegel, Michael, in drugi. Assembly Model Specification. SCA Service Component

Architecture. [Elektronski] 15. March 2007. [Navedeno: 27. 2. 2010]

http://www.osoa.org/download/attachments/35/SCA_AssemblyModel_V100.pdf.

12. Holdsworth, Simon, Ielceanu, Sabin, in Karmarkar, Anish. Web Service Binding

Specification. Open SOA Collaboration. [Elektronski] 21. March 2007. [Navedeno: 28. 2.

2010]

http://www.osoa.org/download/attachments/35/SCA_WebServiceBinding_V100.pdf.

13. Barack, Ron, in drugi. Service Component Arhitecture – Java Component

Implementation Specification V1.0. Open SOA Collaboration. [Elektronski] 15. February

2007. [Navedeno: 4. 3. 2010]

http://www.osoa.org/download/attachments/35/SCA_JavaComponentImplementation_V10

0.pdf?version=1.

14. Juric, Matjaz B., Mathew, Benny, in Sarang, Poornachandra. Business Process

Execution Language for Web Services. Birmingham: Packt Publishing, 2006. ISBN 1-

904811-81-7.



15. Chapman, Martin, Ielceanu, Sabin, in Koenig, Dieter. Service Component Architecture

– Client and Implementation Specification for WS-BPEL V1.0. Open SOA Collaboration.

[Elektronski] 21. March 2007. [Navedeno: 4. 3. 2010]

http://www.osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforB

PEL_V100.pdf?version=1.

16. Edwards, Mike, in Barber, Graham. Service Data Objects White Paper. Open SOA

Collaboration. [Elektronski] 20. March 2007. [Navedeno: 1. 3. 2010]

http://www.osoa.org/download/attachments/287/SDO+V2.1+White+Paper.pdf?version=1.

17. Portier, Bertrand, in Budinsky, Frank. Introduction to Service Data Objects. IBM

developerWorks. [Elektronski] IBM, 24. September 2004. [Navedeno: 1. 3. 2010]

http://www.ibm.com/developerworks/java/library/j-sdo/.

18. Adams, Matthew, Cezar, Andrei, Barack, Ron, in Blohm, Henning. SDO 2.1.0 for

Java. Open SOA Collaboration. [Elektronski] November 2006. [Navedeno: 3. 3. 2010]

http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-

FINAL.pdf?version=1.

19. Group, IBM Software. IBM WebSphere Software – WebSphere Process Server,

WebSphere Integration Developer, Business Objects Overview. IBM Education Assistant.

[Elektronski] 30. April 2007. [Navedeno: 3. 3. 2010]

http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/topic/com.ibm.iea.wpi_v6/wpsw

id/6.0/BusinessObjects/WPSWIDv6_BOOverview.pdf?dmuid=20061231125318979313.

20. Woolf, Bobby. Introduction to SOA governance. IBM developerWorks. [Elektronski]

IBM, July 2007. [Navedeno: 23. 3. 2010] http://www.ibm.com/developerworks/library/ar-

servgov/?S_TACT=107AG01W&S_CMP=campaign.

21. Brown, William, Moore, Gary, in Tegan, William. SOA governance—IBM’s approach.

IBM Software. [Elektronski] August 2006. [Navedeno: 6. 4. 2010]

ftp://ftp.software.ibm.com/software/soa/pdf/SOA_Gov_Process_Overview.pdf.

22. Group, The Open Group's SOA Working. SOA Governance Framework. The Open

Group SOA. [Elektronski] 2009. [Navedeno: 6. 4. 2010]



https://www.opengroup.org/projects/soa-

governance/uploads/40/19263/SOA_Governance_Architecture_v2.4.pdf.

23. Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering

computing as the 5th utility. Buyya, Rajkumar, in drugi. 6, s.l. : Elsevier B.V – Future

Generation Computer Systems, 2009, Zv. 25. 0167-739X.

24. Rittinghouse, John W., in Ransome, James F. Cloud Computing – Implementation,

Management and Security. Boca Raton: Taylor and Francis Group, 2010. 978-1-4398-

0680-7.

25. Linthicum, David S. Cloud Computing and SOA Convergence in Your Enterprise.

Crawfordsville: Pearson Education, Inc., 2009. ISBN-13: 978-0-13-600922-1.

26. Armbrust, Michael, in drugi. Above the Clouds: A Berkeley View of Cloud Computing.

Berkeley: Electrical Engineering and Computer Science, College of Engineering, UC

Berkeley, 2009. UCB/EECS-2009-28.

27. Carolan, Jason, in Gaede, Steve. Introduction to Cloud Computing Architecture. Sun

Microsystems Articles. [Elektronski] June 2009. [Navedeno: 9. 3. 2010]

http://www.sun.com/featured-articles/CloudComputing.pdf.

28. Wikipedia. Infrastructure as a Service. Wikipedia. [Elektronski] Wikipedia, 10. March

2010. [Navedeno: 10. 3. 2010]

http://en.wikipedia.org/wiki/Infrastructure_as_a_Service#Infrastructure.

29. Ou, George. Introduction to Server Virtualization. TechRepublic - A Resource for IT

Professionals. [Elektronski] 22. May 2006. [Navedeno: 10. 3. 2010]

http://articles.techrepublic.com.com/5100-10878_11-6074941.html.

30. Velte, Anthony T., Velte, Toby J., in Elsenpeter, Robert. Cloud Computing – A

Practical Approach. United States: The McGraw-Hill Companies, 2009. 978-0-07-

162695-8.

31. Wikipedia. Virtual Machine. Wikipedia. [Elektronski] 10. March 2010. [Navedeno: 10.

3. 2010] http://en.wikipedia.org/wiki/Virtual_machine.



32. DMTF, Distributed Management Task Force. Open Virtualization Format White Paper.

DMTF Standards. [Elektronski] 2. June 2009. [Navedeno: 10. 3. 2010]

http://www.dmtf.org/standards/published_documents/DSP2017_1.0.0.pdf.

33. Chong, Frederick, in Carraro, Gianpaolo. Architecture Strategies for Catching the Long

Tail. MSDN Architecture Center. [Elektronski] April 2006. [Navedeno: 12. 3. 2010]

http://msdn.microsoft.com/en-us/library/aa479069.aspx.

34. Carraro, Gianpaolo, in Chong, Fred. Software as a Service (SaaS): An Enterprise

Perspective. MSDN Architecture Center. [Elektronski] October 2006. [Navedeno: 13. 3.

2010.] http://msdn.microsoft.com/en-us/library/aa905332.aspx.

35. Reese, George. Cloud Application Architectures. Sebastopool, USA: O'Reilly Media,

Inc., 2009. 978-0-596-15636-7.

36. Tummler Singer, J. What is Enterprise Cloud Computing? SOA World Magazine.

[Elektronski] 4. January 2010. [Navedeno: 4. 5. 2010.] http://soa.sys-

con.com/node/1017378.

37. Bowen, Fillmore. How SOA can easy your move to cloud computing. IBM Software

Group. [Elektronski] IBM, November 2009. [Navedeno: 18. 3. 2010.] http://www-

01.ibm.com/software/solutions/soa/newsletter/nov09/article_soaandcloud.html.

38. Services, Amazon Web. Amazon Web Services. [Elektronski] An amazon.com

company, 2010. [Navedeno: 4. 5. 2010] http://aws.amazon.com/.

39. Singla, Vinay. The Overlapping Worlds of SaaS and SOA. SOA&WOA. [Elektronski]

SYS-CON Media, Inc., 27. July 2009. [Navedeno: 18. 3. 2010] http://cloudcomputing.sys-

con.com/?q=node/1047073.

40. Wikipedia. pureXML. Wikipedia. [Elektronski] Wikimedia Foundation, Inc., 2.

December 2009. [Navedeno: 28. 3. 2010] http://en.wikipedia.org/wiki/PureXML.

41. Bhambhri, Anjul. IBM DB2 Hybrid Engine. XML Cover Pages. [Elektronski] 2005.

[Navedeno: 28. 3. 2010] http://xml.coverpages.org/IBM-DB2-hybrid-engine.pdf.



42. Corporation, IBM. IBM WebSphere CloudBurst Appliance – What is WebSphere

CloudBurst? IBM Education Assistant. [Elektronski] 25. January 2010. [Navedeno: 29. 3.

2010]

http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/topic/com.ibm.iea.cloudburstap

pliance/cloudburstappliance/1.1/Overview/CB11_GeneralOverview.pdf?dmuid=20091218

210907777487.

43. Wikipedia. Health 2.0. Wikipedia. [Elektronski] Wikimedia Foundation, Inc., 9.

January 2010. [Navedeno: 22. 3. 2010] http://en.wikipedia.org/wiki/Health_2.0.

44. Bechtolsheim, Andy. Cloud Computing. Netseminar Stanford. [Elektronski] 12.

November 2008. [Navedeno: 31. 3. 2010]

http://netseminar.stanford.edu/seminars/Cloud.pdf.

8 PRILOGE S t r a n | 113


8

8 PRILOGE

8.1 Seznam slik

Slika 2.1 – Tipi izmenjave sporočil ....................................................................................6

Slika 2.2 – Granularnost in sklopljenost v SOA ..................................................................7

Slika 2.3 – Model logične arhitekture .................................................................................9

Slika 2.4 - Upravljanje informacij v SOA ......................................................................... 10

Slika 2.5 – SCA sestavni model ....................................................................................... 13

Slika 2.6 - SCA komponenta ............................................................................................ 15

Slika 2.7 – Pogled SCA pristopa ...................................................................................... 18

Slika 2.8 – Model kompozita ............................................................................................ 20

Slika 2.9 – Razmerje med komponentami in implementacijo ............................................ 24

Slika 2.10 – Komponenta SCA z implementacijo BPEL ................................................... 28

Slika 2.11 – Trikotnik resnice SOA .................................................................................. 29

Slika 2.12 – Heterogen dostop do podatkov ...................................................................... 30

Slika 2.13 – Komponente arhitekture SDO ....................................................................... 31

Slika 2.14 – SDO podatkovni graf .................................................................................... 33

Slika 2.15 – IBM-ov življenski cikel SOA vodenja .......................................................... 35

Slika 3.1 – Uporabniki in ponudniki računalništva v oblaku ............................................. 41

Slika 3.2 – Infrastruktura oblaka ...................................................................................... 42

Slika 3.3 – Virtualizacija .................................................................................................. 44

Slika 3.4 – SaaS kontinuumi ............................................................................................ 49

114 | S t r a n 8 PRILOGE


Slika 3.5 – Področja delovanja ponudnikov SaaS-a .......................................................... 50

Slika 3.6 – Proračun za tradicionalno okolje ..................................................................... 51

Slika 3.7 - Proračun za okolje SaaS .................................................................................. 51

Slika 3.8 – Nižji stroški SaaS-a odprejo nov trg ................................................................ 52

Slika 3.9 – Tržna linija za LOB prodajalce ....................................................................... 52

Slika 3.10 - SaaS zrelostni model ..................................................................................... 53

Slika 3.11 – Elastičnost rezervacije .................................................................................. 60

Slika 3.12 – Histograma zmogljivosti ............................................................................... 65

Slika 4.1 – Vrednost medsebojnega delovanja SOA in CC ............................................... 68

Slika 4.2 – Prekrivanje med SaaS in SOA ........................................................................ 76

Slika 4.3 – Proces ustvarjanja informacijskega modela ..................................................... 78

Slika 4.4 – Lokalne in oblačne storitve ............................................................................. 79

Slika 4.5 – Proces gradnja storitvenega modela ................................................................ 79

Slika 4.6 – Lokalni in oblačni procesi ............................................................................... 80

Slika 4.7 – Proces gradnje procesnega modela .................................................................. 81

Slika 4.8 – Proces gradnje modela vodenja ....................................................................... 82

Slika 4.9 – Namestitveni model WebSphere CloudBurst .................................................. 87

Slika 5.1 – heJump poslovni vidik .................................................................................... 91

Slika 5.2 – heJump arhitektura ......................................................................................... 93

Slika 5.3 – XML shema CCR zapisa ................................................................................ 95

Slika 5.4 – Prvi del podatkovnega modela ........................................................................ 96

Slika 5.5 – Drugi del podatkovnega modela ..................................................................... 97

Slika 5.6 – Sestavni model heJump storitve ...................................................................... 97

Slika 5.7 – Sestavni diagram heJumpDiscussion storitve .................................................. 99

Slika 5.8 – Definicija vmesnika PHRService .................................................................. 101

Slika 5.9 – Definicija poslovnega objekta PHR .............................................................. 103

8.2 Seznam shem

Shema 2.1 – XML shema komponente ............................................................................. 14

Shema 2.2 – XML shema kompozita ................................................................................ 19



Shema 2.3 – Zaporedno proženje storitev ......................................................................... 27

Shema 2.4 – Vzporedno proženje storitev ........................................................................ 27

8.3 Seznam preglednic

Preglednica 3.1 – Lastnosti gruče, mreže in oblaka .......................................................... 39

Preglednica 3.2 – Ponudniki računalništva v oblaku ........................................................ 43

Preglednica 3.3 – Primerjava infrastrukturnih pristopov ................................................... 58

Preglednica 3.4 – Primerjava stroškov različnih pristopov ................................................ 61

Preglednica 3.5 – Ovire in priložnosti za sprejem in rast računalništva v oblaku ............... 62

Preglednica 3.6 – Izpadi AWS, AppEngine in Gmail ....................................................... 63

Preglednica 4.1 – Značilnosti Amazon EC2 ..................................................................... 73

Preglednica 4.2 – Vlogi IBM WebSphere Integration in Application Developerja ............ 84

Preglednica 4.3 – Značilnosti in prednosti WAS Hypervisor Edition ................................ 86

Preglednica 5.1 – Primeri besednjakov ............................................................................. 96

Preglednica 5.2 – Opisi funkcionalnosti SCA komponente ............................................... 98

8.4 Seznam izvorne kode

Izvorna koda 5.1 – Povezava do podatovne baze ............................................................ 101

Izvorna koda 5.2 – Ustvaritev DOM dokumenta ............................................................. 102

Izvorna koda 5.3 – Validacija XML strukture ................................................................. 103

116 | S t r a n 8 PRILOGE




8.5 Naslov študenta

Ime in priimek: Ilče Georgievski

Naslov: 4 Noemvri 9

Pošta: 7000 Bitola

Država: Makedonija

Telefon študenta: +389 70 466 587; +386 40 161 227

E-pošta: [email protected]

8.6 Kratek življenjepis

Rojen: 30. julija 1986 v Bitoli, Makedonija

Šolanje: 1993–2001 OU Kole Kaninski, Bitola, Makedonija

2001–2005 DSU Gimnazija Josip Broz Tito, Bitola, Makedonija

2005–2010 Fakulteta za elektrotehniko, računalništvo in informatiko, Maribor, Slovenija

2009– Fakulteta za naravoslovje in matematiko, Maribor, Slovenija

mailto:[email protected]�

Konvergenca storitveno usmerjene arhitekture in ... · Service-oriented Architecture– SOA) z...

Documents

Transcript of Konvergenca storitveno usmerjene arhitekture in ... · Service-oriented Architecture– SOA) z...