Vodenje storitveno usmerjene arhitekture · Service-oriented architecture governance Key words:...

Matej Hertiš

VODENJE STORITVENO USMERJENE ARHITEKTURE

Diplomsko delo

Maribor, avgust 2009

I

Diplomsko delo univerzitetnega – visokošolskega strokovnega študijskega programa

VODENJE STORITVENO USMERJENE ARHITEKTURE

Študent: Matej Hertiš

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

Smer: Informatika

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

Lektorica: doc. dr. Darinka Verdonik

Maribor, avgust 2009

II

UNIVERZA V MARIBORU

III

ZAHVALA

Zahvaljujem se mentorju izr. prof. dr. Matjaţu B.

Juriču za pomoč in vodenje pri opravljanju

diplomskega dela. Hvala tudi Mojci Poš, ki me je

podpirala pri procesu pisanja.

Posebna zahvala velja staršem, ki so mi omogočili

študij.

IV

Vodenje storitveno usmerjene arhitekture

Ključne besede: storitveno usmerjena arhitektura, SOA vodenje, ogrodja SOA

vodenja

UDK: 004.777:005(043.2)

Povzetek

Dejstvo je, da je vodenje ključ do predvidljivega obnašanja in poslovnih rezultatov. Prav

tako je dejstvo, da živimo v okolju konstantnih sprememb. V diplomskem delu smo po

predstavitvi vodenja in pristopa k izrabi tehnologije, ki pomaga organizacijam izkoristiti

današnje dinamično globalno okolje, torej storitveno usmerjeno arhitekturo, oboje združili

v novo disciplino vodenja storitveno usmerjene arhitekture. Novo vodenje lahko ima za

organizacije dodatne izzive, zato smo pokazali, kako lahko z različnimi ogrodji vodenja le-

te ublažimo. Raziskali smo ogrodja vodenja, ki so na voljo organizacijam, ter identificirali

elemente, ki bi jih maralo kvalitetno ogrodje nasloviti. Ogrodja smo ob tem tudi predstavili

in določili, katere identificirane elemente vodenja naslovijo. Vsekakor se za le ročnim

vodenjem skriva veliko dela in je na tak način dosega skladnosti z odločitvami vodenja

otežena, zato smo prikazali, kakšna in katera orodja so primerna za podporo vodenju.

Praktično smo prikazali uporabo orodja IBM WebSphere Registry and Repository za

razvoj postopkov, ki avtomatizirajo politike vodenja.

V

Service-oriented architecture governance

Key words: service-oriented architecture, SOA governance, SOA governance frameworks

UDK: 004.777:005(043.2)

Abstract

It is the fact that governance is the key to predictable behavior and business results.

Furthermore, that we live in an environment of constant change. We have presented

governance and the approach of using technology in a way that helps organizations utilize

today’s dynamic global environment. We have also combined both of them into a new

discipline, service-oriented architecture governance. New governance may have additional

challenges for the organization; therefore we showed how the different governance

frameworks mitigate it. We researched the governance frameworks, which are available to

organizations and identify the elements that quality framework would need to address. We

also presented frameworks and determine which identified governance elements they

realize. Certainly it is difficult to achieve compliance with the governance decisions only

by manual work so, we showed what kind of tools are appropriate to support the

governance and which are those. Practically, we demonstrated the use of tool IBM

WebSphere Registry and Repository for the development of procedures that automate the

governance policies.

VI

VSEBINA

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

2 SPLOŠNO O VODENJU ............................................................................................ 4

2.1 VODENJE ................................................................................................................ 4

2.2 VODENJE ALI UPRAVLJANJE .................................................................................... 6

2.3 VODENJE SISTEMOV INFORMACIJSKE TEHNOLOGIJE ................................................ 7

2.4 OGRODJA VODENJA SISTEMOV INFORMACIJSKE TEHNOLOGIJE ................................ 8

3 STORITVENO USMERJENA ARHITEKTURA ................................................. 10

3.1 RAZGALJENA SOA ............................................................................................... 11

3.1.1 Storitev ............................................................................................................. 11

3.1.2 Usmerjenost ..................................................................................................... 13

3.1.3 Arhitektura ....................................................................................................... 13

3.2 STORITVENO USMERJENI MITI ............................................................................... 15

3.3 REFERENČNA ARHITEKTURA SOA ........................................................................ 16

3.3.1 Plast operativnih sistemov ............................................................................... 17

3.3.2 Plast storitvenih komponent ............................................................................ 18

3.3.3 Storitvena plast ................................................................................................ 18

3.3.4 Plast poslovnih procesov ................................................................................. 19

3.3.5 Plast uporabniških vmesnikov ......................................................................... 19

3.3.6 Integracijska plast ........................................................................................... 20

VII

3.3.7 Plast kakovosti storitve .................................................................................... 20

3.3.8 Informacijska plast .......................................................................................... 20

3.3.9 Plast vodenja ................................................................................................... 21

4 VODENJE STORITVENO USMERJENE ARHITEKTURE .............................. 22

4.1 DEFINICIJA SOA VODENJA ................................................................................... 22

4.2 SOA VODENJE IN IT VODENJE .............................................................................. 24

4.3 IZROJENA SOA ..................................................................................................... 25

4.4 TRENUTNI TRENDI SOA VODENJA ........................................................................ 26

4.5 OGRODJA SOA VODENJA ...................................................................................... 29

4.5.1 AgilePath model SOA vodenja ........................................................................ 34

4.5.2 IBM-ova metoda SOA vodenja in upravljanja ................................................ 35

4.5.3 Oraclovo ogrodje SOA vodenja ....................................................................... 36

4.5.4 Ogrodje SOA vodenja podjetja Software AG .................................................. 37

4.5.5 Ogrodje SOA vodenja CBDi SAE .................................................................... 38

4.5.6 Ogrodje SOA vodenja organizacije The Open Group ..................................... 39

4.6 POSVOJITEV SOA OGRODJA.................................................................................. 40

4.7 PREGLED TEHNIKE, TEMELJEČE NA SCENARIJIH .................................................... 41

4.8 SOA REGISTER IN REPOZITORIJ ............................................................................. 44

4.9 PONUDNIKI CELOSTNIH TEHNOLOŠKIH REŠITEV SOA VODENJA ............................ 46

5 RAZVOJ POSTOPKOV ZA SOA VODENJE V WSRR ...................................... 49

VIII

5.1 FUNKCIJE, KI OMOGOČAJO VODENJE ..................................................................... 49

5.2 OPREDELITEV IN UVELJAVITEV ŢIVLJENJSKEGA CIKLA STORITEV ......................... 50

5.3 VALIDACIJA IN NOTIFIKACIJA DEJAVNOSTI IN DOGODKOV .................................... 62

5.4 RAZVOJ VTIČNIKA ZA VALIDACIJO ........................................................................ 63

5.5 RAZVOJ NOTIFIKATORJA ....................................................................................... 66

5.6 OMEJEVANJE DOSTOPA ......................................................................................... 69

5.7 ANALIZA VPLIVA .................................................................................................. 73

6 SKLEP ........................................................................................................................ 76

7 VIRI ............................................................................................................................ 78

8 PRILOGE ................................................................................................................... 82

8.1 SEZNAM SLIK ........................................................................................................ 82

8.2 SEZNAM TABEL ..................................................................................................... 84

8.3 SEZNAM IZVORNE KODE ....................................................................................... 85

8.4 NASLOV ŠTUDENTA .............................................................................................. 85

8.5 KRATEK ŢIVLJENJEPIS........................................................................................... 85

IX

UPORABLJENE KRATICE

SOA Service Oriented Architecture

UDDI Universal Description, Discovery and Integration

ebXML Electronic Business using eXtensible Markup Language

XML Extensible Markup Language

XSD XML Schema Definition

WSDL Web Service Description Language

SLA Service Level Agreement

UML Unified Modeling Language

OASIS Organization for the Advancement of Structured Information Standards

COBIT Control Objectives for Information and related Technology

ISO International Organization for Standardization

ITIL The IT Infrastructure Library

OMG Object Management Group

TOG The Open Group

SEI Software Engineering Institute

IT Information Technology

RA Reference Architecture

EA Enterprise Architecture

CoE Center of Excellence

UI User Interface

SOR System of Records

WSRR WebSphere Registry and Repository

SACL State Adaptive Choreography Language

LDAP Lightweight Directory Access Protocol

ROI Return on Investment

SDLC Software Development Life Cycle

QA Quality Assurance

PMO Project Management Office

SGRM SOA Governance Reference Model

SGVM SOA Governance Vitality Method

Vodenje storitveno usmerjene arhitekture Stran 1

1 UVOD

Še ne tako dolgo nazaj se je vodenje v podjetjih, v katerih se je to sploh izvajalo,

udejanjalo na izjemno statičen način. Bolj ali manj je predstavljalo prenos papirjev in

njihovo podpisovanje od zaposlenih do vodstva in nazaj. Vsekakor pa ima ţe vsaj takšno

vodenje sposobnost zmanjševanja tveganja pri poslovanju podjetja. Pomanjkanje vodenja

ali nepravilno vodenje ima lahko neposredno velik vpliv na uspešnost podjetja. Mnogokrat

je ţe imelo nezadovoljivo vodenje za posledico propad podjetja, krizo drţave ali še huje,

širše regije. Azijska finančna kriza leta 1997 je primer krize celotne regije, za katero je bilo

krivo predvsem pomanjkanje vodenja v podjetniškem okolju azijskih drţav (1). Tudi

zadnja finančna kriza iz leta 2008, ki še traja, nakazuje, da so predvsem napake in slabosti

v modelu poslovnega vodenja pripeljale do katastrofalnih posledic za celotno globalno

gospodarstvo (2).

Stari grški filozof Heraklit Mračni1 je trdil: »Nič ne pelje naprej, le sprememba.« Hitro so

se pojavile variacije tega reka, med najbolj znanimi je »Sprememba je edina konstanta«.

Svoje besede je v svojem času, 475 let pred Kristusom, sicer namenil obnašanju vesolja

(3). Danes ta rek velja praktično na vseh nivojih delovanja današnje druţbe. To je v

petdesetih letih spoznal Isaac Asimov2, ki je povzel njegove besede in jih postavil v

današnji kontekst druţbe: »Edina konstanta je sprememba, stalna sprememba, neizogibna

sprememba, ki je danes prevladujoč dejavnik v druţbi. Ni več mogoče sprejeti smiselne

odločitve brez upoštevanja sveta, kot je, in tudi sveta, kot bo.« Današnja druţba se

konstantno spreminja, z njo pa tudi gospodarsko okolje, v katerem delujejo podjetja in

kateremu se morajo znati vsaj prilagoditi, če ga ţe ne izkoristiti za povečanje svoje

dobičknosnosti.

1 Heraklita Mračnega ne zamenjujmo z mlajšim filozofom in astronomom Heraklitom iz Heraclei Ponta.

2 Isaac Asimov je najbolj znan kot popularizator znanosti in pisec znanstvene fantastike.

Stran 2 Vodenje storitveno usmerjene arhitekture

Vsekakor pa je tudi hitrost pojavljanja sprememb najmanj konstantna. Morda lahko rečemo

tudi, da hitrost počasi eskalira proti linearni ali celo eksponentni, kot to velja za Moorov

zakon (4). To niti ne bi bilo nenavadno, če upoštevamo, da Moorov zakon1 izhaja iz

tehnološkega okolja, ki je podpora današnjemu gospodarstvu in ima nanj posledično velik

vpliv. Sam Moorov zakon prav tako še ni dosegel svoje limite, kot so mu to napovedovali

in je vsaj še dve desetletji ne bo dosegel (5). Vsekakor konstantnim pojavljanjem

sprememb ni videti konca.

Dejstvo je, da morajo podjetja spremeniti svoj model delovanja, torej vodenja, da bo le-to

ob ljudeh vključevalo tudi tehnologije in procese, ki podpirajo njihovo delovanje. To je še

posebej res, kadar se podjetja odločijo povečati svojo agilnost s pomočjo tehnologije, ki bo

podprla njihove procese na tak način, da jih bo moţno hitro in učinkovito prilagajati glede

na potrebe konstantnih sprememb globalnega trga (6).

Kot kaţe, lahko premagamo izzive hitro spreminjajočega se okolja, če zagotovimo agilno

informacijsko podporo in uporabimo tehnologijo na način, ki bo omogočal učinkovit odziv

na spremembe ter vodenje, ki bo te spremembe kontroliralo. V ta namen je smiselno

uporabiti pristop gradnje informacijskih sistemov, imenovan storitveno usmerjena

arhitektura (Service Oriented Architecture – SOA), ki ima zmoţnosti ustvariti usklajeno

povezavo med poslovnimi procesi in njihovo informacijsko podporo. Takšna povezava ima

za posledico večjo agilnost podjetja skozi boljšo informacijsko podporo njegovih

poslovnih procesov.

Učinkovito vodenje vse do najvišje ravni delovanja organizacije je nuja, zato smo drugo

poglavje začeli s pregledom vodenja na različnih ravneh delovanja organizacije.

V tretjem poglavju smo predstavili koncept storitveno usmerjene arhitekture z namenom

spoznati, kako in kaj je potrebno voditi, da bo lahko SOA prinesla obljubljene koristi.

Četro poglavje smo namenili prenosu znanja o vodenju iz drugega poglavja na storitveno

usmerjeno ahritekturo. Nova disciplina vodenja lahko organizacijam povzroči dodatne

1 Moorov zakon pravi, da se pribliţno vsaki dve leti število tranzistorjev na čipu podvoji.


izzive, zato smo v četrtem poglavju predstavili, kako se organizacije spopadajo s temi

izzivi ter kako je mogoče te izzive nasloviti s pomočjo ogrodij SOA vodenja. Dodatno pa

smo raziskali katerim elementom mora kakovostno ogrodje SOA vodenja zdostiti in

določili kako obsoječa ogrodja to izpolnjujejo.

V petem poglavju smo vodenje storitveno usmerjene arhitekture na praktičnem primeru s

pomočjo orodja avtomatizirali, z namenom zagotoviti kar se da visoko skladnost z

odločitvami SOA vodenja. Prikazali smo način, kako je mogoče ustrezno orodje prilagoditi

in uporabiti za specifične potrebe SOA vodenja organizacije.

Zadnje, šesto poglavje je namenjeno sklepu diplomskega dela, kjer izpostavimo ključne

ugotovitve in podamo predloge za nadaljnje raziskovanje storitveno usmerjene arhitekture

in vodenje takšne arhitekture.


2 SPLOŠNO O VODENJU

V uvodu smo se med drugim trudili nakazati, kako pomembno je vodenje (governance). V

tem poglavju pa bomo podrobneje raziskali koncept vodenja v kontekstu današnjega

globalnega trga. Poizkusili bomo prikazati kakšna je razlika med vodenjem in

upravljanjem, kaj pomeni vodenje informacijske tehnologije in kakšne izzive vnaša v

delovanje organizacije.

2.1 Vodenje

Izraz vodenje izvira iz teorije politologije, kjer se nanaša na sistem, ki je voden in

kontroliran s strani politične enote. Termin je danes uporabljan tudi v podjetjih, kjer se

nanaša na organizacijo in kontrolo ljudi, ki izvajajo aktivnosti podjetja za dosego

poslovnih rezultatov.

Jedro vsakega vodenja je v sprejemanju odločitev in prenosu teh odločitev do izvajalcev.

Potreba po dobrem vodenju izhaja iz potrebe organizacije, da sprejema dobre odločitve in

jih efektivno prenaša naprej. Da bomo še laţje razumeli relevantnost vodenja za podjetje,

bomo definirali termin v svojem kontekstu. Obstaja velika mnoţica definicij vodenja, ena

izmed neformalnih definicij glagola voditi je sprejetje in nadzor politik ter standardov

skupine, organizacije ali drţave.

Trenutno ni na voljo standardne definicije termina vodenje, zato ga bomo definirali kot

proces (7). Preden bomo lahko vodenje obravnavali kot proces, moramo definirati še

proces:

Proces je zaporedje akcij, sprememb ali funkcij, ki prinaša konec ali rezultat (8).

Proces je zaporedje soodvisnih pojavov v naravi, druţbi ali mišljenju, ki si sledijo v

času (9).


Proces je okarakteriziran kot sprememba statusa delovnih objektov, ki je posledica

izvajanja opravil (akcij). Pomembno je, da se zavedamo, da so lahko procesi med seboj

hierarhično ali kako drugače odvisni.

Sedaj lahko definiramo vodenje kot proces, ki ustanavlja (7):

Verigo odgovornosti, pooblastila in pravice odločanja.

Merila, politike, standarde in kontrolne mehanizme, ki bi omogočili ljudem

izvajati njihove vloge in odgovornosti.

Ali poenostavljeno, vodenje je proces določanja, razporejanja in upravljanja pravic

odločanja, meril in kontrol. Vsaka organizacija mora vzpostaviti elemente vodenja,

navedene v definiciji, da omogoči organizacijskim enotam upravljanje njihovih vlog in

ustvarjanje dodatne vrednosti za organizacijo. Rešitev vodenja je vzpostavljena in

vzdrţevana skozi ţivljenjski cikel vodenja in podprta z usklajenim upravljanjem (7).

Velikokrat se zamenjujeta procesa vodenja in upravljanja ali pa vsaj meja med njima ni

popolnoma jasna. Razliko med obema bomo v namen boljšega razumevanja obeh procesov

podrobneje predstavili v naslednjem poglavju.

Prvi del definicije zagotovi statični pogled vodenja. Definira strukturo podjetja, kako

deluje, določi pravice odločanja ter vloge s pripadajočimi odgovornostmi. Komunikacija je

pri tem lepilo vodenja in njen pomemben element. Vpleteni morajo biti obveščeni, da

lahko zahtevamo pričakovano obnašanje.

Drugi del definicije zagotovi dinamičen pogled vodenja, na katerega lahko gledamo v

smislu poslovne učinkovitosti. Podjetje definira in uvede politike, identificira standarde, ki

jim bo sledilo, da bo doseglo ţelene cilje, ter določi nabor meril in kontrol, ki bodo

pomagale pri sprejemanju odločitev in merile njihovo efektivnost. Te kontrole vodenje se

lahko uveljavljajo skozi poslovne procese podjetja (7). Posebej pomembno je merjenje

rezultatov aktivnosti organizacije. Povratne informacije teh aktivnosti so ključnega pomena

pri delovanju, ki zahteva nenehne izboljšave oziroma je podvrţeno konstantnim

spremembam okolja.


2.2 Vodenje ali upravljanje

Mnogi zamenjujejo ta termina ali verjamejo, da sta sinonima, a nista. Morda zato, ker

ljudje, ki imajo funkcijo upravljanja, prav tako sprejemajo odločitve in je enostavno

verjeti, da je upravljanje in vodenje isto. Bistvo vodenja je sprejemanje odločitev, medtem

ko upravljanje zagotavlja, da so sprejete odločitve izvedene oziroma da se proces vodenja

podjetja izvaja. Identificiramo lahko dva različna procesa:

Proces vodenja, kot smo ga opisali, definira verigo odgovornosti, ki bo pooblastila ljudi in

posredovala sprejete odločitve, ter pooblastila in sredstva komunikacije. Prav tako definira

merila in kontrolne mehanizme, ki omogočajo ljudem izvedbo njihovih vlog in

odgovornosti. Aktivnost vodenja je namenoma načrtovana tako, da definira organizacijsko

strukturo, pravice odločanja, delovne tokove in pooblastila, da bi ustvarila ţelen delovni

tok, ki optimalno koristi vire podjetja ter jih uravna s cilji in nameni podjetja (7).

Proces upravljanja je izdelek procesa vodenja. Za razliko od procesa vodenja proces

upravljanja uvede specifično verigo odgovornosti, pooblastila ter komunikacijo, ki bo

dajala zaupanje ljudem, da izvedejo svoja dnevna opravila. Proces upravljanja vpelje tudi

ustrezna merila in kontrole, da bi omogočil delavcem svobodo pri izvajanju njihovih vlog

in odgovornosti brez posredovanja vodstva. Te omogočajo vodstvu spremljanje izvajanja

procesa vodenja in upravljanja z daljave kot tudi spremljanje kakovosti izhoda procesa

upravljanja v času izvajanja (7).

Čeprav je procesa teţko razlikovati, je pomembno, da se zavedamo, da sta različna. Meja

med vodenjem in upravljanjem ni enolično določljiva. V praksi je odvisna od zrelosti in

velikosti podjetja. V manjših podjetjih z omejenimi človeškimi in finančnimi viri je

vodenje prepleteno z upravljanjem in je vodstvo bolj vpleteno v odločitve dnevnega

upravljanja (10).


2.3 Vodenje sistemov informacijske tehnologije

Pri stopnji pomembnosti vodenja za podjetje in pomembnosti sistemov informacijske

tehnologije (IT) pri vsakodnevnem delovanju podjetja se kaţe nujnost tudi po vodenju

sistemov informacijske tehnologije. Tako kot poslovno vodenje tudi IT vodenje vpliva na

uspehe in neuspehe podjetja.

IT vodenje predstavlja velik del poslovnega vodenja in je zaradi horizontalne narave IT,

ker skoraj vsak v podjetju uporablja vire IT za upravljanje svojega dela, tudi najbolj viden

del vodenja podjetja. Nova disciplina vodenja je podmnoţica poslovnega vodenja, kot je

predstavljeno na sliki 2.1 in je orientirana na sisteme informacijske tehnologije, njihovo

zmogljivost in tveganja.

Slika 2.1 IT vodenje kot podmnoţica poslovnega vodenja

Načeloma je IT vodenje tako kot poslovno vodenje namenjeno doseganju ciljev in

upravljanju tveganj in ga lahko ponovno definiramo kot proces, ki ustanavlja:

pravice odločanja, povezane z IT,

merila, politike, standarde in kontrolne mehanizme.

IT vodenje ponuja podjetjem moţnost, da spremenijo način poslovanja, in je strateško

pomembno pri rasti podjetja. Pomembnost in zanašanje nanj umeščata IT vodenje med

ključne odgovornosti poslovnega vodenja, ne samo za investitorje, ampak tudi za

regulatorje in revizorje. IT vodenje za podjetje ni več opcija (7).


Vodenje in upravljanje sta različna procesa, kar lahko sedaj prikaţemo na primeru IT

vodenja. Slika 2.2 prikazuje grafično odvisnost med obema procesoma in ostalimi

aktivnostmi ter viri.

Slika 2.2 Odvisnost med vodenjem in upravljanjem

Razvidno je, da na IT vodenje kot podmnoţico poslovnega vodenja vplivajo poslovna

strategija in poslovni cilji, ki motivirajo nastajanje novih ciljev IT vodenja. Vidimo lahko,

da je proces upravljanja oz. upravljalska struktura, ki izvaja ta proces, res izdelek vodenja,

ki jo vodenje kontrolira in usmerja, prav tako pa definira merila in kontrole za poslovne

procese.

2.4 Ogrodja vodenja sistemov informacijske tehnologije

Čeprav ni enotnega in celostnega ogrodja IT vodenja, pripravljenega za neposredno

uporabo v organizaciji, obstaja več ogrodij, ki so na voljo organizacijam in lahko sluţijo

kot koristno izhodišče za oblikovanje lastnega modela vodenja. Posledično je večina IT

organizacij implementirala lastne modele IT vodenja, vendar pa so si pri tem izposodili

elemente iz obstoječih ogrodij. Večina teh ogrodij se dopolnjuje in imajo prednosti na

različnih področjih, velikokrat je uporabljena kombinacija različnih ogrodij, da se

izkoristijo prednosti posameznih ogrodij.


Nekatera ogrodja IT vodenja so (11):

Control Objectives for Information and related Technology (CobIT) je sprejet kot

vodilno svetovno ogrodje za IT vodenje in kontrolo. CobIT je skupek dobre prakse

(ogrodje) za upravljanje z informacijsko tehnologijo, ustvarjen leta 1996 s strani

Information Systems Audit and Control Association (ISACA) ter IT Governance

Institute (ITGI).

IT Infrastructure Library (ITIL) je podrobno ogrodje z dobrimi praksami, kako

zagotoviti IT storitveno upravljanje. Razvito in vzdrţevano je s strani United

Kingdom's Office of Government Commerce, s partnerstvom IT Service

Management Forum.

ISO/IEC 27001 (ISO 27001) je zbirka dobrih praks, ki pomaga organizacijam pri

implementaciji in vzdrţevanju varnostnega programa. Nastal je kot posvojitev

standarda British Standard 7799 (BS7799).

Microsoft Operations Framework (MOF) je niz smernic, katerih cilj je pomagati

strokovnjakom informacijske tehnologije vzpostaviti in razvijati zanesljive,

stroškovno učinkovite storitve.

ISO/IEC 20000 je prvi mednarodni standard za upravljanje IT storitev. Temelji na

British Standard 15000 (BS15000), katerega tudi zamenjuje. ISO 20000 kot njegov

predhodnik BS15000, je bil prvotno načrtovan za vključitev najboljše prakse, ki jo

vsebuje ogrodje ITIL, enakovredno pa podpira tudi druga ogrodja za upravljanje IT

storitev, vključno z MOF ogrodjem in komponentami ogrodja CobIT.

AS8015-2005, Australian Standard for Corporate Governance of Information and

Communication Technology, je bil posvojen s strani ISO/IEC 38500 maja 2008.

ISO/IEC 38500:2008, Corporate governance of information technology (temelječ

na AS8015-2005), zagotavlja ogrodje za efektivno vodenje IT ter nudi podporo

najvišjim nivojem v organizaciji, da bi razumeli in izpolnjevali uradne predpise in

etične obveznosti v smislu uporabe IT.

IT Baseline Protection Catalogs ali IT-Grundschutz Catalogs ("IT Baseline

Protection Manual" pred letom 2005) je zbirka dokumentov German Federal Office

for Security in Information Technology (FSI), uporabnih za detekcijo in

kljubovanje varnostnih točk IT okolja.


3 STORITVENO USMERJENA ARHITEKTURA

Preden podrobneje pogledamo vodenje v kontekstu SOA, moramo osvojiti, kaj SOA

pravzaprav je. SOA ni konkretna arhitektura, ampak nekaj, kar pelje do konkretne

arhitekture. SOA je večkrat poimenovana kot stil, paradigma, koncept, perspektiva,

filozofija ali predstavitev. SOA je pristop, način razmišljanja, sistem znanja, ki pelje do

določenih konkretnih odločitev pri načrtovanju konkretnih programskih arhitektur.

Začetki SOA izvirajo iz ţelja po rešitvi problemov velikih heterogenih distribuiranih

sistemov, ki so rezultat vedno večje rasti podjetij in s tem kompleksnosti njihovih

informacijskih sistemov. Po OASIS SOA referenčnem modelu je SOA »paradigma za

organizacijo in uporabo distribuiranih zmoţnosti, ki so lahko pod kontrolo različnih

lastniških domen« (12). Ob uveljavitvi tehnologije spletnih storitev, ki predstavlja en

moţen način realizacije SOA infrastrukture, je SOA pristop dobil potreben zagon za

razmah in nov primarni cilj v poslovnem svetu.

Primarni cilj SOA je uskladiti poslovni svet in svet informacijskih tehnologij na način, ki

naredi oba učinkovitejša. SOA je most, ki ustvari simbiotično in sinergijsko vez med

njima, ki je močnejša in vrednejša kot karkoli drugega, čemur smo bili priča v preteklosti.

Še več, bistvo SOA je doseči boljše poslovne rezultate z boljšo usklajenostjo poslovanja in

IT (13).

SOA izhaja iz predpostavke, da ima vsako podjetje poslovni načrt, ki opisuje, kako

podjetje deluje, oz. procese, ki jih izvaja, organizacijsko strukturo, dolgoročne in

kratkoročne cilje, pravila in politike, kako podjetje posluje (13).

Večina podjetij ima zapisan visokonivojski poslovni načrt, ki pove, kaj je smisel podjetja.

Vedno več podjetij ima svoj poslovni načrt tudi formalno dokumentiran. Mnoga od teh, ki

imajo svoj poslovni načrt dokumentiran, se soočajo s teţavami posodabljanja načrta z

aktualnim delovanjem podjetja. Poslovni procesi se spreminjajo, kakor se podjetje odzove


na spremembe trga, regulative ali prihod novih produktov, in te spremembe se navadno

zgodijo brez preslikave v poslovni načrt (13).

Zamisel, da bi lahko poslovni načrt preslikali in vzdrţevali, nudi izredno velik potencial

izrabe informacij takšnega načrta. Način uresničitve tega je temelj SOA. Izpeljava načrta

informacijskega sistema iz poslovnega načrta omogoča izvedbo sprememb informacijskega

sistema s hitrostjo spremembe poslovnega načrta. Še več, takšen informacijski sistem nudi

spremljanje stanja poslovanja in doseţenih poslovnih ciljev. Z nudenjem takšnih podatkov

sam informacijski sistem ponuja iniciative za spremembe. Skozi to komunikacijo SOA

zagotavlja bolj fleksibilno poslovanje skozi bolj fleksibilen IT. Ta komunikacija je

predstavljena kot SOA ţivljenjski cikel, v katerem so poslovni procesi modelirani,

sestavljeni, nameščeni in spremljani v iterativnem ciklu.

3.1 Razgaljena SOA

Najpogosteje se v pogovorih o SOA pojavlja vprašanje, kaj pravzaprav je storitev v

storitveno usmerjeni arhitekturi. Če pa ţe razumemo storitev, kaj potem predstavlja

storitvena usmerjenost? In kot nazadnje, kaj pravzaprav je takšna arhitektura, ki predstavlja

storitveno usmerjenost? To so vsa primerna in pomembna vprašanja pri obravnavi SOA.

Najti točno, matematično natančno definicijo vseh teh pojmov, ki bi veljala v vseh

situacijah, pa zna biti zelo teţavno. Verjetno pa takšna preciznost niti ni nujna za dosego

ciljev in uspehov s SOA.

Pojavlja se veliko različnih definicij komponent SOA, od katerih vsaka predstavi malo

drugačen pogled nanje, a so v jedru vedno iste.

3.1.1 Storitev

Kaj pravzaprav je storitev v storitveno usmerjeni arhitekturi? Definirajmo storitev, ena

izmed številnih definicij bi bila:

Storitev je sposobnost dobave kakšne javne zahteve.


Glavni deli definicije so: sposobnost, ki pravi, da so neke zmoţnosti ali funkcije izvedene,

dobava, ki pomeni, da je funkcija bila dostavljena uporabniku, in javne zahteve, ki

predstavljajo nekaj, kar eden ali več uporabnikov ţeli (14).

SOA je poenostavljeno arhitektura, ki uporabi jedro koncepta ponudnik in uporabnik

storitve na slika 3.1, da definira načrt informacijskega sistema. Polega uporabnika in

ponudnika imamo v tem primeru še storitveni register, v katerem ponudnik oglašuje svoje

storitve, medtem ko uporabnik v njem išče storitve, ki bi bile njemu v korist.

Slika 3.1 Ponastavljen koncept ponudnik-uporabnik, uporabljen v SOA

Uporabnik storitve je lahko poslovni proces, opravila, iz katerih je poslovni proces

sestavljen, pa imenujemo storitev.

To je SOA konceptualni pogled na predstavitev storitve. Tehnični pogled bi storitve

prikazal kot vmesnik za sporočilo (sporočila), izmenjujoče se med ponudnikom(i) in

uporabnikom(i). Sam pregled vmesnika mora nuditi zadostne informacije aplikacijam in

storitvam, da so sposobne uporabiti takšen vmesnik. Vmesnike je mogoče tehnično

implementirati z naborom tehnologij, ki podpirajo interakcijo preko omreţja, med temi

najbolj izstopa tehnologija spletnih storitev.


3.1.2 Usmerjenost

Sedaj ko vemo, kaj je storitev, lahko povemo, da je storitvena usmerjenost način, kako

integrirati poslovanje kot nabor povezanih storitev. Če lahko definiramo storitve, jih lahko

začnemo povezovati v kompozicijo oziroma kompozitno storitev, kot je prikazano na sliki

3.23.23.2, ki lahko predstavlja poslovni proces (13). Ali drugače, če lahko identificiramo

poslovni proces in v njem nabor opravil, ki se izvedejo v procesu, potem lahko rečemo, da

so opravila storitve in da je poslovni proces kompozicija storitev.

Slika 3.2 Kompozitna storitev ali poslovni proces

Poslovni načrt je torej v bistvu sestavljen iz kompozicije storitev in politik ter pogojev, kar

skupaj predstavlja načrt informacijskega sistema.

Kompozicija storitev v poslovne procese je najverjetneje eden izmed najpomembnejših

konceptov SOA. Storitve so sestavljene po določenem vrstnem redu in po naboru pravil, da

zagotovijo podporo poslovnim procesom. Kompozicija storitev omogoča zagotoviti

podporo poslovnim procesom na fleksibilen in sorazmerno enostaven način. Prav tako pa

omogoča hitro spreminjanje poslovnih procesov in s tem zagotovi podporo spreminjajočim

se zahtevam hitreje in z manj napora. Šele ko je doseţena raven kompozitnih storitev,

lahko uresničimo vse koristi SOA (15).

3.1.3 Arhitektura

Storitveno usmerjena arhitektura je arhitekturni stil gradnje IT infrastrukture podjetja, ki

izrablja princip storitvene usmerjenosti z ţeljo, doseči tesnejšo usklajenost med

poslovanjem in informacijskimi sistemi, ki podpirajo poslovanje podjetja (13).


Arhitektura podjetja, temelječa na SOA, bo izrabljala kompozitne aplikacije. Kompozitna

aplikacija je zbirka sorodnih in integriranih storitev, ki podpirajo poslovne procese,

zgrajene nad SOA (13). Aplikacija izpolnjuje določen vidik poslovanja podjetja, kar je

doseţeno s kompozicijo storitev in procesov.

Kar bi moralo biti sedaj jasno, je, da bistvo SOA ni toliko tehnologija kot celovita

povezava med poslovanjem in IT-jem podjetja. SOA zajema orodja in metodologije za

popis poslovnega načrta in uporabo tega načrta za pomoč pri izboljšavi poslovanja. Prav

tako zajema orodja, programske vzorce in tehnike za implementacijo poslovnega načrta v

informacijski sistem. Zajema infrastrukturo vmesnega sloja (middleware), ki gosti

implementacijo. SOA zajema upravljanje te implementacije z ţeljo zagotoviti

razpoloţljivost poslovanja in učinkovito rabo virov pri izvajanju implementacije. Zajema

vzpostavitev pravic in procesov, ki kontrolirajo spremembe v poslovnem načrtu in njeni

implementaciji v informacijskem sistemu (13).

Primarni standardni referenčni modeli1 in referenčne arhitekture

2 za SOA so bili izdelani s

strani OASIS, Object Managment Group in The Open Group.

Organization for the Advancement of Structured Information Standards (OASIS)

SOA, referenčni model in referenčna arhitektura, zagotavljata konceptualno

ogrodje in omogočata razumevanje SOA znotraj organizacij, toda nista direktno

izvedljiva.

The Open Group (TOG) SOA referenčna arhitektura nudi osnovo za načrt SOA

arhitekture in mehanizme za preslikavo le-te v industrijsko SOA arhitekturo ter

implementacijo rešitev.

Object Managment Group (OMG) se osredotoča na opis arhitekture in podporo

razvoja na podlagi modelov (model-driven-approach), kar zajema prepoznavanje in

spodbujanje razvoja OMG standardov modeliranje.

1 Je abstraktno ogrodje za razumevanje pomembnosti odnosov med entitetami nekega okolja.

2 Modelira abstraktne arhitekturne elemente v domeni, neodvisni od tehnologije, protokolov in produktov, ki

so uporabljeni za implementacijo domene. Nudi šablono, ki temelji na generalizaciji prejšnjih uspešnih

rešitev.


3.2 Storitveno usmerjeni miti

Po upadu začetne vznesenosti je SOA še vedno tukaj, da ostane. V tem času se je ustvarilo

kar nekaj mitov, ki jih bomo na tem mestu razčistili. Zelo pomembno je, da jih razumemo,

preden se podamo globlje v SOA. Tabela 3-1 opisuje najpogostejše mite, ki obkroţajo

storitveno usmerjeno arhitekturo (16).

Tabela 3-1 Miti in dejstva o SOA

Mit Dejstvo

SOA je tehnologija. SOA je načrtovalski pristop, neodvisen od

produktov, tehnologij ali industrijskih trendov.

SOA zahteva spletne storitve. SOA je lahko realizirana s spletnimi storitvami, a

uporaba spletnih storitev ne prinaša nujno SOA.

SOA je nova in revolucionarna. EDI, CORBA in DCOM veljajo za konceptualne

primere storitvene usmerjenosti.

Referenčna arhitektura SOA

zmanjša tveganja implementacij.

Implementacije SOA so podobne sneţinkam: niti

dve nista enaki.

SOA zahteva popolno prenovo

tehnologij in poslovnih procesov.

SOA bi morala biti postopna in zgrajena na

obstoječih vloţkih.

SOA terja vojsko svetovalcev. SOA zahteva orodja, ne svetovalce.

SOA je enostavna. Gradnja s SOA obogatenih IT okolij je evolucijski

proces, ki zahteva predanost in vztrajnost.

Moramo zgraditi SOA. SOA je pot, ne cilj.

Računalništvo v oblaku bo kmalu

zamenjalo SOA.

SOA je arhitekturni pristop, računalništvo v

oblaku je način za uvajanje vidikov arhitekture,

vključno s SOA.


3.3 Referenčna arhitektura SOA

Do sedaj smo spoznali temeljni namen SOA, v tem poglavju pa si bomo pogledali

gradnike, ki sestavljajo takšno arhitekturo, kar nam bo pomagalo pri razumevanju vidikov,

ki jih je potrebno upoštevati pri SOA vodenju. Različni ponudniki programskih rešitev so

ponudili vsak svoj pogled na referenčno SOA arhitekturo, ki pa je navadno usklajen z

njihovimi produkti.

V ta namen bomo uporabili referenčno arhitekturo standardizacijskega telesa The Open

Group, katerega poslanstvo je vzpostavitev odprtih standardov, ki bi bili tehnološko in

produktno nevtralni. The Open Group SOA Reference Architecture (TOG RA) je

namenjen organizacijam, ki vpeljujejo SOA. Seveda TOG RA ni namenjen samo

organizacijam, ki vpeljujejo SOA, ampak tudi ponudnikom rešitev, ki sestavljajo SOA

infrastrukturo, in integratorjem, ki gradijo SOA rešitve, ter seveda standardizacijskim

telesom, ki delujejo nad SOA specifikacijami (12).

TOG RA je zasnovan s ciljem osnovati SOA gradnike: storitve, komponente in procese, ki

skupaj podpirajo poslovne procese in cilje podjetja. Metapodatki, ki so pod vsako plastjo,

in povezave med njimi pa lahko dodatno olajšajo premostitev vrzeli med poslovanjem in

IT od modeliranja rešitev do njihove realizacije (12). Referenčna arhitektura klasificira

SOA gradnike v devet plasti, kot prikazuje slika 3.3.

Slika 3.3 The Open Group SOA, referenčna arhitektura (12)


Prvih pet plasti vsebuje gradnike, katerih namen se nanaša na poslovno funkcionalnost.

Podpirajo drug drugega v hierarhiji, čeprav njihovo zaporedje ni strogo določeno. V

zaporedju, od spodaj navzgor, vsebujejo gradnike, ki predstavljajo (12):

obstoječe aplikacije in ostale programe – plast operativnih sistemov (Operational

Systems),

programske komponente, ki pomagajo sestaviti storitve in lahko vplivajo na

obstoječe vire – plast storitvenih komponent (Service Component),

storitve, ki so v storitvenem portfelju in so zatorej razpoloţljive za uporabo v

rešitvah skozi odkritje in kompozicijo – plast storitev (Services),

poslovne procese in kompozitne storitve, ki jih ti uporabljajo – plast poslovnih

procesov (Business Processes),

ljudi in zunanje sisteme, ki sodelujejo v poslovnih procesih, in njihove vmesnike do

storitev – plast uporabniških vmesnikov (Consumer Interfaces).

Preostale štiri plasti podpirajo plasti, ki se nanašajo na poslovno funkcionalnost, a se

hierarhično ne podpirajo med seboj v strogem zaporedju. Vsebujejo gradnike, katerih

namen se nanaša na (12):

integracijo drugih gradnikov – plast integracije (Integration),

vidik kakovosti sistemskih operacij – plast kakovosti storitve (Quality of Service),

informacije – plast informacij (Information),

vodenje – plast vodenja (Governance).

Iz slike 3.3 je razvidno, da del, ki predstavlja SOA vodenje, pokriva največje območje. Na

plast vodenja so nanizani vsi ostali gradniki arhitekture, kar nakazuje, da je vodenje

potrebno izvajati za vse gradnike arhitekture.

3.3.1 Plast operativnih sistemov

Gradniki v tej plasti so programi in podatki operacijskih sistemov podjetja. Na primer

zavarovalnica lahko ima gradnik, kot je »upravljanje odnosov s strankami«, »baza strank«,

»notranje računovodstvo«.


V plasti operativnih sistemov gradniki vsebujejo (12):

aplikacije in podatkovna skladišča s funkcionalnostmi, ki so zahtevane za

zagotovitev funkcionalnosti v storitveni plasti,

infrastrukturne programe, kot so operacijski sistemi, podatkovni sistemi in

izvajalna okolja.

3.3.2 Plast storitvenih komponent

Ta plast vsebuje programe, ki niso v plasti operativnih sistemov in pomagajo izvajati

storitve.

Gradniki v tej plasti vsebujejo:

programe za gradnjo storitev, ki ovijajo programe v plasti operativnih sistemov,

programe, ki so napisani, da izvajajo storitve in da sami dostavijo storitveno

funkcionalnost, in

skupine takih programov.

Plast storitvenih komponent omogoča večjo IT fleksibilnost s povečanjem šibke

sklopljenosti sistema. Šibka sklopljenost je doseţena s skrivanjem hitro spreminjajoče se

implementacije pred uporabniki (12).

3.3.3 Storitvena plast

Ta plast vsebuje storitve portfelja storitev. Vsaka storitev ustreza specifikaciji, ki nudi

zadostne podrobnosti, da omogoči uporabniku uporabiti storitev in njene funkcije.

To je osrednja plast modela referenčne arhitekture. Njeni gradniki podpirajo osnovne

značilnosti SOA (12). Primeri storitev portfelja iz te plasti bi v bančništvu lahko bili

»identificirati primernost stranke«, »potrditev prenosa«, »prenesi sredstva« …


Gradniki storitvene plasti vsebujejo:

storitve portfelja,

kompozicije storitev portfelja in storitve drugih portfeljev,

skupine storitev in kompozicije, ki pokrivajo določeno funkcijsko področje,

podatki, ustvarjeni ali uporabljeni s strani storitev portfelja,

opisi storitev, storitvene pogodbe in politike.

3.3.4 Plast poslovnih procesov

Ta plast vsebuje poslovne procese. Primer bi lahko bil »prenos sredstev« ali »obračun

transakcij«.

Poslovni procesi so lahko sestavljeni iz drugih poslovnih procesov in storitev portfelja

(12). Gradniki v tej plasti vsebujejo:

poslovne procese,

kompozicije, v katerih nastopajo poslovni procesi, ki so sestavljeni iz drugih

poslovnih procesov in storitev portfelja,

informacije, ustvarjene ali uporabljene s strani poslovnih procesov.

3.3.5 Plast uporabniških vmesnikov

Ta plast vsebuje uporabniške vmesnike sistema in programske vmesnike, preko katerih

uporabniki dostopajo do storitev portfelja. Primer bi lahko bil »on-line bančni portal« (12).

Gradniki v tej plasti vsebujejo:

ljudi, organizacije in programe, ki sodelujejo v poslovnih procesih,

programske vmesnike, ki prikazujejo informacije in jih sprejemajo s strani

uporabnikov,

podatke, uporabljene s strani vmesniških programov.


3.3.6 Integracijska plast

Ta plast vsebuje gradnike, katerih funkcionalnost je omogočiti integracijo komunikacije

med ostalimi gradniki. Omogoča moţnost razklapljanja1 ponudnikov in uporabnikov

storitev, kar daje dodatno fleksibilnost arhitekturi.

Sporočanje, transformacija sporočil, procesiranje kompleksnih dogodkov, kompozicija

storitev in odkrivanje storitev so podprte z gradniki v tej plasti (12).

3.3.7 Plast kakovosti storitve

Ta plast vsebuje gradnike, katerih funkcionalnost se nanaša na spremljanje in upravljanje

kakovosti storitev sistema in vsebuje zmoţnosti varnosti in upravljanja (12).

3.3.8 Informacijska plast

Ta plast vsebuje gradnike, katerih funkcionalnost je omogočitev transformacije in

upravljanje podatkov. Transformacija sporočil je podprta z gradniki te plasti (12).

Ta plast vsebuje tudi gradnike, kot so:

informacijski modeli,

slovarji,

podatkovni modeli,

modeli za predstavitev podatkov,

programi, ki razkrivajo podatke kot storitve,

pogon za podatkovno iskanje,

pogon za podatkovno rudarjenje,

upravljalski dokumentni sistem.

1 SOA načela dajejo močan poudarek na razklapljanje ponudnikov storitve od uporabnikov storitve. Ena od

osnovnih ideja razklapljanjem je zagotavljanje, da sprememba na strani ponudnika storitve ne bo zahtevala

ustrezne spremembe na strani uporabnika storitve.


3.3.9 Plast vodenja

Gradniki v tej plasti se ukvarjajo z implementacijo in operativnim vodenjem.

Ta plast vsebuje gradnike, kot so:

pravila vodenja in postopki,

storitve in programi, ki podpirajo aplikacije pravil in operacije postopkov.

Cilj te plasti je zagotovitev konsistentnosti storitev in portfelja rešitev ter ţivljenjskega

cikla procesov (12). V tej plasti bo vodenje zagotovilo, da so vsi aspekti SOA vodeni in

upravljani. Kako to doseči, kaj nam je lahko pri tem v pomoč, pa smo obdelali v

naslednjem poglavju.


4 VODENJE STORITVENO USMERJENE ARHITEKTURE

Ob razlagi poslovnega in IT vodenja ter storitveno usmerjene arhitekture in ciljev, ki jih

ţeli doseči, lahko odgovorimo na vprašanje, kaj predstavlja SOA vodenje, zakaj je

pomembno in kakšne so njegove koristi, prav tako pa tudi, kakšne rešitve so na voljo, ki bi

omogočile organizacijam laţjo vpeljavo vodenja v njihovo SOA okolje.

Z vodenjem ţelimo doseči, da bo SOA okolje kar se da uspešno. Uspešnost pa bo

doseţena, ko bo SOA uveljavila svoje glavne koristi iz naslova fleksibilnosti in niţjih

stroškov vzdrţevanja. Ponovna uporaba je eden izmed glavnih principov, ki prinašajo

koristi storitveno usmerjeni arhitekturi. Fleksibilnost in niţji stroški vzdrţevanja ne bodo

doseţeni, če organizacija ne bo uspešno izvajala ponovne uporabe storitev (17).

SOA vodenje more zagotavljati, da SOA daje koristi, da velja enačba: načrtuješ in

implementiraš ponovno uporabljive storitve, nato jih ponovno uporabiš in pridobiš koristi.

Enačba pa seveda ne velja, kadar storitve niso načrtovane za ponovno uporabo ali nikoli

ponovno uporabljene (17). Koristi ponovne uporabe direktno občutita obe strani, na eni

strani poslovanje, saj je izboljšan odziv na spremembe, in na drugi strani IT, ki ima

efektivneje izrabljene vire in manjše stroške.

4.1 Definicija SOA vodenja

Ob mnogih definicijah SOA, ki prihajajo s strani ponudnikov rešitev, standardizacijskih

teles, analitičnih podjetij in priznanih avtorjev, se ob definiciji SOA vodenja in njenega

obsega pojavlja veliko zmede in nestrinjanja (18).

Vsekakor pa je SOA vodenje še vedno vodenje, katerega bistvo je vzpostavitev pravic

odločanja z namenom upravljanja tveganj in dosega ţelenih poslovnih rezultatov. Ker so v

Gartnerjevih vrstah skovali kratico SOA, bomo na tem mestu za definicijo uporabili njihov


pogled na SOA vodenje, ki pravi, da je za SOA vodenje potrebno vzpostaviti pravice

odločanja za (17):

1. definiranje in spreminjanje poslovnih procesov, ki bodo podprti s SOA,

2. definiranje, načrtovanje, dostop, izvajanje, delovanje in vzdrţevanje storitev,

3. identificiranje storitvenih zahtev in pravic dostopa,

4. določitev lastništva storitev in razdelitev stroškov,

5. postavitev politik, odgovornosti in pravil za vse zgoraj našteto,

6. merjenje uporabe in skladnosti in opredelitev pobud za spodbujanje sprejetja teh

pravil.

SOA vodenje torej določa pravice odločanja za definiranje in spreminjanje poslovnih

procesov, ki bodo podprti s SOA, pravice dostopa in zmogljivosti. Dodatno naslavlja, kako

se storitve ponovno uporabijo, načrtujejo, dostopajo, izvajajo in vzdrţujejo. Prav tako je

SOA vodenje pomemben mehanizem za določanje lastništva storitev in razdelitve stroškov

v organizaciji. Definira tudi politike, postopke in pravila o tem, kako organizacija izvaja in

upravlja SOA okolje. Poleg tega je skladnost potrebno zagotoviti v različnih procesih

razvoja in namestitve, da se pokaţe, da SOA vodenje deluje. Nekatera pravila so lahko

uveljavljena tudi skozi uporabo določenih orodij za upravljanje politik. SOA vodenje ne

more biti le sledenje pravilom, ampak mora meriti izvajanje in skladnost ter opredeliti

pobude za spodbujanje sprejetja teh pravil (17).

Očitno SOA vodenje upravlja s tveganji SOA okolja, da zagotovi, da so izbrane prave

storitve za implementacijo, da so implementirane tako, da jih bo mogoče ponovno

uporabiti, in da se bodo razvite storitve tudi ponovno uporabile. SOA vodenje zagotavlja,

da organizacija zasleduje primerno SOA strategijo, usklajeno z IT in poslovnimi cilji, in

izvaja to strategijo z zadanimi smernicami in omejitvami.

SOA vodenje je povezano z ostalimi področji vodenja znotraj organizacije in mora biti

definirano, implementirano in vzdrţevano v širšem kontekstu. Direktno bi moralo razširjati

IT vodenje, pri tem pa se osredotočiti na ţivljenjski cikel storitve za zagotovitev poslovnih

ciljev SOA.


4.2 SOA vodenje in IT vodenje

Pri načrtovanju in uveljavitvi SOA vodenja je vsekakor potrebno začeti graditi pri IT

vodenju. Da lahko SOA vodenje umestimo pod IT vodenje, je potrebno identificirati

spremembe, ki so potrebne v IT vodenju, da bi se zagotovilo ustrezno upravljanje zasnove

in konceptov storitvene usmerjenosti in distribuirane arhitekture in da storitve zagotavljajo

poslovne cilje (19).

SOA vodenje bi moralo nasloviti teme, kako naj bodo pravice odločanja, politike, procesi

in merila IT vodenja spremenjeni in obogateni za uspešno vpeljavo SOA, in tako

izoblikovati učinkovito SOA vodenje (19). Če sedaj v kontekst poslovnega in IT vodenja

dodamo SOA vodenje, nastane nova razširjena slika 4.1.

Slika 4.1 SOA vodenje kot podmnoţica poslovnega in IT vodenja

SOA vodenje se mora razširjati preko meja IT vodenja, saj je le-to orientirano na sisteme

informacijske tehnologije, njihovo zmogljivost in tveganja, kar vizualno prikazuje slika

4.1. SOA vodenje pa vključuje tudi upravljanje poslovnih procesov in storitev, da bi

zadostilo poslovnim ciljem. Ker bistvo SOA ni le tehnologija, o njenem vodenju ne

moremo razmišljati le kot o dopolnitvi IT vodenja, ampak o njegovi razširitvi.

Za pomoč pri vpeljavi SOA vodenja lahko uporabimo ogrodja IT vodenja, kot sta CObIT

ali ITIL, ki pa ne naslavljata SOA direktno. Vsekakor pa lahko obstoječa implementacija

ogrodja IT vodenja izredno pospeši vpeljavo SOA vodenja. Organizacijam, ki še nimajo

vzpostavljenega močnega IT vodenja, pa ponuja zahteva po SOA vodenju dodaten razlog

za utrditev IT vodenja.


Da bi izkoristili kar največ koristi SOA implementacije in pri tem ne povzročali dodatnih

izzivov organizaciji, se podjetja lahko posluţijo uveljavljenih pristopov oziroma ogrodij za

SOA vodenje. Kakor za vsako drugo vodenje so se iz različnih virov na trgu pojavila tudi

ogrodja za SOA vodenje.

4.3 Izrojena SOA

Vodenje je sredstvo, s katerim zagotovimo predvidljive rezultate, in brez vodenja tudi pri

SOA pride do nepredvidljivih implementacij. Projekti organizacij, ki uporabljajo SOA, a

brez vodenja, večinoma prinesejo le malo dodatne vrednosti. Podjetja, ki imajo SOA brez

strategije vodenja ali je le-ta slaba, imajo pogosto teţave. Njihove simptome Gartner

razvršča kot:

SOA divjega zahoda kot najbolj pogost primer izrojene SOA. Storitve se nenadzorovano

širijo brez procesa formalne definicije storitve. Takšno SOA pogosto spodbuja navdušenje

nad enostavno uporabo tehnologij spletnih storitev. Velik del funkcionalnosti aplikacij je

izpostavljen skozi spletne storitve, ki pa niso objavljene v centralnem registru. Nobeden ne

ve, koliko storitev imajo, zakaj jih imajo ali kaj te delajo, zato ni njihove koristi in ponovne

uporabe. To je teţko popraviti in nadzirati (17).

Podvojena SOA je bolj disciplinirana in premetena verzija SOA divjega zahoda. Ponavadi

vsebuje veliko storitev (včasih več kot 1000). Stvari delujejo dobro, toda veliko storitev je

bilo podvojenih enkrat ali celo večkrat, mehanizmi nagrajevanja za ponovno uporabljive

storitve in uporabo obstoječih storitev so nejasni. Obstaja malo ponovne uporabe in stroški

vzdrţevanja se mnoţijo ter večajo veliko bolj, kot bi to bilo potrebno. Ţalostno je, da so

podjetja pogosto zadovoljna s takšno SOA, čeprav bi bil njihov prihranek mnogo višji, če

bi zmanjšali podvajanje (17).

SOA za police, predstavlja implementirano SOA okolje, toda le malo aplikacij uporablja

javne storitve. Večina jih ostane takšnih, kot so, ob uporabi nestrukturiranega

integracijskega mehanizma točka do točka za povezovanje z drugimi deli IT infrastrukture.

Obstaja le malo koristi poslovnih enot, ni dogovorjene arhitekture na nivoju celotnega


podjetja in ponovna uporaba ostane le obljuba. Nameni so dobri, toda SOA je izguba virov

v tem kontekstu in ne bo prinesla ţelenih koristi (17).

Tudi Oracle je identificiral nekaj simptomov, ki lahko kaţejo, da se vodenje ne izvaja ali

da je neefektivno (6):

ni SOA načrta,

nejasne prioritete,

kulturni odpor do sprememb,

pomanjkanje vpogleda v storitve in portfelj,

neučinkovitost operativnih procesov in praks,

razmetana infrastruktura,

nastanek SOA silosov,

neučinkovita sredstva za potrditev in uveljavitev standardov skladnosti,

premalo informacij za sprejemanje investicijskih odločitev in projektov,

ni sredstev za merjenje napredka ali donosnosti (Return On Investment – ROI).

To so vse simptomi, na katere moramo biti pozorni pri izvajanju SOA, če ţelimo iz nje

pridobiti kar največ koristi, ki jih ta ponuja. Prepozen odziv na teţave je bil ţe mnogokrat

poguben za SOA projekte.

4.4 Trenutni trendi SOA vodenja

S tem ko organizacije napredujejo pri implementaciji SOA in njihovo SOA okolje

dozoreva, se potreba po učinkovitem vodenju povečuje. Trenutno stanje namestitev SOA v

organizacijah je zelo napredovalo, skoraj 20 % jih ima vzpostavljeno SOA okolje med

podjetji ali preko celotnega podjetja, kar kaţe slika 4.2, ki je del ankete iz leta 2008, ki jo

je izvedel ebizQ (20).

Iz slike 4.2 je mogoče razbrati tudi, da se le slabih 15 % anketiranih podjetij od skupno 118

v letu 2008 še ni lotilo implementacije SOA, kar kaţe, da je začetno vznesenost SOA res

prerasla in je sedaj dozorela. Na to kaţe tudi dejstvo, da 85 % organizacij izvaja aktivnosti

na področju posvojitve SOA v svoje IT okolje.


Slika 4.2 Stopnja posvojitve SOA (20)

Za večino organizacij je SOA vodenje naslednji logični korak v evoluciji do SOA. Zato je

smiseln rezultat ankete, ki kaţe na to, da ima večina podjetji, tj. kar 66 %, izbrane ljudi za

SOA vodenje, medtem ko jih je 31 % ţe raziskovalo področje SOA vodenja. To pomeni,

da se 97 % vseh anketiranih podjetij aktivno angaţira na področju SOA vodenja.

Večina analitikov, priznanih avtorjev in proizvajalcev se strinja, da je SOA vodenje

kritično za uspeh in realizacijo koristi SOA. To potrjujejo tudi anketirana podjetja, kot

prikazuje slika 4.3, ki verjamejo, da je SOA vodenje kritična komponenta SOA strategije.

Kar 49 % jih verjame, da bi brez vodenja SOA propadla, ostalih 44 % pa jih je

identificiralo vodenje kot pomembno in zahtevano.

Slika 4.3 Pomembnost SOA vodenja (20)

Da bi laţje razumeli, kaj motivira organizacije za vpeljavo SOA vodenja, poglejmo sliko

4.4. Večina jih ţeli implementirati dobro prakso v SOA okolje in povečati usklajenost med

poslovanjem in IT kot najpomembnejšo korist SOA. Takoj za usklajenostjo je pomembna

agilnost podjetja, ki jo SOA zagotavlja skozi ponovno uporabo, ki je prav tako visoko

uvrščena med dejavniki za začetek SOA vodenja.

0% 5% 10% 15% 20%

Testiranje/preverjanje koncepta

V razvoju

Interne storitve znotraj oddelka

Interne storitve med oddelki

Preko celotnega podjetja

Med podjetji

Ostale/brez SOA

0% 10% 20% 30% 40% 50%

Kritično - brez vodenja SOA ne bi uspela

Pomembno - bo potrebno na neki točki razvoja

Ni pomembno


Slika 4.4 Ključni dejavniki za začetek SOA vodenja (20)

Tudi SOA vodenje vpelje nekaj izzivov, da pa bi pravočasno naslovili te izzive, naj nam

bodo v pomoč teţave, s katerimi se srečujejo drugi. Največje teţave, s katerimi se srečujejo

organizacije pri SOA vodenju, sestavlja kombinacija znanja, komunikacije in koordinacije,

kot prikazuje slika 4.5. Naslavljanje organizacijske strukture, financiranj in politik mora

biti osnova vsakega SOA vodenja.

Slika 4.5 Največji izzivi pri SOA vodenju (20)

Pri izbiri rešitve SOA vodenja različnih ponudnikov sta za organizacije pomembni

predvsem dve področji. Najbolj, tj. v kar 31 %, kot kaţe slika 4.6, organizacije cenijo

ponudnikova znanja in izkušnje, kot drugo pa podporo za heterogene sisteme, kar je

smiselno glede na to, da so navadno implementacije SOA okolja zelo raznolike zaradi

različnih aplikacij in IT komponent. Integrirana SOA platforma je iz tega razloga manj

pomembna, saj organizacije verjamejo, da bo njihovo okolje obsegalo heterogene sisteme.

0% 20% 40% 60% 80%

Ţelja implementirati dobro prakso

Povečati poslovno in IT usklajenost

Pridobiti realnočasovni vpogled v storitve

Zmanjšati tveganja SOA transformacije

Demonstrirati izmerjen ROI SOA

Realizirati ponovno uporabo storitev

Spremljati in komunicirati napredek SOA

Ostalo

0% 10% 20% 30% 40% 50% 60%

Odpor proti spremembam

Krivulja učenja/nezadostna znanja

Vrzel med poslovanjem in IT/organi. prepreke

Pomanjkanje vodstvene podpore ali sponzorstva

Financiranje

Pomanjkanje skladnega procesa vodenja in politik

Ostalo


Slika 4.6 Kriteriji za izbiro SOA vodenja (20)

Ker je SOA vodenje samo po sebi lahko velik izziv, organizacije iščejo v ponudnikih

znanja in izkušnje, da bi jih vodili skozi vpeljavo vodenja. V naslednjem poglavju bomo

predstavili pristope k SOA vodenju oziroma ogrodja, ki lahko organizacije vodijo pri

vpeljavi SOA vodenja in tako zmanjšajo potrebne napore za vpeljavo SOA vodenja.

4.5 Ogrodja SOA vodenja

Da bi izkoristili kar največ koristi SOA in pri tem ne povzročali dodatnih izzivov za

organizacije, se le-te lahko posluţijo uveljavljenih pristopov oziroma ogrodij za SOA

vodenje. SOA ogrodje mora biti takšno, da je usklajeno z ţelenimi poslovnimi in IT cilji

ter kompatibilno z aktualnimi pristopi IT in poslovnega vodenja.

Uspešno ogrodje za vodenje zahteva pravo razmerje med ljudmi, procesi in tehnologijo.

Formula za pravo razmerje leţi v razumevanju ciljev vodenja in kako bodo ti doseţeni.

Vsekakor ni SOA strategije, ki bi ustrezala vsem, kakor ni le enega SOA načrta za vse in ni

enega nabora politik in procedur, ki bi predstavljal SOA vodenje (6).

Zato smo identificirali ogrodja, ki lahko organizaciji pri teh izzivih pomagajo. Ni vsako

ogrodje za vsako organizacijo niti ni katerokoli ogrodje uporabno brez lastnega truda,

vloţenega v njegovo prilagoditev in posvojitev. Za pomoč pri izbiri ogrodja oziroma

pristopa k vodenju SOA smo nekatere najbolj popolne zbrali v tabeli 4-1. Skozi

raziskovanje SOA vodenja smo v tabelo dodali tudi elemente vodenja, pri katerih smo

zaznali, da bi bili koristni za uspešnost vodenja in posledično zaţeleni za vsako ogrodje

SOA vodenja.

0% 10% 20% 30% 40% 50% 60%

Ponudnikova znanja in izkušnje s SOA

Podpora heterogenosti/najboljše te vrste

Ponuja široko, celovito vodenje

Ponuja integrirano SOA platformo


Pri identificiranju elementov smo veliko pozornosti namenili izzivom, s katerimi se

organizacije, ki uvajajo SOA vodenje v svoje okolje, srečujejo. Naloga dobrega vodenja

mora biti, da naslovi teţave, preden do njih pride. Smiselno je uporabiti te izkušnje pri

iskanju ustreznega ogrodja SOA vodenja. Niso pa pomembni le izzivi in teţave, vključimo

lahko tudi vzroke za začetek vpeljave SOA vodenja pri teh organizacijah. Smiselno je, da

naslovimo tudi vidike, ki predstavljajo gonilo ţelje po uvedbi SOA vodenja. Pri tem smo

identificirali naslednje elemente SOA vodenja:

Financiranje: skoraj 40 % organizacij (slika 4.5) se srečuje z izzivi pri financiranju

SOA projektov.

Nabor politik: organizacije čutijo pomanjkanje ustreznih politik in procesov

vodenja v 40 % (slika 4.5).

Dobra praksa: kar 65 % organizacij vpeljuje vodenje zaradi dobre prakse (slika

4.4).

Organizacijske strukture: pogosto so ovira pri doseganju ponovne uporabe, prav

tako pa so del vsakega učinkovitega vodenja ter kot take prepoznane tudi s strani

organizacij pri SOA vodenju (20).

Specifične vloge/odgovornosti: so del organizacijske strukture, zato je smiselno, da

organizacije verjamejo, da uspešno definirane strukture predstavljajo 50 %

uspešnosti SOA vodenja (20).

Podpora s tehnologijo in orodji: organizacije potrebujejo tehnologijo in orodja, ki

bodo podpirala njihovo SOA vodenje (slika 4.6).

Zaradi zasnove storitveno usmerjene arhitekture smo za potrebe vodenja identificirali še:

Življenjski cikel SOA: vodenje storitveno usmerjene arhitekture je potrebno

povezati z obstoječimi postopki vodenja in ga razširiti po celotnem ţivljenjskem

ciklu SOA (6).

Življenjski cikel storitve: storitev je temeljni gradnik SOA in bistvenega pomena,

njen ţivljenjski cikel pa je s strani Software AG identificiran kot ključna zahteva

SOA vodenja (21).


Kot del splošnih principov vodenja, v katere smo dobili vpogled skozi prvo poglavje

vodenja, pa še:

Model metrik: naj ekipa SOA vodenja v skladu z zrelostjo SOA okolij definira

jasne metrike za merjenje efektivnosti, ki bodo pokazale napredek pri dozorevanju

prizadevanj SOA.

Zrelostni model: vzpostavitev SOA načrta, standardov, politik in procedur naj bo

usklajena s stopnjo zrelosti SOA.

SOA načrt: preobseţnosti vodenja se lahko izognemo, če se drţimo zastavljenega

načrta, ki bo postopoma naslavljal različne vidike vodenja, usklajene s cilji vodenja

in zahtevami organizacije.

Ti elementi bodo skupaj pomagali izpopolnjevati model SOA vodenja organizacije skozi

čas njenega izvajanja. SOA je učinkovita le, če izpolnjuje poslovne cilje, ki peljejo SOA

naprej, zato mora vodenje izbrati metrike, ki bodo dokazale, da so ti cilji doseţeni.

SOA metrike je potrebno načrtovati zgodaj v fazi SOA načrtovanja, ne samo za

spremljanje napredka, ampak tudi za usmerjanje SOA prizadevanj. To medsebojno

delovanje SOA vodenja in SOA metrik pomaga zagotoviti ţeleno obnašanje udeleţencev v

SOA okolju (22). Model mora vsebovati poslovne metrike, procesne metrike, metrike

zmogljivosti, storitvene pogodbe (service-level agreements – SLAs) in metrike SOA

vodenja, kot je SOA skladnost, ter izjeme v poročilih razvijalcev.

SOA načrt, sestavljen s pomočjo zrelostnega modela, omogoča organizacijam, da začnejo

SOA popotovanje ter upravljajo transformacijo na SOA, ki gradi postopno z vsakim

korakom, in končno dostavo pričakovanih SOA koristi: ponovno uporabo storitev,

izboljšano integracijo, interoperabilnost in poslovno agilnost (6). Pri identifikaciji

elementov in v potrditev izbranih smo si pomagali še z naslednjimi viri: (14), (20) in (23).

Obstaja vse več ogrodij SOA vodenja, ki zagotavljajo koncepte vodenja in podporo

organizacijam pri njegovi vpeljavi. Nekatera so usmerjena bolj specifično v določena

področja, medtem ko druga celoviteje pokrijejo vse koncepte.


Nekatera od teh ogrodij ponujajo:

vodilni na IT trgu, kot sta IBM in Oracle (6), (19), (24),

nišni proizvajalci in svetovalci SOA, kot so AgilePath, Software AG in SOA

Software (21), (25), (24),

neodvisna podjetja za svetovanje, kot je CBDi (26),

industrijske organizacije, kot je The Open Group (18).

V tabeli 4-1 smo navedli ogrodja SOA vodenja različnih ponudnikov z elementi vodenja,

kot smo jih identificirali zgoraj. Za prikaz popolnosti vsakega izmed ogrodij smo v tabeli

označili, ali ogrodje naslovi vidike elementa ali ne. Kaţe se, da izbrana ogrodja zelo dobro

naslavljajo izbrane elemente, jasno pa se kaţe tudi razlika v tipih ponudnikov, saj oba

predstavnika vodilnih iz IT trga ponujata za svoje ogrodje vodenja tudi tehnologijo z orodji

za podporo predlaganega ogrodja. Tudi Software AG kot nišni ponudnik SOA se je na tem

področju izkazal in ponudil tehnologijo in orodja, ki podpirajo njegovo ogrodje vodenja.

Tabela 4-1 Pristopi k SOA vodenju

Legenda:

● – vsebuje

○ – ne vsebuje

Org

an

izaci

jsk

a

stru

ktu

ra

Sp

ecif

ičn

e

vlo

ge/

od

govorn

ost

i

Dob

ra p

rak

sa

Fin

an

cira

nje

SO

A ţ

ivlj

enjs

ki

cik

el

Ţiv

ljen

jsk

i ci

kel

stori

tve

Kata

log p

oli

tik

SO

A n

ačr

t

SO

A z

relo

stn

i m

od

el

Mod

el m

etri

k

Pod

pora

s t

ehn

olo

gij

o

in o

rod

ji

AgilePath ● ● ● ● ● ● ● ● ● ● ○

IBM ● ● ● ○ ● ● ● ○ ● ● ●

Oracle ● ● ● ● ● ● ● ○ ● ● ●

Software AG ● ● ● ● ○ ● ● ● ● ○ ●

CBDI ● ● ● ● ● ● ● ● ● ● ○

The Open Group ● ● ● ● ● ● ● ● ● ● ○


Ta ogrodja so lahko zelo koristna, saj opredelijo specifične slovarje in prepoznajo

zmoţnosti SOA vodenja. Nekateri celo predlagajo referenčno arhitekturo in opredelijo

najboljšo prakso, zlasti ponudniki posebnih tehnologij in orodij za podporo vodenju.

Ogrodja teh ponudnikov so bila razvita na podlagi izkušenj iz dejanskih organizacij in kot

takšna predstavljajo abstrakten in posplošen model ključnih značilnosti SOA vodenja, kot

jih vidi ponudnik.

Pogost zlom SOA vodenj ni posledica teh ogrodij, ampak nezmoţnosti organizacij, da

posvojijo in prilagodijo ogrodja vodenja svojemu kontekstu poslovanja. Medtem ko

ogrodja predlagajo na splošno, kaj je vključeno v SOA vodenje, ne povedo organizaciji

posebej, kaj je potrebno storiti ter predvsem kako to storiti.

V nadaljevanju smo predstavili ogrodja ponudnikov iz tabele 4-1 in njihov pogled na

definicijo SOA vodenja z namenom olajšati nadaljnje raziskovanje ogrodij SOA vodenja,

ki so trenutno na voljo organizacijam za posvojitev.


4.5.1 AgilePath model SOA vodenja

Po mnenju AgilePath »je SOA vodenje opredelitev, implementacija in nenehno izvrševanje

odločitvenega modela SOA in ogrodja odgovornosti, ki zagotavljata organizaciji

zasledovanje ustrezne SOA strategije, usklajene z IT in poslovnimi cilji, ter izvaja to

strategijo v skladu s smernicami in omejitvami, določenimi s strani telesa SOA načel in

politik«, medtem ko »so SOA politike uveljavljene s pomočjo celostnega modela

uveljavljanja, sestavljenega iz različnih mehanizmov uveljavljanja politik, kot so odbor

vodenja, procesi vodenja, preverjanja in presoje ter orodja in tehnologije, ki podpirajo

vodenje« (25).

AgilePathov štiriplastni model SOA vodenja (AgilePath Four tier SOA Governance

Model) je predstavljen na sliki 4.7. Ta model je vezan na poenoten model uveljavljanja

politik, ki ga je potrebno uveljaviti v celotnem procesu vodenja podjetja in v konceptu

upravljanja zmoţnosti vodenja, ki skrbi za dobro formo vodenja skozi čas.

Dodatne informacije je mogoče najti na: http://www.agile-path.com.

Slika 4.7 AgilePathov štiriplastni model SOA vodenja (25)


4.5.2 IBM-ova metoda SOA vodenja in upravljanja

Po mnenju IBM »je SOA vodenje razširitev obstoječega IT vodenja in je posebej

orientirano na ţivljenjski cikel storitve, metapodatkov in kompozitnih aplikacij v

storitveno usmerjeni arhitekturi organizacije« (19).

Skladno s to definicijo pristop IBM-a k SOA vodenju temelji na konceptu ţivljenjskega

cikla, ki pa je različen od IBM-ovega SOA ţivljenjskega cikla in ima v vsaki fazi

opredeljene korake in končne izdelke, kakor je prikazano na sliki 4.8. Faze na diagramu in

koraki v posamezni fazi so neodvisni in veljajo za kateri koli proces ali delovno strukturo.

Nekateri specifični elementi, ki so zajeti v ogrodju, so osnovani na ţivljenjskem ciklu

storitve, od identifikacije do namestitve in uporabe.

IBM-ova metoda SOA vodenja in upravljanja (IBM SOA Governance and Management

Method) je iterativen pristop k uvedbi učinkovitega vodenja za podporo storitveno

usmerjene arhitekture (19).

Dodatne informacije je mogoče najti na:

http://www-01.ibm.com/software/solutions/soa/gov/.

Slika 4.8 IBM-ova metoda SOA vodenja in upravljanja (19)


4.5.3 Oraclovo ogrodje SOA vodenja

Po mnenju Oracla “je SOA vodenje mogoče opredeliti kot interakcijo med politikami (kaj

– what), sprejemalci odločitev (kdo – who) in procesi (kako – how) za zagotovitev SOA

uspeha«. Sprejetje politik in postopkov za zagotovitev pravočasne in ustrezne izvedbe

SOA načrta je jedro SOA vodenja (27).

Oraclovo ogrodje SOA vodenja (Oracle SOA Governance Framework) je organizirano

okoli vplivnih ključnih točk politik SOA vodenja. Verjamejo, da je za uspešno ogrodje

SOA vodenja potrebno pravo razmerje ljudi, procesov in tehnologij, kot je prikazano na

sliki 4.9. Njihovo ogrodje vodenja se razprostira čez celoten ţivljenjski cikel SOA ter pri

tem premosti in povezuje edinstvene stopnje, ki opredeljujejo in opisujejo ta ţivljenjski

cikel.

Ogrodje vsebuje tudi proces šestih korakov, ki pomagajo podjetju doseči napredek pri

izboljšanju zmoţnosti izvajanja SOA vodenja, ter nudi najboljše prakse za vsak korak v

tem procesu.


http://www.oracle.com/technologies/soa/soa-governance.html.

Slika 4.9 Oraclovo ogrodje SOA vodenja (6)


4.5.4 Ogrodje SOA vodenja podjetja Software AG

Po mnenju Softwara AG “je SOA vodenje podmnoţica IT vodenja. Vzpostavlja politike,

kontrole in mehanizme uveljavljanja, potrebne za uspešno SOA posvojitev, s povečanjem

vidljivosti in kontrole IT-ja nad SOA razvojem in namestitvijo,« in nadalje: »SOA vodenje

je umetnost zaotavljanja, da podjetje ustvarja prave lego kocke, jih zdruţuje na prave

načine in to izvaja dosledno preko celotnega podjetja, da bi učinkovito uresničilo poslovne

cilje« (21).

Referenčno ogrodje SOA vodenja (Software AG Reference SOA Governance Framework)

Softwara AG je zasnovano na ravni storitvenega ţivljenjskega cikla in je podprto z

naborom njihovih produktov. Ogrodje grafično predstavlja slika 4.10, ki razvršča

priporočene elemente za učinkovito izvajanje SOA vodenja in upravljanja s SOA viri v tri

skupine: organizacijske elemente, povezane z ljudmi, norme, povezane s politikami,

postopki in procesi, ter tehnologijo, povezano z orodji.


http://www.softwareag.com/Corporate/products/wm/soa_governance/default.asp.

Slika 4.10 Referenčno ogrodje SOA vodenja Softwara AG (21)


4.5.5 Ogrodje SOA vodenja CBDi SAE

Po mnenju CBDi »je SOA vodenje del IT vodenja, ki se nanaša na organizacijske

strukture, politike in postopke, ki zagotavljajo, da prizadevanja SOA organizacije vzdrţijo

in razširijo poslovno in IT strategijo ter doseţejo ţelene rezultate« (26). Verjamejo, da

mora ogrodje SOA vodenja delovati znotraj konteksta poslovne in IT strategije ter ogrodij

vodenja. Vodenje je v tem primeru zagotovljeno skozi identifikacijo in postavitev ustreznih

politik.

CBDi-jevo ogrodje SOA vodenja (CBDi SOA Governance Framework) je predstavljeno na

sliki 4.11 v obliki niza različnih pogledov, ki naslavljajo, kako (how), kaj (what), kdo

(who) in kdaj (when) vidike SOA upravljanja (26). CBDi zagovarja, da vodenje potrebuje

osnovo v jasni opredelitvi politik, pri čemer so tudi mnogim organizacijam pomagali.

Izpopolnili so njihov pristop SOA vodenja z izboljšanjem temeljev z jasnimi opredelitvami

politik. Izkušnje, ki so jih s tem pridobili, učijo, da morajo organizacije napredovati po

lastnih zmoţnostih in na način, ki je realen v smislu zrelosti njihove SOA posvojitve.

Dodatne informacije je mogoče najti na: http://www.cbdiforum.com.

Slika 4.11 Ogrodje vodenja CBDi-SAE (26)


4.5.6 Ogrodje SOA vodenja organizacije The Open Group

Po mnenju The Open Group je »na SOA vodenje potrebno gledati kot aplikacijo

poslovnega vodenja, IT vodenja in vodenja arhitekture podjetja1 (Enterprise Architecture

EA) za storitveno usmerjene arhitekture. Posledično SOA vodenje razširja EA in IT

vodenje, da bi zagotovila, da so koristi, ki jih SOA ponuja, izpolnjene. To zahteva vodenje

ne samo vidikov izvajanja SOA, ampak tudi aktivnosti strateškega načrtovanja.« (18)

Za naslovitev SOA izzivov potrebuje podjetje celovit in prilagojen reţim SOA vodenja, ki

zajema procese, organizacijske strukture in podporno tehnologijo ter se lahko namesti v

postopnem iterativnem načinu. The Open Group ogrodje SOA vodenja (The Open Group

SOA Governance Framework) na sliki 4.12 sestavljata referenčni model SOA vodenja

(SOA Governance Reference Model – SGRM), ki je uporabljen za izhodišče, in SOA

metoda vitalnosti (SOA Governance Vitality Method – SGVM), ki predstavlja proces

opredelitve, izboljšanja in obdelave povratnih informacij za opredelitev specifičnega in

prilagojenega reţima SOA vodenja (18).

Dodatne informacije je mogoče najti na: http://www.opengroup.org/projects/soa.

Slika 4.12 Ogrodje SOA vodenja organizacije The Open Group (18)

1 Vodenje arhitekture podjetja je praksa in usmeritev, s katero se arhitektura podjetja in ostale arhitekture

upravljajo in nadzorujejo na ravni podjetja.


4.6 Posvojitev SOA ogrodja

Mnoge organizacije, ki razmišljajo o SOA posvojitvi, so vsaj nekoliko seznanjene z

ogrodji vodenja različnih proizvajalcev in industrijskih organizacij ter morebitnih drugih

ponudnikov. Vendar pa se potrebe teh organizacij po SOA vodenju lahko zelo razlikujejo.

Jasno je, da ista rešitev SOA vodenja ali ogrodja ni primerna za vsakogar. Nekatere razlike

so: kulturne razlike ali tehnična izpopolnjenost, področje uporabe, disciplina procesov,

poslovni cilji in trţni profil. V večini primerov ni zaţeleno niti mogoče, da organizacija

neposredno sprejme rešitev enega ponudnika. Organizacija lahko ugotovi, da so njene

potrebe SOA vodenja edinstvene ali pa lastnosti obstoječe infrastrukture, aplikacije in

trenutni pristop IT vodenja povzročajo omejitve, ki izključujejo katero izmed strategij

ponudnikov. Te organizacije lahko razmišljajo tudi v smeri gradnje lastne implementacije

SOA vodenja (28).

Medtem ko se organizacije lahko zavedajo, da so na voljo ogrodja vodenja, so lahko prav

tako zmedene, kaj SOA vodenje lahko stori za njih, kaj SOA vodenje dejansko pomeni za

njih, katere specifične zmogljivosti vodenja morajo izvajati in katero strategijo za sprejetje

teh zmogljivosti morajo uporabiti. Najverjetneje se zavedajo in poznajo potrebe po SOA

vodenju, ampak ne vedo, kako uvesti SOA vodenje znotraj svojega specifičnega konteksta

delovanja.

Vsekakor zato obstaja potreba po nepristranski tehniki, ki izpostavi in poenostavi ključne

elemente obstoječih komercialnih modelov in omogoča organizacijam hitrejše

razumevanje, kaj je potrebno storiti za uspešno uvedbo SOA vodenja. Primer pristopa, ki

ustreza tem lastnostim in podpira organizacije pri razumevanju njihovih potreb SOA

vodenja ter konteksta, v katerem je potrebno uvesti SOA vodenje, predstavlja tehnika,

predlagana s strani Software Engineering Instituta (SEI), ki temelji na scenarijih (A

Scenario-Based Technique for Developing SOA Technical Governance) (28). Ta pristop se

osredotoča le na tehnične vidike SOA vodenja.

Organizacije lahko v implementacijah SOA igrajo različne vloge ali naslavljajo več

perspektiv: gradijo storitve (ponudniki storitev), razvijajo aplikacije, ki uporabljajo storitve

(uporabniki storitev), in tudi oblikujejo svojo SOA infrastrukturo (ponudnik


infrastrukture), pogosto zaradi edinstvenih zahtev SOA okolja, ki ga vzpostavljajo.

Organizacije lahko prevzamejo samo eno ali dve od teh vlog, kot na primer tiste, ki

razvijajo ali uporabljajo storitve tretjih oseb. Učinkovito SOA vodenje za te organizacije

mora upoštevati vsako operativno perspektivo v danem kontekstu. Tehnika, predlagana s

strani SEI, upošteva te perspektive brez podrobne poglobitve v specifične vloge. Vsak

scenarij zagotavlja kontekst in zahteve specifične situacije v zvezi s tehničnimi vidiki

posameznega SOA projekta.

Na tem mestu se pojavlja nov koncept perspektiv, kot je uporabnik storitve in ponudnik

storitve ali infrastrukture, ki je po mnenju SEI pomemben (28) pri uvedbi vodenja.

Analizirana ogrodja SOA vodenja gredo v zelo specifične podrobnosti o vlogah in

odgovornostih (npr. SOA arhitekt, SOA načrtovalec), ki so seveda prav tako pomembne.

Značilnosti tehnike SEI, temelječe na scenarijih za uvedbo SOA vodenja, so (28):

nevtralnost glede na ponudnike in uporabnost, ne glede ne izbrano ogrodje

ponudnika ali lastno ogrodje SOA vodenja,

temelji na scenarijih za zajetje specifičnih potreb vodenja v organizacijah,

zaveda se tveganja za podporo organizacijam pri analizi in odpravi morebitnih

teţav pri vodenju.

Namen tehnike ni nadomestiti obstoječe komercialne ponudbe, ampak nuditi izhodišče za

pomoč organizacijam pri razumevanju njihovih posebnih potreb SOA vodenja in

navigacijo skozi razpoloţljive ponudbe ogrodij SOA vodenja. Tehnika se lahko uporabi v

povezavi z ogrodji SOA vodenja, ki smo jih obravnavali, ali katerim koli drugim

obstoječim ogrodjem.

4.7 Pregled tehnike, temelječe na scenarijih

Software Engineering Institute predlaga tehniko, temelječo na scenarijih, ki zaposluje šest

aktivnosti za razumevanje konteksta organizacije in za ustvarjanje scenarijev, ki se

nanašajo na ogrodja SOA vodenja.


Aktivnosti tehnike SEI so (28):

1. vzpostavitev konteksta – gonilniki SOA vodenja, ogrodje in obseg,

2. razvoj klasifikacijskih shem,

3. vzpostavitev interesnih skupin za potrebe SOA vodenja,

4. ustvarjanje in dodelava scenarijev za potrebe SOA vodenja,

5. konsolidiranje scenarijev,

6. prilagoditev politik na način, da ustrezajo ogrodju SOA vodenja.

Vizualna predstava tehnike je predstavljena na sliki 4.13, kjer smer puščic prikazuje tok

aktivnosti. Ta slika kaţe, da se prve tri aktivnosti lahko izvajajo hkrati. Toda za eno

ponovitev jih je potrebno dokončati, preden lahko posamezna skupina začne razvoj

scenarijev. Preostale aktivnosti so zaporedne. Zanka na sliki 4.13 prikazuje prehod iz

aktivnosti 6 nazaj v aktivnost 1, ki predstavlja postopen pristop k SOA vodenju (28).

Slika 4.13 SEI-eva tehnika implementacije SOA vodenja (28)


Aktivnosti 1 in 2 na sliki 4.13 (vzpostavitev konteksta in razvoj klasifikacijskih shem) se

izvedeta na ravni celotne organizacije in ju je potrebno opraviti s centralnim organom (na

primer SOA center odličnosti1) za pospeševanje splošnega soglasja. Vzpostavitev

interesnih skupin, aktivnost 3, zahteva medsebojno sodelovanje med centralnim organom

in različnimi vrstami poslovanja vključenih (ali med načrtovanimi, da se vključijo) v SOA

prizadevanja. Aktivnost 4 (ustvarjanje scenarijev) se ponovi za vsako od organizacijskih

enot, opredeljenih v aktivnosti 3. Zadnji dve aktivnosti, konsolidiranje scenarijev in

prilagoditev politik, gradita na rezultatih preteklih aktivnosti. Aktivnost 5 zdruţuje vse

scenarije, opredeljene v aktivnosti 4, z vsako skupino. Aktivnost 6 se nanaša na delo

prejšnjih aktivnosti in ogrodje SOA vodenja, ki ga organizacija izbere (28). Za pomoč pri

izvedbi aktivnosti 4, pri kateri se ustvarijo scenariji, je SEI priskrbel šablono za zajetje

elementov konteksta scenarija in preslikavo stanja vsakega elementa (identificiranje,

ustvarjanje, posodobitev) v eno izmed aktivnosti iz slike 4.13.

Nerealno bi bilo pričakovati, da lahko vse potrebne zahteve SOA vodenja zajamemo v eni

iteraciji te tehnike. Organizacija lahko v ta namen periodično izvede nov cikel procesa te

tehnike za identifikacijo novih scenarijev in pripadajočih politik SOA vodenja ter

mehanizmov za njihovo podporo. Ko se zahteve spreminjajo, se lahko skupine zaprosi, da

premislijo o posodobitvi obstoječih scenarijev in ustvarjanju novih, ki zajemajo njihove

izboljšave in potrebne spremembe. Te spremembe se lahko nato preslikajo nazaj v

obstoječe ogrodje SOA vodenja (28).

Ponudniki in druga obstoječa ogrodja SOA vodenja so uporabno izhodišče za organizacije

pri uvajanju SOA. Vendar pa sprejetje obstoječega ogrodja, ne da bi upoštevali edinstvene

potrebe organizacije, lahko povzroči neučinkovitost, nepotrebno delo ali, še huje, popoln

neuspeh (28). Namesto sprejetja na zahtevo se mora sprejetje ogrodja SOA vodenja začeti

z analizo organizacijskih potreb za SOA vodenje. Tehnika SEI, ki temelji na scenarijih,

zagotavlja, da je nevtralna glede na ponudnike, skladna z obstoječimi ogrodji SOA

1 SOA center odličnosti (Center of Exellence – CoE) je organizacija, ki osvoji in spodbuja najboljšo prakso,

znanja in vrhunske pragmatične rešitve na področju SOA. CoE uvaja strogost in disciplino v različnih SOA

pobudah in zagotavlja koristi s krepitvijo spretnosti in usposobljenosti za vzdrţevanje uspešne izvedbe vedno

kompleksnejših SOA pobud.


vodenja, preprosta in enostavno razširljiva. Ta tehnika se lahko uporabi tudi v zgodnjih

fazah uvajanja SOA za postavitev temeljev SOA vodenja organizacije. Prav tako pa tudi za

zajemanje neizogibnih sprememb potreb po vodenju, ko je SOA ţe nameščena.

4.8 SOA register in repozitorij

Ko doseţemo točko, ko imamo definiran načrt vodenja, nam lahko pri uveljavljanju tega

načrta pomagajo tudi orodja. Dobro mesto, kjer lahko uporabimo tehnologijo in orodja za

uveljavljanje politik, je SOA register in repozitorij kot centralno skladišče1 vseh SOA

artefaktov. Na sliki 4.14 vidimo, da je register in repozitorij osrednja komponenta, na

katero se sklicujeta tako ponudnik kot uporabnik storitve; ponudnik, kadar objavlja

vmesnike storitev oz. reference na WSDL2 (Web Service Description Language) datoteke

v register in ostale dokumente v repozitorij, ter na drugi strani uporabnik, ki išče storitve,

jih odkrije in uporabi.

Slika 4.14 SOA register in repozitorij kot centralno skladišče

1 SOA register in repozitorij imenujemo tudi sistem zapisov (System of Records – SOR) oziroma centralno

skladišče zapisov.

2 WSDL je XML format za opisovanje mreţnih storitev kot nabor končnih točk, ki delujejo nad sporočili,

katera vsebujejo dokumentno ali postopkovno usmerjene informacije.


Njegova vloga se zato vedno bolj razširja na področje vodenja, medtem ko je njegova

primarna naloga uresničitev enega izmed temeljnih načel SOA, tj. ponovna uporaba, kajti s

centralnim skladiščem je tudi IT arhitektom laţje najti in ponovno uporabiti obstoječe

programske vire.

SOA register in repozitorij mora zagotavljati zmoţnosti vodenja in tako omogočati

organizacijam, da opredelijo in uveljavijo politike, ki urejajo vsebino registra in uporabo

vsebine skozi njen celoten ţivljenjski cikel. Ker se politike razlikujejo od organizacije do

organizacije, mora SOA register in repozitorij omogočiti organizaciji uveljavljanje lastnih

politik za vodenje katere koli vrste storitvenih artefaktov skozi celoten ţivljenjski cikel.

Prav tako mora ponujati ogrodje, na katerem je mogoče zgraditi lasten ţivljenjski cikel

vodenja za storitvene artefakte.

Zaradi vedno večje kompleksnosti implementacij SOA je nemogoče pričakovati, da lahko

z WSDL datoteko opišemo vse lastnosti storitve, zato mora repozitorij omogočati shrambo

dodatnih dokumentov in metapodatkov (29). Ni dovolj le funkcionalnost registra v SOA

okolju, potreben je tudi repozitorij, kar je 4razvidno iz slike 4.14. Register poskrbi za

metapodatke, na katere lahko gledamo tudi kot na reference na dokumente, medtem ko

repozitorij vsebuje podatke oziroma konkretne dokumente. Zgradbo in vire, ki jih vsebuje

vsak izmed njiju v večini produktov z lastnostmi registra in repozitorija, prikazuje slika

4.15.

Slika 4.15 Konceptualna shema SOA registra in repozitorija


Kadar organizacije ocenjujejo produkte z lastnostmi registra in repozitorija za uvedbo v

svoje SOA okolje, navadno ti produkti spadajo v eno izmed naslednjih kategorij (29):

1. nestandardni lastni registri repozitoriji,

2. UDDI registri brez repozitorija,

3. UDDI register z lastnim nestandardnim repozitorijem,

4. ebXML register in repozitorij,

5. kombinacija UDDI registra in ebXML registra in repozitorija.

UDDI register nudi podmnoţico zmogljivosti, ki jih ponuja ebXML register. V praksi nudi

le register brez repozitorija (29). UDDI je z verzijo 2.0 postal OASIS standard, trenutno je

aktualna verzija 3.0. EbXML je prav tako OASIS standard, ki pa je postal tudi del

standardov ISO 15000. Trenutna verzija 3.0 ni uporabljena v večjem številu registrov in

repozitorijev na trgu, saj ima v teh UDDI še vedno veliko prednost.

4.9 Ponudniki celostnih tehnoloških rešitev SOA vodenja

Tehnologije za SOA vodenje se kot vsak drug nabor tehnologij trudijo nasloviti potrebe

SOA sfere in več (24). Magični kvadrat na sliki 4.16 je Gartnerjev grafični prikaz stanja na

trgu za določeno obdobje. Prikazuje

analizo podjetij, ocenjenih z merili, ki

jih postavi Gartner za določen trg. Pri

iskanju tehnološkega orodja, ki bi kar

se da celovito pripomoglo k

učinkovitemu SOA vodenju, se bomo

posvetili vodilnim podjetjem iz

Gartnerjevega magičnega kvadranta.

Slika 4.16 Magični kvadrant celostnih

tehnoloških rešitev SOA vodenja (24)


Izkaţe se, da produkti z lastnostmi registra in repozitorija zelo dobro podpirajo SOA

vodenje. V tabeli 4-2 smo predstavili produkte vodilnih proizvajalcev iz Gartnerjevega

magičnega kvadranta celostnih tehnoloških rešitev iz slike 4.16, ki imajo lastnosti registra

in repozitorija. Dodali pa smo tudi, katero izmed standardnih implementacij registrov in

repozitorijev uporabljajo (UDDI ali ebXML) ter v katero kategorijo iz poglavja zgoraj se

uvrščajo.

Tabela 4-2 Produkti SOA registra in repozitorija

Proizvajalec Produkt UDDI ebXML Kategorija

Open Source freebXML Registry

3.0

ne 3.0 4

Sun

Microsystems

Service Registry 3.0 3.0 5

IBM WebSphere Service

Registry and

Repository 6.2

le

sinhronizacij

a

ne 1

Oracle Registry and

Repository 10.3

3.0 ne 3

SOA Software Policy Manager 6.0 3.0 ne 3

Software AG CentraSite

Governance Edition

7.1

3.0 le

sinhronizacija

3

HP SOA Systinet 3.0 3.0 ne 3

Tibco ActiveMatrix 2.2 3.0 ne 3


Iz tabele 4-2 je mogoče razbrati, da je med vodilnimi ponudniki implementiran UDDI 3.0

in da večina produktov spada v skupino UDDI registrov z lastnim nestandardnim

repozitorijem. Tukaj je IBM s svojim produktom izjema, saj je razvil popolnoma svoj

standard in nudi le določen del UDDI vmesnikov za potrebe sinhronizacije med registri.

IBM obvladuje 70 % SOA trga, preostanek trga si deli 12 drugih proizvajalcev s

primerljivimi trţnimi deleţi, nobeden od njih pa v letu 2009 ni bil sposoben zbrati več kot

8 % trga. IBM je vodilni v oblikovanju industrijskih de facto SOA standardov (30).


5 RAZVOJ POSTOPKOV ZA SOA VODENJE V WSRR

Namen orodij je olajšati ali omogočiti določeno delo. Področje SOA vodenja pri tem ni

izjema, kakor smo spoznali v poglavju 4.8. Eno izmed teh orodij je IBM-ov produkt

WebSphere Service Registry and Repository (WSRR) iz tabele 4-2. Ta ponuja zmogljivost

registra in repozitorija, s čimer ima potencial podpore vodenju, zato smo ga v tem poglavju

vzeli pod drobnogled. Pogledali smo, katere mehanizme za podporo SOA vodenju ima na

voljo in kako jih uporabiti ter prilagoditi za specifične potrebe organizacij. V WSRR smo

razvili nabor postopkov, ki imajo zmoţnosti podpreti SOA vodenje, da bi prikazali način,

kako lahko organizacije prilagodijo WSRR, da le-ta podpre njihov načrt SOA vodenja.

5.1 Funkcije, ki omogočajo vodenje

WSRR podpira bogat nabor razširljivih funkcij vodenja, tudi moţnost modeliranja lastnega

ţivljenjskega cikla storitev za vodene artefakte, definiranje veljavnih prehodov med stanji

storitve, razvoj vtičnikov za zaščito prehodov med stanji in določitev akcij/obvestil, ki se

morajo izvršiti ob prehodu. Prav tako ponuja vmesnik za analizo vpliva sprememb na

vsebino WSRR ter nudi revizijo sprememb (31).

Potrebno je še enkrat poudariti, da področje vodenja SOA okolja presega katerikoli

posamezen izdelek. Vendar je WSRR zelo zmogljiv produkt, ki omogoča SOA vodenje, in

ima številne mehanizme, ki omogočajo izvajanje postopkov vodenja, ki so bili določeni v

okviru svojega poslovnega modela (31).

WSRR omogoča vodenje storitev s pomočjo nekaterih vgrajenih mehanizmov:

opredelitev in uveljavitev življenjskega cikla storitev za vodene vire,

validacijo in notifikacijo dejavnosti in dogodkov, povezanih s spremembami

in razvojem v ţivljenjskem ciklu storitve ali storitve informacijskega modela,


opredelitev, uveljavitev in vpeljavo varnostnih politik, ki omejujejo dostop do

informacij storitev in izvajanja njenih operacij,

analizo vpliva artefakta na artefakte, s katerimi je ta v povezavi,

sistem dovoljenj, ki omogoča tudi zelo fino nastavitev dovoljenj za akcije in

artefakte.

V nadaljevanju smo opredelili in uveljavili lasten ţivljenjski cikel storitev ter razvili lastna

vtičnika za validacijo in notifikacijo dejavnosti in dogodkov, pogledali sistem dovoljenj in

orodje za analizo vpliva.

5.2 Opredelitev in uveljavitev ţivljenjskega cikla storitev

Kakor so si SOA implementacije različne, so si posledično tudi definirani SOA ţivljenjski

cikli. Nujno je, da orodje podpira definiranje lastnih ţivljenjskih ciklov za izbrane

artefakte, ki so shranjeni v njem. WSRR omogoča definiranje lastnih ţivljenjskih ciklov na

enostaven in transparenten način. Obstaja pa teţava pri podpori večih različnih ţivljenjskih

ciklov hkrati, a tudi to pomanjkljivost se da odpraviti, kar smo prikazali na praktičnem

primeru definiranja t. i. lastnega ogrodja za ţivljenjske cikle.

Artefakti, shranjeni v WSRR, privzeto niso del ţivljenjskega cikla in zatorej niso vodeni

skozi ţivljenjski cikel. To lahko za izbran artefakt naredimo ročno s pomočjo

funkcionalnosti, ki ga naredi za del ţivljenjskega cikla. Ta funkcionalnost se imenuje

naredi vodenega (make governable), nasprotno, če ţelimo na neki točki artefakt izvzeti iz

ţivljenjskega cikla, ga je potrebno odstraniti iz vodenja (remove governance). V WSRR so

lahko vodeni tudi artefakti, ki niso v ţivljenjskem ciklu in torej niso vodeni (governed), a

lahko na njih vseeno izvajamo določene aktivnosti vodenja, npr. avtorizacijo in validacijo.

Pri načrtovanju ţivljenjskega cikla moramo razumeti, katera stanja (states) in prehode

(transitions) potrebujemo, katere vloge obstajajo in kako in kdaj ter kateri uporabniki

bodo uporabljali WSRR skozi različna stanja ţivljenjskega cikla. Potrebno je imeti jasno

definicijo, katere aktivnosti se morajo zgoditi, preden lahko nadaljujemo na naslednjo

stopnjo.


Iz UML terminologije je stanje faza v vedenjskem vzorcu entitete. Stanje predstavlja

vrednost atributov entitete. Da določimo stanja, moramo vedeti, kateri so atributi entitete,

ki jo ţelimo voditi, in kako se vrednosti teh atributov spreminjajo. Potrebujemo tudi

prehode med stanji. V UML kontekstu je prehod napredovanje iz enega stanja v drugo, ki

bo sproţeno z dogodkom. Prehod je tipično rezultat izvedbe dogodka, ki povzroči

pomembno spremembo v stanju entitete. Vedeti moramo torej tudi, katere akcije

povzročajo spremembe atributov entitete in posledično stanja.

Slika 5.1 predstavlja grafični prikaz diagrama stanj (State Machine) iz orodja IBM

WebSphere Integration Developer. Diagram stanj v svoji notaciji uporablja stanja in

prehode, zaradi česar je ustrezna tehnika za modeliranje ţivljenjskih ciklov.

Slika 5.1 Gradniki ţivljenjskega cikla

Pri namestitvi WSRR je v namen vodenja vnaprej nameščen enostaven ţivljenjski cikel

storitve, prikazan na sliki 5.2, ki izhaja iz IBM-ovega ţivljenjskega cikla SOA.

Slika 5.2 Vnaprej nameščen privzeti WSRR ţivljenjski cikel storitve


Privzet ţivljenjski cikel iz slike 5.2 podpira le ţivljenjski cikel storitve, in to v najvišjem

abstraktnem pogledu, in kot tak ne more zadostiti vsem vidikom SOA vodenja. Večina

organizacij potrebuje več ţivljenjskih ciklov za različne podatke ali metapodatke, ki jih

shranjujejo v WSRR, kateri pa privzeto podpira le en ţivljenjski cikel, zaradi česar se je

treba posluţiti posebnih tehnik za dosego podpore več ţivljenjskih ciklov. V ta namen smo

opredelili lastno ogrodje, ki bo podpiralo razširjen ţivljenjski cikel storitev ter dodatne

ţivljenjske cikle drugih podatkov ali metapodatkov, ki so lahko shranjeni v WSRR in

katere bi ţeleli voditi skozi ţivljenjski cikel.

Najboljši način za opredelitev lastnega ţivljenjskega cikla je razvoj novega diagrama stanj

(State Machine) z uporabo ustreznega orodja. To pomeni, da je potrebno ustvariti datoteko

SACL1 (State Adaptive Choreography Language), ki opisuje diagram stanj in je potrebna

za vnos novega ţivljenjskega cikla v WSRR. SACL datoteko je mogoče ustvariti tudi

ročno, mi smo v ta namen uporabili orodje IBM WebSphere Integration Developer.

Uporaba SACL omogoča definirati tako imenovane kompozitne diagrame stanj (composite

state machines), ki lahko v bistvu sami predstavljajo ţivljenjski cikel, vsebovan v večjem

ţivljenjskem ciklu. Kompozitni diagram stanj lahko uporabimo za enkapsulacijo

podprocesov znotraj glavnega ţivljenjskega cikla ali za podporo več ţivljenjskih ciklov.

Kompozitne diagrame stanj smo uporabili v našem ogrodju, v katerem imajo funkcijo

nuditi podporo več ţivljenjskih ciklov. Iz slike 5.3 je razvidno, da smo v definirano

ogrodje vključili dva ţivljenjska cikla, to sta »ZivljenskiCikelKoncneTocke« In

»ZivljenskiCikelStoritve«. Oba izmed njuji sta realizirana s pomočjo kompozitnega

diagrama stanj.

1 Problem le enega ţivljenjskega cikla izhaja prav iz SACL datoteke, saj WSRR ne podpira več SACL

datotek hkrati.


Slika 5.3 Ogrodje (diagram stanj) za podporo več ţivljenjskih ciklov na WSRR

Namen ogrodja je bil preseči omejitve WSRR pri podpori le enega ţivljenjskega cikla.

Vidimo lahko, da je sedaj podpora dodatnim ţivljenjskim ciklom omogočeno s pomočjo

dodajanja dodatnih kompozitnih diagramov stanj v definirano ogrodje na način, kot je

prikazan na sliki 5.4.

Slika 5.4 Dodajanje ţivljenjskih ciklov na ogrodje

Pri definiranju lastnega ţivljenjskega cikla smo izhajali iz IBM-ovega SOA ţivljenjskega

cikla ter pred-nameščenega ţivljenjskega cikla. Raziskali smo probleme iz prakse pri

izvajanju ţivljenjskih ciklov, kot so bili identificirani s strani priznanih avtorjev, ter prakso


organizacij. Poiskali smo identificirano dobro prakso ter jo prenesli v naš ţivljenjski cikel

ter pri tem dodali tudi lastne izkušnje.

Definirali smo nov ţivljenjski cikel, kot ga predstavlja slika 5.5. Zasnovan je kot

kompozitni diagram stanj, tako da ga je mogoče vključiti v ogrodje. Ne pozabimo, da je

ţivljenjski cikel storitve lahko tudi ţivljenjski cikel procesa.

Slika 5.5 Kompozitni diagram stanj ţivljenjskega cikla storitve

Ker smo izhajali iz IBM-ovega SOA ţivljenjskega cikla, prikazanega na sliki 5.2, lahko

stanja zdruţimo v skupine, ki predstavljajo faze tega cikla. Na sliki 5.5 smo tako označili

tudi skupine stanj, ki predstavljajo vsako izmed štirih faz iz IBM-ovega ţivljenjskega cikla.

Za laţje razumevanje je smiselno sedaj zapisati za vsako fazo vse prehode in stanja ter

njihove opise.


V tabeli 5-1 so zbrani podatki za prvo fazo, modeliranje. Prehodov, ki premaknejo storitev

nazaj v prejšnje stanje, ne bomo opisovali v tabeli, predstavljeni so na sliki 5.6.

Tabela 5-1 Prehodi in stanja ter opisi za fazo modeliranja

Prehod Stanje Opis

Identificirano Nova verzija storitve ali procesa oz. zmoţnosti je

zahtevana ali identificirana.

Predlagaj

obseg

Pregled obsega Vpleteni pregledajo zahteve in predlaganega lastnika

verzije ter obseg.

Odobri

obseg

Obseg sprejet Razvoj in lastniki definirajo stroške in časovni okvir

izvedbe dela.

Predlagaj

načrt

Pregled načrta Vsi vpleteni v razvoj in uporabo zmoţnosti imajo

priloţnost pregledati načrt implementacije ter podati

svoje mnenje.

Odobri načrt Načrt sprejet Začne se razvoj prve verzije. Določi se specifikacija,

kar zajema vmesnike, ki jih bo nudila, storitve, ki jih

bo uporabljala, zmogljivosti, ki jim bo morala

zadostiti in ostalo.

Predlagaj

specifikacijo

Pregled

specifikacije

Pregled specifikacije mora zagotoviti, da bo

specifikacija prinesla to, kar vpleteni zahtevajo.

Potrditev omogoči uporabnikom in razvijalcem

začetek dela.


Slika 5.6 Diagram prehodov in stanj za fazo modeliranja

V tabeli 5-2 so zbrani podatki za fazo sestavljanja. Prehodov, ki premaknejo storitev nazaj

v prejšnje stanje, ne bomo opisovali v tabeli, predstavljeni so na sliki 5.7.

Tabela 5-2 Prehodi in stanja ter opisi za fazo sestavljanja

Prehod Stanje Opis

Odobri

specifikacijo

Specificirano Na tej točki se večina razvoja in sestave zmoţnosti

začne. Večina razvoja je specifična in tukaj ni vodena.

Ob primernem stanju se predlaga verzija za pregled.

Predlagaj

verzijo

Pregled verzije Vpleteni pregledajo, če predlagana verzija zadostuje

kriterijem testiranja in je nivo kakovosti primeren za

začetek priprav namestitve in konfiguracije v staging

okolje.

Odobri

verzijo

Potrjena verzija Potrjena verzija je nameščena v staging okolje in

skonfigurirana tako, da lahko sodeluje z ostalimi

nameščenimi procesi in storitvami.


Slika 5.7 Diagram prehodov in stanj za fazo sestavljanja

V tabeli 5-3 so zbrani podatki za fazo namestitve. Prehodov, ki premaknejo storitev nazaj v

prejšnje stanje, ne bomo opisovali v tabeli, predstavljeni so na sliki 5.8.

Tabela 5-3 Prehodi in stanja ter opisi za fazo namestitve

Prehod Stanje Opis

Predlagaj staging1

namestitev

Pregled staging

namestitve

Identificira se, kdaj bo uporabnikom omogočen

dostop do nameščene zmoţnosti v staging

okolju.

Odobri staging

namestitev

Staged Verzija je testirana v staging okolju z namenom

prepričati se, da je zahtevam zadovoljeno in da

jo bo mogoče izvajati v produkcijskem okolju.

1 Staging okolje je tisto, ki je v največji moţni meri enako produkcijskemu okolju. Namen staging okolja je

simulirati kar se da največ elementov produkcijskega okolja.


Prehod Stanje Opis

Predlagaj

certifikacijo

Certifikacijski

pregled

Testiranje je končano in dano je dovoljenje, da

se lahko verzija namesti v produkcijsko okolje.

Odobri certifikacijo Certificirano Certificirana verzija je nameščena v produkcijo

okolje in testirana.

Predlagaj

produkcijsko

namestitev

Pregled

izvajanja

Končni pregled izvajanja v produkcijskem

okolju je izveden in podano je dovoljenje za

predajo verzije v uporabo.

Odobri produkcijsko

namestitev

Izvajajoče Verzija je nameščena v produkcijsko okolje in

predana uporabi.

Slika 5.8 Diagram prehodov in stanj za fazo namestitve


V tabeli 5-4 so zbrani podatki za fazo namestitve. Prehodov, ki premaknejo storitev nazaj v

prejšnje stanje, ne bomo opisovali v tabeli, predstavljeni so na sliki 5.9.

Tabela 5-4 Prehodi in stanja ter opisi za fazo upravljanja

Prehod Stanje Opis

Zastaraj Zastarano Zmoţnosti ni več potrebna, nova verzija ne bo več razvita,

trenutna pa se še lahko uporablja.

Upokoji Upokojeno Zmoţnost se umakne tako, da ni več dosegljiva, nobena verzija

zmoţnosti ni več v uporabi.

Slika 5.9 Diagram prehodov in stanj za fazo upravljanja

Za prikaz moţnosti razširjanja ogrodja z dodatnimi ţivljenjskimi cikli smo definirali

dodaten ţivljenjski cikel, končne točke, katere cikel je prikazan na sliki 5.9. Ţivljenjski

cikel končne točke je uporaben za vodenje končne točke od odobritve do upokojitve.

Slika 5.10 Kompozitni diagram stanj ţivljenjskega cikla končne točke


V tabeli 5-5 so zbrani podatki za ţivljenjski cikel končne točke. Prehodov, ki premaknejo

končno točko nazaj v prejšnje stanje, ne bomo opisovali v tabeli, predstavljeni so na sliki

5.10.

Tabela 5-5 Prehodi in stanja ter opisi za ţivljenjski cikel končne točke

Prehod Stanje Opis

Ni na voljo Končna točka je nameščena, a dostop onemogoča

mediacija.

Odobri uporabo Na voljo Mediacija upošteva končno točko za uporabo.

Upokoji Upokojeno Končna točka je bila odstranjena iz okolja.

Pripravljeno SACL datoteko, ki vsebuje ogrodje z dvema novima ţivljenjskima cikloma, je

potrebno namestiti na WSRR. Celoten razvoj, namestitev in uporaba novega ţivljenjskega

cikla z orodjem IBM WebSphere Integration Developer se izvedejo v štirih korakih:

1. Definiraj nov ţivljenjski cikel:

a. ustvari nov diagram stanj,

b. ustvari vmesnik,

c. definiraj stanja,

d. dodaj korelacijske lastnosti,

e. izvozi SACL.

2. Odstrani privzet ţivljenjski cikel in popravi elemente, ki se sklicujejo nanj:

a. odstrani taksonomijo1 ţivljenjskega cikla.

b. popravi WSRR Web UI poglede, ki uporabljajo stanja ţivljenjskega cikla,

1 Taksonomija je klasifikacija stvari. Navadno so taksonomije hierarhične in dajo ime vsemu, kar imamo v

izbrani domeni, ter pokaţejo, kako so stvari med seboj odvisne.


c. popravi avtorizacijske politike, ki se nanašajo na ţivljenjski cikel,

d. popravi konfiguracijo odkrivanja storitev, če vsebuje reference na prehode,

3. Namesti nov ţivljenjski cikel:

a. s pomočjo WSRR Web UI pogleda,

b. s pomočjo skripte,

Primer zagona skripte:

<wsrr_home>\admin\scripts_cell <was_home>/bin/wsadmin -cell

Cell -node Node -server Server -f

updateLifecycleDefinition.jacl -filepath c:\ibm -sacl_filename

FERILifeCycles.sacl -owl_filename FERILifeCycles.owl

c. z več ročnimi koraki.

4. Uporabi ţivljenjski cikel.

Odstranili smo privzet ţivljenjski cikel, tako da smo odstranili njegove klasifikacije, nato

smo s pomočjo skripte iz koraka 3 b naloţili nov ţivljenjski cikel. Uporaba ţivljenjskega

cikla je sedaj mogoča, novi dokumenti imajo na voljo izbiro, pod katerim ţivljenjskim

ciklom iz ogrodja se bodo vodili, kar je prikazano na sliki 5.11.

Slika 5.11 Ogrodje z novima ţivljenjskima cikloma v uporabi

Ţivljenjski cikel je sedaj lahko predan uporabi, pred tem pa je na ţivljenjski cikel smiselno

dodati politike, kot so bile definirane z načrtom vodenja in jih je moţno avtomatizirati na


WSRR. To smo storili v naslednjem poglavju z implementacijo dveh vtičnikov, ki bosta

imela vlogo uveljavljanja politik.

5.3 Validacija in notifikacija dejavnosti in dogodkov

WSRR nudi programske vmesnike, ki omogočajo implementacijo lastne kode, ki se lahko

izvede v času standardnega procesiranja WSRR. Razredi, ki implementirajo te vmesnike,

so imenujejo WSRR vtičniki. Vtičniki omogočajo implementacijo lastne kode, ki

uveljavlja politike vodenja, kot so bile opredeljene z načrtom SOA vodenja.

Trenutno WSRR podpira naslednje tipe vtičnikov:

validatorji, ki so izvedeni pred nekaterimi operacijami registra,

notifikatorji se izvedejo potem, ko se je določena operacija izvedla,

modifikatorji so klicani potem, ko se spremembe zapišejo v bazo, a se transakcija

še ne zaključi, in omogočajo naknadno spreminjanje podatkov,

WSDL razširitveni razpoznavalniki se izvedejo v času procesiranja WSDL.

Diagram na sliki 5.12 predstavlja zaporedje klica vtičnikov, ki se izvedejo ob katerikoli

akciji odjemalca. Celotno zaporedje se izvede kot transakcija.

Slika 5.12 Zaporedje izvajanja WSRR vtičnikov ob akciji odjemalca


Implementacija vtičnika se izvede v dveh korakih:

1. Razvoj razreda vtičnika.

2. Namestitev vtičnika:

a. zapakiranje v jar in namestitev na WSRR,

b. nastavitev WSRR za uporabo novega vtičnika.

Za predstavitev uveljavljanja politike na WSRR smo razvili vtičnik za validacijo

imenskega prostora in vtičnik za notifikacijo dogodkov.

5.4 Razvoj vtičnika za validacijo

Za prikaz zmoţnosti WSRR smo se odločili implementirati validator, ki bo v skladu s

politiko vodenja preveril ustreznost poimenovanja imenskega prostora1 dokumenta.

Njegova funkcionalnost bo zajemala preverjanje dokumentov kateri bodo postali vodeni ter

tistih, ki bodo izvedli prehod lastnega ţivljenjskega cikla. Dodatno pa tudi za tiste, ki bodo

izstopili iz ţivljenjskega cikla oz. ne bodo več vodeni. To je preprost primer, ki kaţe

konceptualen pristop k implementaciji lastnih, po meri razvitih mehanizmov vodenja.

Prvi korak je razvoj razreda vtičnika, ki bo implementiral enega izmed validacijskih

vmesnikov. Na voljo imamo:

com.ibm.serviceregistry.ServiceRegistryValidator,

com.ibm.serviceregistry.governance.ServiceRegistryGovernanceValidator,

com.ibm.serviceregistry.governance.ServiceRegistryGovernanceValidator2.

Med njimi sta dve pomembni razliki. Prvo prikazuje slika 5.13, iz katere je razvidno, da

drugi in tretji vmesnik, ki sta namenjena vodenju, vsebujeta dodatne operacije, uporabne

pri vodenih dokumentih.

1 Imenski prostor se uporablja za zagotavljanje unikatnosti imen elementov in atributov, uporabljenih v XML

dokumentih.


Druga razlika je v načinu procesiranja validacijskega vtičnika, saj se vtičnika, namenjena

vodenju, izvedeta le na vrhnjem dokumentu, nad katerim je bila storjena akcija, nad

odvisnimi dokumenti pa se izvede le operacija posodobitve (update).

Slika 5.13 Razredni diagram WSRR vmesnikov za validacijo

Namen validatorja je preverjanje imenskega prostora dokumenta ob prehodu v stanje

vodenj. V ta namen moramo uporabiti vmesnik »ServiceRegistryGovernanceValidator2«,

ki vsebuje operacijo »makeGovernable«. Izvorna koda 1 predstavlja le del kode vtičnika,

ki preverja ustreznost imenskega prostora dokumenta, v primeru njegove neustreznosti pa

nastavi status napake in posledično dokument ne postane voden.

Izvorna koda 1 WSRR vtičnik validator

…

public class NameSpaceValidator implements ServiceRegistryGovernanceValidator2

{

public ServiceRegistryStatus makeGovernable(OriginalObject arg0, String

arg1) {

ServiceRegistryStatus status = new ServiceRegistryStatus();

if (!arg0.getNamespace().startsWith("http://feri.uni-mb.si/")) {

status.addDiagnostic(ServiceRegistryStatus.ERROR,

"Imenski prostor dokumenta neveljaven.");

}

return status;

}

…


Preden lahko nov vtičnik namestimo na WSRR, ga je potrebno zapakirati v jar ter nato

prenesti na WSRR. Naslednji korak je potem le še sprememba nastavitev, ki opredeljujejo,

kateri validatorji se izvajajo v času procesiranja WSRR, da bo vseboval tudi nov vtičnik.

Nastavitve je mogoče spremeniti preko vmesnika WSRR WEB UI, kot to prikazuje slika

5.14, na kateri je razvidno tudi, da smo dodali naš validator

»GovernanceNameSpaceValidator« med nabor ţe izbranih.

Slika 5.14 Nastavitev novega vtičnika na WSRR

Da bi predstavili še delovanje novega validatorja, smo ustvarili XML1 (Extensible Markup

Language) shemo oziroma XSD2 (XML Schema Definition) datoteko Diploma z

neveljavnim imenskim prostorom. Izvorna koda 2 predstavlja celotno vsebino definirane

XSD datoteke. Naša politika vodenja zahteva, da se imenski prostori vseh dokumentov

začnejo s »http://feri.uni.mb.si/«, kar je vidno tudi v izvorni kodi 1 medtem, ko lahko iz

izvorne kode 2 razberemo, da shema diploma vsebuje neveljaven imenski prostor

»http://www.niprostora.com«. Preden lahko prikaţemo delovanje vtičnika, je potrebno

definirano shemo Diploma shraniti na WSRR.

1 XML predstavlja razširljiv označevalni jezik, ki je preprost, zelo prilagodljiv tekstovni format. XML igra

vedno bolj pomembno vlogo pri izmenjavi najrazličnejših podatkov na spletu in drugje.

2 XSD predstavljata sredstvo za opredelitev strukture, vsebine in semantike XML dokumentov.


Izvorna koda 2 XML shema Diploma

Če poskusimo ta dokument prenesti pod vodenje, novi validator opravi svoje delo, pojavi

se napaka pri izvedbi akcije (slika 5.15) in dokument ne postane voden.

Slika 5.15 Napaka validacijskega vtičnika v primeru neustreznega imenskega prostora

5.5 Razvoj notifikatorja

Namen notifikatorja je zabeleţiti dogodke ob spremembi stanja katerega izmed vodenih

dokumentov ter ob spremembi dokumenta v vodenega in nazaj v ne-vodenega. Kakor

validator mora tudi notifikator implementirati enega izmed predvidenih vmesnikov, tokrat

za notifikacijo na sliki 5.16. Ker bo vtičnik vodil dnevnik sprememb tudi za dokumente, ki

bodo postali vodeni, in za dokumente, ki bodo prešli iz vodenja, moramo uporabiti

</xsd:schema targetNamespace="http://www.niprostora.com/DiplomaArtefakti" >

<xsd:complexType name="Diploma" >

<xsd:sequence>

<xsd:element minOccurs="0" name="Tema" type="xsd:string" />

<xsd:element minOccurs="0" name="Datum" type="xsd:date" />

<xsd:element minOccurs="0" name="Ocena" type="xsd:int" />

<xsd:element minOccurs="0" name="Avtor" type="xsd:string" />

<xsd:element minOccurs="0" name="Mentor" type="xsd:string" >

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:schema>


vmesnik »ServiceRegistryGovernanceNotifier2«, in ne

»ServiceRegistryGovernanceNotifier«, saj slednji ne podpira operacij, namenjenih

prehodom v stanje voden (makeGovernable) in nazaj (removeGovernance).

Slika 5.16 Razredni diagram WSRR vmesnikov za notifikacijo

Izvorna koda 3 prikazuje le del celotne kode, ki implementira razred vtičnika notifikatorja.

Prikazan je del, ki prikazuje implementacijo operacije »transition«, ki izvede zapis na

sistemski izhod oziroma dnevnik dogodkov aplikacijskega streţnika.

Izvorna koda 3 WSRR vtičnik notifikator

…

public class GovernanceTransitionLog implements

ServiceRegistryGovernanceNotifier2 {

public void transition(String initialTransition, OriginalObject

oldObject, OriginalObject newObject, boolean success,

ServiceRegistryException ex) {

// prehod uspešen

if (success) {

System.out.println(oldObject.getName()

+ " je opravil tranzicijo iz " + initialTransition + " uspesno");

}

// prehod neuspel, v log zapišemo sporočilo izjeme in ime artefakta

else {

System.out.println("Napaka pri izvedbi prehoda "

+ oldObject.getName() + ". Sporocilo izjeme: " + ex.getMessage());

}

}

…


Operacija »transition« se bo izvedla ob prehodu artefakta med stanji njegovega

ţivljenjskega cikla. Dodatno smo implementirali še dve operaciji, ki na tem mestu nista

vidni in sta namenjeni prehodom v stanje voden in nazaj.

Kot je veljalo za validator, je potrebno tudi notifikator zapakirati v jar, prenesti na WSRR

ter ustrezno dopolniti nastavitve. Ko je vse to urejeno, se vtičnik izvede ob standardnem

procesiranju WSRR, kar pomeni, da se za vsak dokument, ki postane voden, v streţniški

dnevnik zapiše ustrezen dogodek. Podobno se zapišeta v dnevnik tudi dogodka ob akciji

prehoda artefakta iz enega v drugo stanje in ob odvzemu artefakta iz njegovega

ţivljenjskega cikla.

Za prikaz delovanja smo WSDL dokument »ArhivirajDiplomo.wsdl« označili kot voden.

Pri tem je razviti vtičnik v dnevnik dogodkov na aplikacijskem streţniku zapisal dogodek o

izvedeni akciji, kar prikazuje slika 5.17. Na tem mestu bodo vidni tudi dogodki za ostali

dve akciji za kateri se ob standardnem procesiranju WSRR izvede razvit vtičnik t.i.

notifikator.

Slika 5.17 Zapis notifikatorja o izvedeni akciji v dnevniku aplikacijskega streţnika


5.6 Omejevanje dostopa

WebSphere Service Registry in Repository uporablja za nadzor dostopa varnostne

mehanizme WebSphere Application Server, da zagotovi dostop samo avtoriziranim

uporabnikom. Samo upravljanje nadzora dostopa do WSRR je za SOA vodenje premalo

natančno. Potrebna je niţja raven nastavitev dostopa, kar pomeni tudi nastavitev dovoljenj

izvajanja specifičnih akcij nad izbranimi dokumenti. Ker WSRR omogoča nastavitev

natančnejšega nadzora dostopa do posameznih informacij in akcij, pa varnostne

mehanizme WebSphere Application Server tudi razširja.

Dovoljenje v WSRR enkapsulira akcijo in ciljni artefakt, na katerem naj bo akcija

izvedena. Dodajanje dovoljenja vlogi omogoči uporabniku te vloge izvedbo akcije na

ciljnem artefaktu (31). Slika 5.18 prikazuje primer enega izmed dovoljenj vloge z imenom

WSRRAdmin nad akcijo srrUpdate za vse WSDL dokumente v WSRR.

Slika 5.18 Vloga in dovoljenja v WSRR

V WSRR imamo na voljo akcije iz tabele 5-6. Ciljni artefakt določimo s poizvedovalnim

jezikom WSRR, ki temelji na podmnoţici XPath 2.0. Zaradi specifičnosti dovoljenj pa ima

dodano podporo Service Data Object (SDO), relacijami in nekaterimi dodatnimi

funkcionalnostmi za poizvedovanje po klasifikacijah (31).


Tabela 5-6 Veljavne akcije za WSRR dovoljenja (31)

Ime Opis

srrCreate Dovoljenje za kreacijo ciljnega artefakta v WSRR.

srrRetrive Dovoljenje za pridobitev ciljnega artefakta iz WSRR.

srrUpdate Dovoljenje za posodobitev ciljnega artefakta v WSRR.

srrDelete Dovoljenje za izbris ciljnega artefakta iz WSRR.

srrTransition Dovoljenje za prehod ciljnega artefakta znotraj ţivljenjskega cikla na

WSRR.

srrManageGov Dovoljenje za spremembo ciljnega artefakta v vodenega ali za

odstranitev iz vodenja na WSRR.

Bogat nabor moţnosti izbire ciljnega artefakta nam daje moţnost določitev dovoljenja za

ciljni artefakt v posameznem stanju ţivljenjskega cikla. Ta funkcionalnost izredno poveča

WSRR-jeve zmoţnosti vodenja, saj je na tem mestu mogoče definirati del pravic odločanja

SOA vodenja.

Za celovito in efektivno definiranje pravic odločanja moramo imeti v WSRR vse vloge in

uporabnike, ki delujejo v SOA okolju organizacije. Ker nimamo vlog in uporabnikov ali

imenika, iz katerega bi jih lahko pridobili, WSRR pa omogoča med drugim tudi povezavo

na LDAP (Lightweight Directory Access Protocol), bomo prikazali primer na dveh

privzetih vlogah WSRRAdmin z uporabnikom admin in WSRRUser z uporabnikom matej.

Primer dovoljenja na sliki 5.19 dovoljuje vlogi WSRRadmin prehode med stanji artefakta,

saj deluje nad akcijo srrTransition. Dovoljenje velja za vse dokumente, ki se nahajajo v

enem izmed stanj ţivljenjskega cikla, ki je bil definiran v prejšnjem poglavju.


Slika 5.19 Primer dovoljenja za prehod na WSRR

Ker upravljanje z dovoljenji ni na voljo z uporabo grafičnega vmesnika, je to potrebno

storiti s posebnim ukazom v komandni konzoli.

Primer ukaza za dovoljenje na sliki 5.19:

<wsrr_home>\admin\scripts_cell wsadmin -cell Cell -node Node -server Server

-f addPermissionToRole.jacl -role WSRRAdmin -action srrTransition

-permission_name VodenPrehodDovoljenje -permission_target

/WSRR/BaseObject[classifiedByAnyOf('http://feri.uni-

mb.si/xmlns/lifecycle/LifeCycle#State')]

Če ţeli uporabnik, ki nima vloge WSRRAdmin, izvesti nad ciljnim artefaktom prehod na

naslednje stanje ţivljenjskega cikla, mu je to onemogočeno. WSRR vrne napako

dovoljenja, kot je to na sliki 5.20 prejel uporabnik matej, ki ima vlogo WSRRUser.

Slika 5.20 Primer napake zaradi nezadostnih pravic na WSRR


Za prikaz zelo fine nastavitve dovoljenj, ki jih lahko doseţemo, smo na sliki 5.21 prikazali

še en primer dovoljenja, ki daje vlogi WSRRUser dovoljenje za pridobitev vodenega

artefakta, če je le-ta v stanju »Izvajajoce« ţivljenjskega cikla.

Slika 5.21 Primer dovoljenja za pridobitev vodenega artefakta na WSRR

Pri definiranju cilja moramo biti pozorni, saj je potrebno uporabiti ID razreda klasifikacije,

v tem primeru »http://feri.uni-mb.si/xmlns/lifecycle/LifeCycle#State14«, in ne imena

klasifikacije, kar bi bilo v tem primeru »Izvajajoce«. Kot rečeno, stanja in prehodi

ţivljenjskega cikla se ob prenosu SACL datoteke na WSRR pretvorijo v taksonomijo

klasifikacij. ID razreda klasifikacije ţelenega stanja ali prehoda lahko pridobimo iz

WSRR-ja, kot kaţe slika 5.22.

Slika 5.22 Pridobitev ID-ja razreda klasifikacije za ţeleno stanje ali prehod


Tudi to dovoljenje je potrebno izvesti s pomočjo skripte. Za prikaz uporabe skripte za

dodajanje dovoljenj vlogi smo podali še en primer.

Primer ukaza za dovoljenje na sliki 5.21:

<wsrr_home>\admin\scripts_cell wsadmin -cell Cell -node Node -server Server -

f addPermissionToRole.jacl -role WSRRUser -action srrRetrieve -

permission_name VodenPridobiDovoljenje -permission_target

/WSRR/BaseObject[classifiedByAnyOf('http://feri.uni-

mb.si/xmlns/lifecycle/LifeCycle#State14')]

5.7 Analiza vpliva

Večina artefaktov, shranjenih v registru in repozitoriju, je povezanih med seboj oziroma

niso izolirani. Zaradi njihove medsebojne odvisnosti lahko spremembe enega artefakta

vplivajo na delovanje odvisnih artefaktov. Pri sprejemanju odločitev, ki bodo povzročile

spremembo artefakta, je nujno imeti popolno sliko vpliva, ki ga bo sprememba imela na

širše SOA okolje. V ta namen je potrebno izvesti analizo vpliva, to funkcionalnost ponuja

tudi WSRR. Imenuje se orodje analize vpliva (Impact Analysis), ki rekurzivno prehodi vse

relacije iz izbranega artefakta, za katerega izvajamo analizo, ter gradi listo vseh dosegljivih

artefaktov. Ta list je ob zaključku izvajanja vrnjen kot rezultat analize vpliva. Predstavlja

zbirko artefaktov v WSRR, na katere bi lahko vplivala morebitna sprememba izbranega

artefakta.

V WSRR smo shranili shemo »Diploma«. Ker ţelimo izvesti spremembe, nas zanima,

kateri artefakti so odvisno povezani s to shemo. Pripravili smo analizo vpliva na sliki 5.23,

kjer je razvidno, da smo izbrali moţnost, ki določa izvajanje analize za artefakte, ki so

odvisni od izbranega, ter tudi, da se omejujemo na artefakte vrste WSDL ali XSD, ki

uporabljajo in imajo zato uvoţeno shemo »Diploma«. Rezultati bodo vrnjeni v tem

primeru v tabelarični obliki.


Slika 5.23 Priprava analize vpliva

Rezultate, ki jih vrne analize vpliva, prikazuje slika 5.24. Vidimo lahko, da je shema

Diploma uporabljena v dveh storitvah in zatorej lahko sprememba sheme povzroči

potencialno nedelovanje teh dveh storitev. To je pomembna informacija in jo je potrebno

imeti v mislih pri sprejemanju odločitev, ki lahko imajo zaradi narave arhitekture globlje

posledice v SOA okolju.

Slika 5.24 Rezultat analize vpliva

Verjetno še bolj kot za katero koli drugo vrsto tradicionalnih IT arhitektur velja za SOA

rešitve, da so tesno integrirane in šibko sklopljene. To povzroči, da sprememba


posameznih storitev ali komponent lahko pusti svoj vpliv globoko v SOA okolju, kar

pomeni, da je ključnega pomena za organizacije, da imajo na voljo način za analiziranje

vpliva sprememb (ali morebitne spremembe) in razumevanje, kako bodo spremembe

posameznih storitev vplivale na ostalo okolje. To je mesto, kjer analiza vpliva in sledljivost

prideta v poštev (20).

Do sedaj smo praktično prikazali pet načinov, kako lahko z orodji, ki podpirajo SOA

vodenje, olajšamo dosego skladnosti z načrtom vodenja. WSRR se je izkazal za odlično in

zelo prilagodljivo orodje pri podpori SOA vodenju, kar nam je omogočilo, da smo lahko ne

le definirali lasten celovit ţivljenjski cikel storitve, ampak tudi ogrodje, ki omogoča preseči

določene omejitve WSRR-ja. Identificirali smo stanja ţivljenjskega cikla storitve in

prehode med njimi, jih opisali ter dodali grafično predstavitev v obliki diagramov stanj.

Vse skupaj smo namestili na WSRR, kar nam je omogočilo, da smo lahko na definiran

ţivljenjski cikel kasneje dodali tudi politike vodenja. Podali smo korake za razvoj in

konceptualno idejo, ki dajeta organizacijam osnovo za razvoj lastnega ogrodja in

poljubnega ţivljenjskega cikla. Dodatno smo izrabili zmoţnost WSRR-ja, ki omogoča

obogatitev ţivljenjskega cikla s politikami, kar smo naredili z razvojem dveh t. i. WSRR

vtičnikov. Predstavili smo nabor vtičnikov, ki jih ponuja WSRR, in korake, potrebne za

njihovo implementacijo. Razvili smo dva javanska razreda, ki implementirata ustrezen

Java vmesnik za realizacijo vtičnika. Oba razreda smo razvili tako, da delujeta nad ţe prej

definiranim lastnim ţivljenjskim ciklom storitve. Vtičnika smo v ustrezni obliki namestili

na WSRR ter demonstrirali njuno delovanje. V nadaljevanju smo prikazali še, kako je

mogoče uveljaviti pravice odločanja z WSRR. Predstavili smo dovoljenje, kot ga pozna

WSRR, ter pripravili dva izmed teh kot vzorčni prikaz podelitve pravic določeni vlogi za

izvedbo akcije prehoda med ciljnimi stanji definiranega ţivljenjskega cikla storitve. Nismo

pa pozabili niti na analizo vpliva; pokazali smo, kako lahko le-ta v WSRR nudi dodatne

informacije, ki so koristne pri kvalitetnem sprejemanju odločitev vodenja. Na praktičnem

primeru smo predstavili, kako lahko manjša sprememba le ene XML sheme povzroči

teţave v širšem SOA okolju, v našem primeru potencialno nedelovanje dveh storitev. Vse

to smo naredili z namenom dati vpogled, kolikšen del SOA vodenja je mogoče podpreti z

ustreznimi orodji in kakšen je postopek ter ideja za dosego tega.


6 SKLEP

Kljub vsem aktivnostim, ki trenutno potekajo v zvezi s SOA, še vedno ostaja veliko zmede

okoli tega, kaj točno pomeni storitveno usmerjena arhitektura. V podjetniškem okolju

zmeda vsekakor ni zaţelena. Zgodovina prakse nas uči, da je zmedo teoretično lahko

upravljati z vodenjem, ki se kaţe kot nepogrešljivo na vseh ravneh. Ker organizacije vidijo

rešitev nekaterih problemov poslovanja, predvsem agilnosti pri odzivih na spremembe trga,

v SOA, postaja le-ta vse bolj razširjeno posvojena. Vodenje novega pristopa gradnje

informacijskih sistemov je tako evolucijsko smiseln naslednji korak za zagotovitev

učinkovitost SOA, ki bo prinesla ţelene poslovne rezultate brez dodatne zmede.

Večina organizacij, ki danes uvajajo SOA v svoja informacijska okolja, verjame, da bi bila

brez vodenja njihova prizadevanja obsojena na propad, kakor je bilo pomanjkanje vodenja

ţe velikokrat pogubno (1), (2). To podpirajo ob prepričanju organizacij tudi praksa,

priznani avtorji (14), (23), analitična podjetja (24), (17) in ponudniki rešitev (6), (19), (21).

Dojemanje novega načina dela in tvorba kompetenčnega sistema znanj, ki bo napajal

vpletene pri izvajanju SOA, je lahko začetek popotovanja proti SOA in prvi korak pri

vzpostavitvi SOA vodenja. Nova disciplina vodenja nalaga organizacijam dodatne izzive.

Ţelja je, doseči kar se da optimalno razmerje med vloţenimi viri in rezultati, izboljšanje

tega razmerja pri SOA vodenju pa je mogoče doseči z uporabo ţe uveljavljenih pristopov.

Na trgu je mnogo ogrodij SOA vodenja, ki nudijo določeno šablono, po kateri lahko

organizacije vzpostavijo lastno SOA vodenje. Ponudniki ogrodij so različni, od vodilnih na

IT trgu (6) (19) do standardizacijskih teles (18). Ta ogrodja so zelo koristna kljub eni

pomanjkljivosti, ki pesti organizacije pri vpeljavi SOA vodenja: to je, katere zmogljivosti

vodenja morajo izvajati in katero strategijo za sprejetje teh zmogljivosti morajo uporabiti.

Delen odgovor nudi tehnika SEI, ki temelji na scenarijih, da bi implementirala SOA

vodenje. Tudi The Open Group v svojem ogrodju predstavlja metodo vitalnosti, katere

namen je prav pomoč pri prilagoditvi in vpeljavi SOA ogrodja v organizacijo.


Izdelava načrta vodenja je lahko ničvredna, če ni zagotovljene skladnosti s sprejetimi

politikami vodenja. Če je SOA vodenje organizacije dovolj zrelo, lahko za uveljavljanje

skladnosti dela svojih politik uporabi orodje. Register in repozitorij kot centralno skladišče

SOA dokumentov je dobro mesto za uporabo orodja za zagotavljanje skladnosti. IBM

WebSphere Registry and Repository se je izkazal kot odlično orodje, ki ponuja širok nabor

moţnosti avtomatizacije politik, od lastnih ţivljenjskih ciklov do po meri narejenih

validatorjev.

Hitro razvijajoč se koncept SOA nudi veliko moţnosti za nadaljnje raziskave, ki se kaţejo

na več področjih. Definiranje lastnega ogrodja SOA vodenja z izpeljavo obstoječih bi bilo

eno izmed teh. Pri tem bi se bilo smiselno osredotočiti na manjše organizacije, ki nimajo

mnogo virov in izredno kompleksnih informacijskih sistemov. V to kategorijo spada

večina organizacij v Sloveniji in bi s takšnim ogrodjem SOA vodenja pripomogli k

uspešnejšim SOA posvojitvam v slovenskem prostoru.

Koristno bi se bilo lotiti tudi področja tehnoloških rešitev v podpori SOA vodenju. Z

dozorevanjem SOA okolja in vodenja je smiselno uporabiti tudi orodja, ki lajšajo vodenje

takšnega okolja. Kompleksnejša vzorčna implementacija SOA vodenja s pomočjo orodja

bi bila vsekakor koristna vsaki organizaciji, ki je na ustrezni stopnji zrelosti.

Nadaljnje delo v okviru SOA pristopa je izredno perspektivno zaradi koristi, ki jih prinaša

tako poslovanju organizacije kot njenemu IT-ju. Potrebe po znanjih s tega področja se

bodo še vnaprej večale, medtem ko strokovnjakov ţe sedaj primanjkuje. Po Gartnerjevih

napovedih bo do leta 2010 manj kot 25 % organizacij imelo zadovoljive tehnične in

organizacijske sposobnosti, potrebne za dostavo celovite SOA (17). To dejstvo ob

kombinaciji vedno večjega števila SOA implementacij (20) bi moralo dati zagon

obstoječim in novim strokovnjakom, da usmerijo svoja prizadevanja v področje SOA.


7 VIRI

1. Johnson, Simon, in drugi. Corporate governance in the Asian financial crisis. Journal

of Financial Economics. 2000, Izv. 1-2.

2. Kirkpatrick, Grant. The Corporate Governance: Lessons from the Financial Crisis.

s.l. : OECD Steering Group, 2009. 1995-2864.

3. Heraclitus. Wikiquote. [Elektronski] 2. junij 3009. [Navedeno: 4. junij 2009.]

http://en.wikiquote.org/wiki/Heraclitus.

4. Moore, Gordon. Progress in digital integrated electronics. Electron Devices Meeting.

1975, Zv. 21.

5. Moore's Law. Wikipedia. [Elektronski] 1. julij 2009. [Navedeno: 4. julij 2009.]

http://en.wikipedia.org/wiki/Moore's_law.

6. Oracle. Right from the Start: SOA Lifecycle Governance. Oracle Corporation.

[Elektronski] junij 2008. [Navedeno: 4. julij 2009.]

http://www.oracle.com/technology/tech/soa/uddi/pdf/soa-gov-rightstart-whitepaper.pdf.

7. Mueller, Lynn, in drugi. IBM IT Governance Approach: Business Performance

through IT Execution. s.l. : IBM Corporation, 2008.

8. Process. Dictionary.com. [Elektronski] Ask.com. [Navedeno: 14. junij 2009.]

http://dictionary.reference.com/browse/process.

9. Slovar slovenskega knjiţnega jezika. Slovarske in besedilne zbirke. [Elektronski] Inštitut

za slovenski jezik Frana Ramovša ZRC SAZU. [Navedeno: 14. julij 2009.] http://bos.zrc-

sazu.si/cgi/a03.exe?name=sskj_testa&expression=proces&hs=1.


10. Independent Evaluation Group. Sourcebook for Evaluating Global and Regional

Partnership: Indicative Principles and Standards. Washington : IEG-World Bank, 2007.

1-60244-001-8.

11. Information technology governance. Wikipedia. [Elektronski] 24. junij 2009.

[Navedeno: 15. julij 2009.]

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

12. SOA Reference Architecture. The Open Group. [Elektronski] Draft 10, 5. junij 2009.

[Navedeno: 22. julij 2009.]

http://www.opengroup.org/projects/soa/doc.tpl?CALLER=documents.tpl&dcat=28&gdid=

19714.

13. High, Rob, Kinder, Stephen in Graham, Steve. IBM’s SOA Foundation: An

Architectural Introduction and Overview. [Elektronski] 1.0, 15. november 2005.

[Navedeno: 18. junij 2009.]

http://download.boulder.ibm.com/ibmdl/pub/software/dw/webservices/ws-soa-

whitepaper.pdf.

14. Biske, Todd. SOA Governance: The key to successful SOA adoption in your

organization. Birmingham : Packt Publishing, 2008. 978-1-847195-86-9.

15. Juric, Matjaz B. Business Process Execution Language for Web Services. januar :

Packt Publishing, 2006. 1-904811-81-7.

16. Moinuddin, Moin. An Overview of Service-Oriented Architecture in Retail. Microsoft

Corporation. [Elektronski] januar 2007. [Navedeno: 22. junij 2009.]

http://msdn.microsoft.com/en-us/library/bb264584.aspx.

17. Hotle, Matt. Application and SOA Governance: The Who, What and Why. s.l. :

Gartner, 2008.

18. SOA Governance Framework. The Open Group. [Elektronski] Draft 2.4, 20. april

2009. [Navedeno: 23. junij 2009.] https://www.opengroup.org/projects/soa-

governance/uploads/40/19263/SOA_Governance_Architecture_v2.4.pdf.


19. Keen, Martin, in drugi. Implementing Technology to Support SOA Governance and

Management. s.l. : IBM Corporation, 2007.

20. Increasing the Effectiveness and Efficiency of SOA Through Governance. Oracle

Corporation. [Elektronski] 2008. [Navedeno: 18. avgust 2009.]

http://www.oracle.com/technologies/soa/docs/oracle-governance-whitepaper.pdf.

21. The CentraSite Community: Fast-tracking SOA Governance using best-of-breed

solutions. SoftwareAG. [Elektronski] september 2008. [Navedeno: 9. avgust 2009.]

http://communities.softwareag.com/download/business-

community/Doing%20SOA/WP_CS_Community_med.pdf.

22. Answers to the Six Most-Asked. AgilePath. [Elektronski] 2005.

[Navedeno: 10. avgust 2009.]

http://www.agile-path.com/_media/whitepapers/Six_most_asked_SOA_Questions.PDF.

23. Niemann, Michael. Governance for Service-oriented Architectures: An

Implementation Approach. Tehnična Univerza Darmstadt. [Elektronski] [Navedeno: 20.

avgust 2009.] http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-374/I-

ESA2008_MichaelNiemann.pdf.

24. Magic Quadrant for Integrated SOA Governance Technology Sets. Gartner.

[Elektronski] 31. marec 2009. [Navedeno: 29. junij 2009.]

http://mediaproducts.gartner.com/reprints/oracle/article65/article65.html.

25. Next Generation SOA Governance: Enterprise SOA Governance for the Services-

Driven Enterprise. AgilePath. [Elektronski] 2008. [Navedeno: 9. avgust 2009.]

http://www.agile-path.com/_media/whitepapers/NexGen_SOA_Governance.pdf.

26. SOA Governance Framework. CBDI. [Elektronski] CBDI, april 2008.

[Navedeno: 8. avgust 2009.]

http://www.cbdiforum.com/secure/interact/2008-04/challenge_opportunity_br.php.


27. SOA Governance: Framework and Best Practices. Oracle Corporation. [Elektronski]

maj 2007. [Navedeno: 29. junij 2009.]

http://www.oracle.com/technologies/soa/docs/oracle-soa-governance-best-practices.pdf.

28. Simanta, Soumya, in drugi. A Scenario-Based Technique for Developing SOA

Technical Governance. Software Engineering Institute. [Elektronski] junij 2009.

[Navedeno: 11. avgust 2009.] www.sei.cmu.edu/pub/documents/09.reports/09tn009.pdf.

29. Effective SOA Deployment Using an SOA Registry-Repository. SUN Corporation.

[Elektronski] september 2005. [Navedeno: 28. junij 2009.] A Practical Guide.

http://www.sun.com/products/soa/registry/soa_registry_wp.pdf.

30. Worldwide Services Oriented Architecture (SOA) Infrastructure Market Shares,

Strategy, and Forecasts, 2009-2015. WinterGreen Research. [Elektronski] april 2009.

[Navedeno: 30. junij 2009.]

http://www.wintergreenresearch.com/reports/Service%20Oriented%20Architecture%20(S

OA)%20Infrastructure%20Market.htm.

31. Dudley, Chris, in drugi. WebSphere Service Registry and Repository Handbook. s.l. :

IBM Corporation, 2005.

32. Cantor, Mrray in Sanders, John D. Operational IT Governance. IBM

developerWorks. [Elektronski] IBM Corporation, 15. maj 2007. [Navedeno: 15. julij 2009.]

http://www.ibm.com/developerworks/rational/library/may07/cantor_sanders/.


8 PRILOGE

8.1 Seznam slik

Slika 2.1 IT vodenje kot podmnoţica poslovnega vodenja ................................................... 7

Slika 2.2 Odvisnost med vodenjem in upravljanjem ............................................................. 8

Slika 3.1 Ponastavljen koncept ponudnik-uporabnik, uporabljen v SOA ........................... 12

Slika 3.2 Kompozitna storitev ali poslovni proces .............................................................. 13

Slika 3.3 The Open Group SOA, referenčna arhitektura (12) ............................................. 16

Slika 4.1 SOA vodenje kot podmnoţica poslovnega in IT vodenja .................................... 24

Slika 4.2 Stopnja posvojitve SOA (20) ............................................................................... 27

Slika 4.3 Pomembnost SOA vodenja (20) ........................................................................... 27

Slika 4.4 Ključni dejavniki za začetek SOA vodenja (20) .................................................. 28

Slika 4.5 Največji izzivi pri SOA vodenju (20)................................................................... 28

Slika 4.6 Kriteriji za izbiro SOA vodenja (20) .................................................................... 29

Slika 4.7 AgilePathov štiriplastni model SOA vodenja (25) ............................................... 34

Slika 4.8 IBM-ova metoda SOA vodenja in upravljanja (19) ............................................. 35

Slika 4.9 Oraclovo ogrodje SOA vodenja (6)...................................................................... 36

Slika 4.10 Referenčno ogrodje SOA vodenja Softwara AG (21) ........................................ 37

Slika 4.11 Ogrodje vodenja CBDi-SAE (26) ...................................................................... 38


Slika 4.12 Ogrodje SOA vodenja organizacije The Open Group (18) ............................... 39

Slika 4.13 SEI-eva tehnika implementacije SOA vodenja (28) .......................................... 42

Slika 4.14 SOA register in repozitorij kot centralno skladišče............................................ 44

Slika 4.15 Konceptualna shema SOA registra in repozitorija ............................................. 45

Slika 4.16 Magični kvadrant celostnih tehnoloških rešitev SOA vodenja (24) .................. 46

Slika 5.1 Gradniki ţivljenjskega cikla ................................................................................. 51

Slika 5.2 Vnaprej nameščen privzeti WSRR ţivljenjski cikel storitve ............................... 51

Slika 5.3 Ogrodje (diagram stanj) za podporo več ţivljenjskih ciklov na WSRR .............. 53

Slika 5.4 Dodajanje ţivljenjskih ciklov na ogrodje ............................................................. 53

Slika 5.5 Kompozitni diagram stanj ţivljenjskega cikla storitve ........................................ 54

Slika 5.6 Diagram prehodov in stanj za fazo modeliranja ................................................... 56

Slika 5.7 Diagram prehodov in stanj za fazo sestavljanja ................................................... 57

Slika 5.8 Diagram prehodov in stanj za fazo namestitve .................................................... 58

Slika 5.9 Diagram prehodov in stanj za fazo upravljanja .................................................... 59

Slika 5.10 Kompozitni diagram stanj ţivljenjskega cikla končne točke ............................. 59

Slika 5.11 Ogrodje z novima ţivljenjskima cikloma v uporabi .......................................... 61

Slika 5.12 Zaporedje izvajanja WSRR vtičnikov ob akciji odjemalca................................ 62

Slika 5.13 Razredni diagram WSRR vmesnikov za validacijo ........................................... 64

Slika 5.14 Nastavitev novega vtičnika na WSRR ............................................................... 65

Slika 5.15 Napaka validacijskega vtičnika v primeru neustreznega imenskega prostora ... 66


Slika 5.16 Razredni diagram WSRR vmesnikov za notifikacijo......................................... 67

Slika 5.17 Zapis notifikatorja o izvedeni akciji v dnevniku aplikacijskega streţnika ......... 68

Slika 5.18 Vloga in dovoljenja v WSRR ............................................................................. 69

Slika 5.19 Primer dovoljenja za prehod na WSRR ............................................................. 71

Slika 5.20 Primer napake zaradi nezadostnih pravic na WSRR .......................................... 71

Slika 5.21 Primer dovoljenja za pridobitev vodenega artefakta na WSRR ......................... 72

Slika 5.22 Pridobitev ID-ja razreda klasifikacije za ţeleno stanje ali prehod ..................... 72

Slika 5.23 Priprava analize vpliva ....................................................................................... 74

Slika 5.24 Rezultat analize vpliva ....................................................................................... 74

8.2 Seznam tabel

Tabela 3-1 Miti in dejstva o SOA ........................................................................................ 15

Tabela 4-1 Pristopi k SOA vodenju ..................................................................................... 32

Tabela 4-2 Produkti SOA registra in repozitorija ................................................................ 47

Tabela 5-1 Prehodi in stanja ter opisi za fazo modeliranja.................................................. 55

Tabela 5-2 Prehodi in stanja ter opisi za fazo sestavljanja .................................................. 56

Tabela 5-3 Prehodi in stanja ter opisi za fazo namestitve ................................................... 57

Tabela 5-4 Prehodi in stanja ter opisi za fazo upravljanja ................................................... 59

Tabela 5-5 Prehodi in stanja ter opisi za ţivljenjski cikel končne točke ............................. 60

Tabela 5-6 Veljavne akcije za WSRR dovoljenja (31)........................................................ 70


8.3 Seznam izvorne kode

Izvorna koda 1 WSRR vtičnik validator.............................................................................. 64

Izvorna koda 2 XML shema Diploma ................................................................................. 66

Izvorna koda 3 WSRR vtičnik notifikator ........................................................................... 67

8.4 Naslov študenta

Matej Hertiš

Gozdarska ul. 11

2342 Ruše, Slovenija

Telefon: +386 (0)41 820 552

E-pošta: [email protected]

8.5 Kratek ţivljenjepis

Rojen: 20. 3. 1985 v Mariboru

Šolanje: 1992-2000 Osnovna šola Janka Glazerja, Ruše

2000-2004 Srednja elektro-računalniška šola Maribor

2004-2009 Fakulteta za elektrotehniko, računalništvo in informatiko, Maribor

mailto:[email protected]

Vodenje storitveno usmerjene arhitekture · Service-oriented architecture governance Key words:...

Documents

Transcript of Vodenje storitveno usmerjene arhitekture · Service-oriented architecture governance Key words:...