View
3
Download
0
Category
Preview:
Citation preview
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.
Vodenje storitveno usmerjene arhitekture Stran 3
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.
Stran 4 Vodenje storitveno usmerjene 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).
Vodenje storitveno usmerjene arhitekture Stran 5
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.
Stran 6 Vodenje storitveno usmerjene arhitekture
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).
Vodenje storitveno usmerjene arhitekture Stran 7
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).
Stran 8 Vodenje storitveno usmerjene arhitekture
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.
Vodenje storitveno usmerjene arhitekture Stran 9
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.
Stran 10 Vodenje storitveno usmerjene arhitekture
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
Vodenje storitveno usmerjene arhitekture Stran 11
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.
Stran 12 Vodenje storitveno usmerjene arhitekture
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.
Vodenje storitveno usmerjene arhitekture Stran 13
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).
Stran 14 Vodenje storitveno usmerjene arhitekture
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.
Vodenje storitveno usmerjene arhitekture Stran 15
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.
Stran 16 Vodenje storitveno usmerjene arhitekture
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)
Vodenje storitveno usmerjene arhitekture Stran 17
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«.
Stran 18 Vodenje storitveno usmerjene arhitekture
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« …
Vodenje storitveno usmerjene arhitekture Stran 19
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.
Stran 20 Vodenje storitveno usmerjene arhitekture
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.
Vodenje storitveno usmerjene arhitekture Stran 21
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.
Stran 22 Vodenje storitveno usmerjene arhitekture
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
Vodenje storitveno usmerjene arhitekture Stran 23
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.
Stran 24 Vodenje storitveno usmerjene arhitekture
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.
Vodenje storitveno usmerjene arhitekture Stran 25
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
Stran 26 Vodenje storitveno usmerjene arhitekture
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.
Vodenje storitveno usmerjene arhitekture Stran 27
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
Stran 28 Vodenje storitveno usmerjene arhitekture
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
Vodenje storitveno usmerjene arhitekture Stran 29
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
Stran 30 Vodenje storitveno usmerjene arhitekture
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).
Vodenje storitveno usmerjene arhitekture Stran 31
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.
Stran 32 Vodenje storitveno usmerjene arhitekture
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 ● ● ● ● ● ● ● ● ● ● ○
Vodenje storitveno usmerjene arhitekture Stran 33
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.
Stran 34 Vodenje storitveno usmerjene arhitekture
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)
Vodenje storitveno usmerjene arhitekture Stran 35
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)
Stran 36 Vodenje storitveno usmerjene arhitekture
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.
Dodatne informacije je mogoče najti na:
http://www.oracle.com/technologies/soa/soa-governance.html.
Slika 4.9 Oraclovo ogrodje SOA vodenja (6)
Vodenje storitveno usmerjene arhitekture Stran 37
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.
Dodatne informacije je mogoče najti na:
http://www.softwareag.com/Corporate/products/wm/soa_governance/default.asp.
Slika 4.10 Referenčno ogrodje SOA vodenja Softwara AG (21)
Stran 38 Vodenje storitveno usmerjene arhitekture
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)
Vodenje storitveno usmerjene arhitekture Stran 39
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.
Stran 40 Vodenje storitveno usmerjene arhitekture
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
Vodenje storitveno usmerjene arhitekture Stran 41
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.
Stran 42 Vodenje storitveno usmerjene arhitekture
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)
Vodenje storitveno usmerjene arhitekture Stran 43
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.
Stran 44 Vodenje storitveno usmerjene arhitekture
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.
Vodenje storitveno usmerjene arhitekture Stran 45
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
Stran 46 Vodenje storitveno usmerjene arhitekture
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)
Vodenje storitveno usmerjene arhitekture Stran 47
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
Stran 48 Vodenje storitveno usmerjene arhitekture
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).
Vodenje storitveno usmerjene arhitekture Stran 49
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,
Stran 50 Vodenje storitveno usmerjene arhitekture
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.
Vodenje storitveno usmerjene arhitekture Stran 51
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
Stran 52 Vodenje storitveno usmerjene arhitekture
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.
Vodenje storitveno usmerjene arhitekture Stran 53
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
Stran 54 Vodenje storitveno usmerjene arhitekture
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.
Vodenje storitveno usmerjene arhitekture Stran 55
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.
Stran 56 Vodenje storitveno usmerjene arhitekture
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.
Vodenje storitveno usmerjene arhitekture Stran 57
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.
Stran 58 Vodenje storitveno usmerjene arhitekture
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
Vodenje storitveno usmerjene arhitekture Stran 59
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
Stran 60 Vodenje storitveno usmerjene arhitekture
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.
Vodenje storitveno usmerjene arhitekture Stran 61
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
Stran 62 Vodenje storitveno usmerjene arhitekture
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
Vodenje storitveno usmerjene arhitekture Stran 63
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.
Stran 64 Vodenje storitveno usmerjene arhitekture
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;
}
…
Vodenje storitveno usmerjene arhitekture Stran 65
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.
Stran 66 Vodenje storitveno usmerjene arhitekture
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>
Vodenje storitveno usmerjene arhitekture Stran 67
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());
}
}
…
Stran 68 Vodenje storitveno usmerjene arhitekture
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
Vodenje storitveno usmerjene arhitekture Stran 69
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).
Stran 70 Vodenje storitveno usmerjene arhitekture
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.
Vodenje storitveno usmerjene arhitekture Stran 71
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
Stran 72 Vodenje storitveno usmerjene arhitekture
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
Vodenje storitveno usmerjene arhitekture Stran 73
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.
Stran 74 Vodenje storitveno usmerjene arhitekture
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
Vodenje storitveno usmerjene arhitekture Stran 75
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.
Stran 76 Vodenje storitveno usmerjene arhitekture
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.
Vodenje storitveno usmerjene arhitekture Stran 77
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.
Stran 78 Vodenje storitveno usmerjene arhitekture
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.
Vodenje storitveno usmerjene arhitekture Stran 79
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.
Stran 80 Vodenje storitveno usmerjene arhitekture
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.
Vodenje storitveno usmerjene arhitekture Stran 81
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/.
Stran 82 Vodenje storitveno usmerjene arhitekture
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
Vodenje storitveno usmerjene arhitekture Stran 83
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
Stran 84 Vodenje storitveno usmerjene arhitekture
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
Vodenje storitveno usmerjene arhitekture Stran 85
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: matej.hertis@uni-mb.si
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
Recommended