vpeljava celovitega modela obravnave izjem znotraj ... · into service-oriented architecture key...

Fakulteta za elektrotehniko, računalništvo in informatiko

Doktorska disertacija

Vpeljava celovitega modela obravnave izjem znotraj storitveno usmerjene arhitekture

Marec 2014 Andrej Kocbek

Fakulteta za elektrotehniko, računalništvo in informatiko

Doktorska disertacija

Vpeljava celovitega modela obravnave izjem znotraj storitveno usmerjene arhitekture

Marec 2014 Andrej Kocbek mentor: prof. dr. Matjaž B. Jurič somentor: prof. dr. Ivan Rozman

ix

Zahvala

Iskreno se zahvaljujem vsem, ki ste mi kakorkoli pomagali pri nastanku doktorske disertacije.

Za ideje in nasvete pri pisanju disertacije se zahvaljujem

mentorju dr. Matjažu B. Juriču, somentorju dr. Ivanu Rozmanu ter vsem sodelavcem v laboratoriju za njihovo pomoč in prijetno delo.

Posebej bi se rad zahvalil svojim najbližjim. Predvsem staršem, ki so me podpirali in

mi omogočili brezskrbno doseganje zastavljenih ciljev. Rad bi se zahvalil tudi bratu Simonu za vso podporo.

Posebna zahvala gre tudi prijateljem,

ki so me nesebično spodbujali in mi stali ob strani.

»Operacijo delno financira Evropska unija, in sicer iz Evropskega socialnega sklada. Operacija se izvaja v okviru Operativnega programa razvoja človeških virov za obdobje 2007-2013, 1. razvojne prioritete: Spodbujanje podjetništva in prilagodljivosti; prednostne usmeritve 1.1: Strokovnjaki in raziskovalci za konkurenčnost podjetij.«

xi

KAZALO

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

1.1 Opredelitev raziskovalnega problema ............................................................................................ 1 1.1.1 Obravnava izjem v sistemih za izvajanje poslovnih procesov ...................................................... 2 1.1.2 Obravnava izjem znotraj storitveno usmerjene arhitekture ....................................................... 3

1.2 Cilji doktorske disertacije ............................................................................................................... 4 1.2.1 Teza in hipoteze doktorske disertacije ........................................................................................ 4 1.2.2 Pričakovani izvirni znanstveni prispevki ...................................................................................... 5

1.3 Uporabljene metode znanstvenega raziskovanja ........................................................................... 6

1.4 Predpostavke in omejitve ............................................................................................................... 6

1.5 Struktura disertacije ....................................................................................................................... 7

PREGLED RAZISKOVALNEGA PODROČJA..................................................................... 9 2

2.1 Obravnava izjem kompozitnih storitev znotraj sistemov za izvajanje poslovnih procesov ............ 10

2.2 Obravnava izjem poslovnih procesov na podlagi uporabe mehanizmov vpeljave politik .............. 11

2.3 Obravnava izjem BPEL na podlagi uporabe pravil ECA .................................................................. 14

2.4 Uporaba koncepta anotacij pri obravnavi izjem brez spreminjanja kontrolnega toka poslovnega procesa .................................................................................................................................................... 16

2.5 Uveljavljene razširitve jezika BPEL ................................................................................................ 16

PREDSTAVITEV RAZISKOVALNEGA PODROČJA ..................................................... 19 3

3.1 Predstavitev procesno umerjenih informacijskih sistemov ........................................................... 19 3.1.1 Kronološki pregled razvoja jezikov za izvajanje poslovnih procesov ......................................... 20 3.1.2 Referenčni model poslovnih procesov ...................................................................................... 23 3.1.3 Življenjski cikel PAIS ................................................................................................................... 25

3.2 Upravljanje poslovnih procesov ................................................................................................... 26

3.3 Jeziki za upravljanje poslovnih procesov ...................................................................................... 27 3.3.1 Petrijeve mreže .......................................................................................................................... 29 3.3.2 YAWL.......................................................................................................................................... 30 3.3.3 EPC ............................................................................................................................................. 31 3.3.4 WPDL in XPDL ............................................................................................................................ 31 3.3.5 BPML .......................................................................................................................................... 32 3.3.6 XLANG ........................................................................................................................................ 33 3.3.7 WSFL .......................................................................................................................................... 33 3.3.8 WSCL .......................................................................................................................................... 33 3.3.9 BPMN ......................................................................................................................................... 34 3.3.10 WS-CDL ...................................................................................................................................... 35 3.3.11 BPEL ........................................................................................................................................... 35

xii

3.4 Izvajanje poslovnih procesov znotraj storitveno usmerjene arhitekture ...................................... 37 3.4.1 Prednosti uporabe SOA pri izvajanju poslovnih procesov ......................................................... 40 3.4.2 Tehnične komponente ............................................................................................................... 41 3.4.3 Kompozicija spletnih storitev znotraj storitveno usmerjene arhitekture .................................. 47 3.4.4 WS – BPEL .................................................................................................................................. 48 3.4.5 Signalizacija in obravnava izjem poslovnih procesov ................................................................ 58

3.5 Vzorci obravnave izjem ................................................................................................................ 62 3.5.1 Obravnava izjem na nivoju aktivnosti ........................................................................................ 64 3.5.2 Obravnava izjem na nivoju primera ........................................................................................... 67 3.5.3 Aktivnosti obnovitve .................................................................................................................. 68 3.5.4 Mehanizem obravnave izjem..................................................................................................... 68 3.5.5 Strategije obravnave izjem ........................................................................................................ 68 3.5.6 Predstavitev primera uporabe vzorcev strategij obravnave izjem ............................................ 73

PREDSTAVITEV REŠITVE ............................................................................................... 79 4

4.1 Podrobna predstavitev problema ................................................................................................. 79 4.1.1 Napaka pri klicu storitev ............................................................................................................ 79 4.1.2 Podvojenost kode ...................................................................................................................... 81 4.1.3 Prepletanje logike poslovnega toka z logiko obravnave izjem .................................................. 81

4.2 Formalni model ............................................................................................................................ 82 4.2.1 Uporaba politik obravnave izjem ............................................................................................... 83 4.2.2 Upravljavci izjem ........................................................................................................................ 85 4.2.3 Strategije obravnave izjem ........................................................................................................ 87

PRESLIKAVA PREDLAGANEGA MODELA V JEZIK BPEL ........................................ 89 5

5.1 Deklaracija razširljivosti jezika BPEL ............................................................................................. 90

5.2 Realizacija politik obravnave izjem ............................................................................................... 92 5.2.1 Struktura politike obravnave izjem............................................................................................ 92 5.2.2 Vključitev politike obravnave izjem znotraj procesa BPEL ........................................................ 95 5.2.3 Nevsiljiva uporaba politik obravnave izjem znotraj procesa BPEL ............................................ 97 5.2.4 Obravnava izjem z uporabo upravljavca izjem znotraj politik obravnave izjem ........................ 98

5.3 Realizacija strategij obravnave izjem ............................................................................................ 99 5.3.1 Strategije obravnave izjem ........................................................................................................ 99 5.3.2 Ponovno proženje aktivnosti ................................................................................................... 101 5.3.3 Beleženje izjem ........................................................................................................................ 102 5.3.4 Obveščanje administratorjev procesa ..................................................................................... 103 5.3.5 Ponovitev obsega BPEL ............................................................................................................ 104 5.3.6 Pošiljanje izjem naprej do standardnega mehanizma obravnave izjem BPEL ......................... 104

OVREDNOTENJE UČINKOVITOSTI PREDLAGANE REŠITVE IN ANALIZA 6REZULTATOV ...........................................................................................................................107

6.1 Zbiranje procesnih modelov za ovrednotenje učinkovitosti predlagane rešitve ......................... 109

6.2 Priprava nabora in razširitev procesnih modelov ....................................................................... 109

6.3 Identifikacija in izbira metrik za merjenje kompleksnosti procesnih modelov ............................ 110

xiii

6.3.1 Perspektive kompleksnosti poslovnih procesov ...................................................................... 111 6.3.2 Metrike kompleksnosti poslovnih procesov ............................................................................ 113

6.4 Izvajanje meritev kompleksnosti procesnih modelov ................................................................. 120 6.4.1 Primer izvedbe meritev kompleksnosti poslovnega procesa .................................................. 121 6.4.2 Rezultati meritev kompleksnosti ............................................................................................. 122

6.5 Analiza pridobljenih rezultatov .................................................................................................. 123

RAZPRAVA O HIPOTEZAH ............................................................................................127 7

ZAKLJUČEK ........................................................................................................................129 8

LITERATURA ....................................................................................................................131 9

xiv

KAZALO SLIK

SLIKA 1: RAZVOJ INFORMACIJSKIH SISTEMOV [63]. ..................................................................................................... 21

SLIKA 2: REFERENČNI MODEL POSLOVNIH PROCESOV [69]. ........................................................................................... 23

SLIKA 3: ŽIVLJENJSKI CIKEL PAIS. ............................................................................................................................. 25

SLIKA 4: ČASOVNI RAZVOJ SPECIFIKACIJE BPEL. .......................................................................................................... 37

SLIKA 5: STORITVENO USMERJENA ARHITEKTURA [82]. ................................................................................................ 40

SLIKA 6: LOČITEV APLIKACIJ ODJEMALCA OD STORITEV [128]. ....................................................................................... 44

SLIKA 7: RAZVOJ KONTROLNIH VZORCEV POSLOVNIH PROCESOV S STRANI IPW [24]. ......................................................... 63

SLIKA 8: ŽIVLJENJSKI CIKEL AKTIVNOSTI Z VIDIKA POSAMEZNEGA VIRA [145]. .................................................................... 65

SLIKA 9: PRIMITIVNI GRADNIKI ZA OBRAVNAVO IZJEM. [59] .......................................................................................... 73

SLIKA 10: VZORČNA UPORABA PRIMARNIH GRADNIKOV ZA OBRAVNAVO IZJEM. ................................................................ 74

SLIKA 11: POSLOVNI PROCES IZTERJAVA. ................................................................................................................... 75

SLIKA 12: PREDSTAVITEV VZORCA OBRAVNAVE IZJEME Z UPORABO PREPROSTIH GRADNIKOV – A. ......................................... 75

SLIKA 13: PREDSTAVITEV VZORCA OBRAVNAVE IZJEME Z UPORABO PREPROSTIH GRADNIKOV – B. ......................................... 76

SLIKA 14: PREDSTAVITEV VZORCA OBRAVNAVE IZJEME Z UPORABO PREPROSTIH GRADNIKOV – C. ......................................... 76

SLIKA 15: PREDSTAVITEV VZORCA OBRAVNAVE IZJEME Z UPORABO PREPROSTIH GRADNIKOV – D. ......................................... 77

SLIKA 16: REŠITEV BPEL ZA NAPAKE PRI KLICU STORITEV. ............................................................................................. 80

SLIKA 17: VISOKONIVOJSKI PREGLED PREDLAGANIH KONCEPTOV RAZŠIRITVE JEZIKA BPEL. .................................................. 90

SLIKA 18: POSTOPEK OVREDNOTENJA UČINKOVITOSTI REŠITVE. ................................................................................... 108

SLIKA 19: KOMPLEKSNOSTI TOKA POSLOVNEGA PROCESA. .......................................................................................... 111

SLIKA 20: PORAZDELITEV IZRAČUNANIH ZNIŽANJ KOMPLEKSNOSTI PROCESOV BPEL. ....................................................... 124

xv

KAZALO TABEL

TABELA 1: PREDSTAVITEV RAZŠIRITEV JEZIKA BPEL. .................................................................................................... 17

TABELA 2: KATEGORIZACIJA IZJEM BPEL. .................................................................................................................. 58

TABELA 3: RAZPOREDITEV SESTAVLJENIH VZORCEV V SKUPINE OBSEGA DOGODKOV IZJEM [145]. ......................................... 70

TABELA 4: ANALIZE PODPORE POSAMEZNIM VZORCEM S STRANI PROCESNIH JEZIKOV. ........................................................ 72

TABELA 5: PRESLIKAVA STRUKTURE POLITIKE IZ FORMALNEGA JEZIKA V JEZIK BPEL. ........................................................... 92

TABELA 6: PRESLIKAVA STRATEGIJ OBRAVNAVE IZJEM IZ FORMALNEGA MODELA V JEZIK BPEL............................................ 101

TABELA 7: UTEŽI KOMPLEKSNOSTI AKTIVNOSTI PROCESA BPEL. ................................................................................... 118

TABELA 8: REZULTATI MERITEV KOMPLEKSNOSTI NA POSLOVNEM PROCESU IZTERJAVA. .................................................... 121

TABELA 9: RAZLIKE KOMPLEKSNOSTI MED RAZŠIRJENIM IN NERAŠIRJENIM POSLOVNIM PROCESOM IZTERJAVA. ...................... 122

TABELA 10: RAZLIKE V KOMPLEKSNOSTI MED NERAZŠIRJENIMI IN RAZŠIRJENIMI PROCESI BPEL. ......................................... 123

TABELA 11: IZRAČUNANI STATISTIČNI PODATKI ZA POSAMEZNO PROCESNO ORIENTIRANO METRIKO. ................................... 123

xvi

KAZALO IZSEKOV

IZSEK 1: STRUKTURA PROCESA BPEL 2.0. ................................................................................................................. 49

IZSEK 2: SINTAKSA UPRAVLJAVCEV DOGODKOV. .......................................................................................................... 56

IZSEK 3: IZRECNA ZAHTEVA NASTANKA IZJEME BPEL. ................................................................................................... 59

IZSEK 4: IZRECNA ZAHTEVA PROŽENJA IZJEME BPEL Z UPORABO SPREMENLJIVKE. .............................................................. 59

IZSEK 5: SINTAKSA EKSPLICITNEGA UPRAVLJAVCA IZJEM. ............................................................................................... 61

IZSEK 6: SINTAKSA IMPLICITNEGA UPRAVLJAVCA IZJEM. ................................................................................................ 62

IZSEK 7: UPORABA STANDARDNEGA MEHANIZMA RAZŠIRLJIVOSTI BPEL. ......................................................................... 91

IZSEK 8: SINTAKSA RAZŠIRLJIVE AKTIVNOSTI <EXTENSIONACTIVITY>. ....................................................................... 91

IZSEK 9: STRUKTURA POLITIKE OBRAVNAVE IZJEM. ....................................................................................................... 94

IZSEK 10: VKLJUČITEV POLITIK OBRAVNAVE IZJEM V JEZIK BPEL. .................................................................................... 95

IZSEK 11: UPORABA POLITIK OBRAVNAVE IZJEM ZNOTRAJ OBSEGA. ................................................................................. 97

IZSEK 12: RAZŠIRJEN UPRAVLJAVEC IZJEM. ................................................................................................................. 99

IZSEK 13: VPELJANE STRATEGIJE OBRAVNAVE IZJEM V JEZIK BPEL. ............................................................................... 100

IZSEK 14: PRIMER SINTAKSE STRATEGIJE OBRAVNAVE IZJEM - PONOVNO PROŽENJE AKTIVNOSTI. ........................................ 102

IZSEK 15: PRIMER SINTAKSE STRATEGIJE OBRAVNAVE IZJEM – BELEŽENJE IZJEM. ............................................................. 103

IZSEK 16: PRIMER SINTAKSE STRATEGIJE OBRAVNAVE IZJEM – OBVEŠČANJE ADMINISTRATORJA PROCESA. ............................ 104

IZSEK 17: PRIMER SINTAKSE STRATEGIJE OBRAVNAVE IZJEM – PONOVITEV OBSEGA BPEL. ................................................ 104

IZSEK 18: PRIMER SINTAKSE STRATEGIJE OBRAVNAVE IZJEM – POŠILJANJE IZJEM NAPREJ. .................................................. 105

xvii

Vpeljava celovitega modela obravnave izjem znotraj

storitveno usmerjene arhitekture

Ključne besede: storitveno usmerjena arhitektura, obravnava izjem, politika

obravnave izjem, upravljavec izjem, poslovni proces, BPEL

UDK: 004.434:005(043.3)

Povzetek:

Storitveno usmerjena arhitektura predstavlja evolucijo porazdeljenih računalniških

sistemov in temelji na konceptih interoperabilnih storitev. Ena izmed vidnejših

pomanjkljivosti storitveno usmerjene arhitekture je njena pomanjkljiva podpora

obravnavi izjem. To predstavlja precejšnjo oviro pri gradnji kompleksnih in za

izvedbo nalog ključno pomembnih aplikacij. Učinkovita obravnava izjem v poslovnih

procesih in orkestriranih spletnih storitvah tako predstavlja atribut zanesljivosti

izvajanja modelov poslovnih procesov. V doktorski disertaciji se osredotočimo na

vpeljavo celovitega modela obravnave izjem znotraj storitvene usmerjene

arhitekture. V ta namen predlagamo formalni model za specifikacijo obravnave izjem

na osnovi politik in strategij obravnave izjem v modelih poslovnih procesov z

namenom vzpostaviti in omogočiti večjo odpornost procesov na izjeme. Predlagani

formalni model podamo s pomočjo matematičnega zapisa. S formalnim modelom

naslovimo izpostavljene pomanjkljivosti obravnave izjem procesno usmerjenih

izvršljivih jezikov v storitveno usmerjeni arhitekturi. Formalni model je zasnovan

tako, da je neodvisen od procesnega jezika. Izvedljivost formalnega modela

preverimo z njegovo preslikavo v jezik za izvajanje poslovnih procesov (BPEL), ki

predstavlja de-facto standard za orkestracijo storitev znotraj storitveno usmerjene

arhitekture. Učinkovitost predlaganega formalnega modela preverimo z merjenjem

kompleksnosti procesnih modelov ob podpori uporabe procesno usmerjenih metrik.

xviii

Introduction of the comprehensive fault handling model

into service-oriented architecture

Key Words: service-oriented architecture, fault handling, fault policy, fault handler,

business process, BPEL

Abstract:

Service Oriented Architecture is an evolution of distributed computing systems. It is

based on the concepts of interoperable services. Service Oriented Architecture does

not provide sufficient architectural support for application and information

integration. One of its noticeable deficiencies is its basic and limited fault handling

mechanism which presents problems when building complex and crucial

applications. Powerful and flexible fault handling abilities in business processes and

orchestrated web services play a critical role in implementation of business process

models. In this doctoral thesis we focus on introducing a formal model for fault

handling mechanism within Service Oriented Architecture. The proposed model

defines policies and fault handling strategies. It aims to make business processes

more fault tolerant. We explain it with a mathematical representation. The proposed

model addresses fault handling issues of process oriented executable languages in

Service Oriented Architecture. Our model does not depend on a particular process

language. We evaluate the feasability of the proposed model by translating it into

Business Process Execution Language. Business Process Execution Language

represents de-facto standard for orchestrating web services inside Service Oriented

Architecture. Furthermore, we measure complexity of business process models by

using process metrics. This way we check the efficiency of the proposed model.

Univerza v Mariboru Doktorska disertacija

Andrej Kocbek – Vpeljava celovitega modela obravnave izjem znotraj storitveno usmerjene arhitekturo 1

Uvod 1

1.1 Opredelitev raziskovalnega problema

Storitveno usmerjena arhitektura (angl. Service Oriented Architecture, krat. SOA) in

upravljanje poslovnih procesov (angl. Business Process management, krat. BPM) sta

se v današnjem času že dodobra usidrala pri razvoju informacijskih sistemov. Oba

pristopa spodbujata procesno razmišljanje in težita k usklajenosti informacijske

podpore s poslovanjem. SOA predstavlja arhitekturni način medsebojnega

sodelovanja storitev in uporabnikov, ki jo sestavljajo ohlapno povezane storitve ter

jasno definirani vmesniki [1]. Omenjene storitve niso samo komponente, ampak

imajo tudi poslovni pomen. Namenjene so večkratni uporabi v različnih poslovnih

procesih. Možnost enostavnega preurejanja in deljenje storitev med poslovne procese

obeta hitro prilagoditev sistemov na spreminjajoče se poslovne zahteve [2].

Izvajanje poslovnih procesov bi bilo precej enostavnejše, če bi se vse poslovne

aktivnosti znotraj procesa izvedle uspešno, brez da pride do kakršnikoli napak oz.

izjem [3]. Sistemi z naprednimi interaktivnimi aktivnostmi so zaradi kompleksnosti

in dolgo trajajočih procesov precej dovzetni za izjeme [4, 5]. Izjema nastopi ob

nepravilnem izvajanju storitve. S povečanjem heterogenosti in kompleksnosti

poslovnih procesov je njihova implementacija postala izziv za vsakega načrtovalca

procesov. Pogosto se za implementacijo aktivnosti, ki se uspešno izvedejo, uporabi

majhen del celotnega časa, ki je namenjen načrtovanju in implementaciji poslovnih

procesov. Večino časa se porabi za opredelitev ustrezne logike obravnave izjem, s

katero želimo vzpostaviti robusten in prožen proces, katerega primerek se uspešno

izvede v vseh pričakovanih in nepričakovanih pogojih [6]. Skupina Hurwitz [7]

ocenjuje, da je pri načrtovanju in implementaciji poslovnih procesov skoraj 80%

celotnega časa porabljenega za obravnavo izjem. Kljub uspešni avtomatizaciji

poslovnih procesov zadnja raziskava kaže [8], da se za obravnavo izjem porabi še

vedno približno 66% časa. Obstajajo številni tehnični in poslovni razlogi, zaradi



katerih so izjeme še vedno tako pogost pojav pri izvajanju primerkov realnih

poslovnih procesov [9]:

Napake na nivoju sistema (npr. težave z omrežjem in razpoložljivostjo virov,

okvara podatkov, itd.) je težko odpraviti.

Hitri razvoj poslovnih ciklov ne dopušča dovolj časa za temeljito testiranje

novih procesov na poslovnem in tehničnem nivoju. Pri vpeljavi novega

poslovnega procesa v produkcijskem okolju se lahko pričakuje, da se bodo

pojavile določene izjeme, ki jih bo potrebno obravnavati.

Kontekst poslovnega procesa v podjetju lahko povzroči izjemo (npr. produkt je

razprodan).

Zunanji dejavniki, na katere podjetje ne more vplivati, lahko povzročijo izjeme

(npr. vremenske razmere lahko povzročijo zamudo pri dostavi pošiljke).

Zato vpeljava celovitega mehanizma obravnave izjem predstavlja pomemben vidik

pri načrtovanju in implementaciji poslovnih procesov. SOA mora tako biti zasnovana

na način, da tudi v primeru pojava izjeme ta ne povzroči zaustavitve delovanja

sistema oz. njegovega nepravilnega izvajanja.

1.1.1 Obravnava izjem v sistemih za izvajanje poslovnih procesov

Ena izmed pomembnejših pomanjkljivost obstoječih sistemov za izvajanje poslovnih

procesov je njihova slaba podpora obravnavi izjem. To predstavlja veliko oviro pri

gradnji kompleksnih in za izvedbo nalog ključno pomembnih aplikacij. Učinkovita

obravnava izjem v poslovnih procesih in orkestriranih spletnih storitvah tako

predstavlja atribut uspešne obstojnosti sistemov za izvajanje poslovnih procesov.

Večina aplikacij, ki temelji na izvajanju poslovnih procesov, se srečuje z izjemami, kot

so napake pri klicu storitev, težave pri komunikaciji, umanjkanje odziva uporabnikov,

zamujanje rokov in nepričakovano delovanje poslovne logike.

Za zagotavljanje zanesljivosti sistemov v splošnem obstajajo štirje glavni pristopi:

preprečevanje, obravnavanje, odstranjevanje in napovedovanje izjem [10]. Očitno je

nemogoče, da bi se med izvajanjem poslovnih procesov izognili vsem izjemam.

Obravnava izjem, katere cilj je zagotavljanje pravilnega izvajanja storitev tudi ob

prisotnosti izjem, predstavlja tako najboljšo izbiro za zanesljivo izvajanje poslovnih



procesov. Trenutno najbolj splošen in razširjen postopek obravnave izjem vključuje

zaustavitev izvajanja procesa in poročanje o izjemah administratorju procesa. Ker pa

poslovni procesi postajajo obsežnejši in kompleksnejši, je ročna odprava izjem vedno

težje izvedljiva. Skladno s tem je jasno, da potrebujemo samodejno obravnavanje

izjem.

V ta namen sistemi za izvajanje poslovnih procesov vsebujejo upravljavce izjem (angl.

exception handlers). Upravljavci izjem lahko samodejno in fleksibilno obravnavajo

vse vrste izjem, v kolikor načrtovalci procesa pričakujejo izjeme, do katerih prihaja. V

nasprotnem primeru je za obravnavno izjem potrebna človeška interakcija (npr.

uporaba uporabniških opravil, ki so posebej namenjena obravnavi izjem).

1.1.2 Obravnava izjem znotraj storitveno usmerjene arhitekture

Pri vzpostavitvi zanesljivosti sistemov, ki temeljijo na SOA, je potrebno upoštevati tri

različne arhitekturne nivoje, na katerih se lahko pojavijo izjeme: (1) tok poslovnega

procesa, (2) delovanje storitvenega vodila in (3) izvajanje zunanjih storitev. Pri

delovanju storitvenega vodila prihaja do tehničnih izjem, medtem ko pri izvajanju

poslovnega toka in zunanjih storitev prihaja do poslovnih izjem.

V SOA se za implementacijo poslovnih procesov uporablja jezik za izvajanje poslovnih

procesov (angl. Business Process Execution Language, krat. BPEL), medtem ko za

izvajanje implementiranih procesov poskrbi procesni strežnik. Skladno s tem

moramo pri izvajanju poslovnega toka oz. procesa upoštevati standardni mehanizem

obravnave izjem, ki ga ponuja BPEL. Načrtovanje procesov BPEL zahteva opredelitev

konstruktov BPEL, ki so namenjeni implementaciji obravnave izjem (npr. upravljavci

izjem) na razmeroma nizkem nivoju. Zaradi tega pride do prepletanja normalne

poslovne logike procesov z logiko procesa, ki služi obravnavi izjem. Posledično so

razvoj, vzdrževanje in nadgradnja obeh vrst procesnih logik oteženi [11].

Trenutna specifikacija BPEL (oz. natančneje Web Services BPEL, krat. WS-BPEL,

verzije 2.0) prav tako zahteva, da načrtovalci procesov za vsak poslovni proces

definirajo svoje upravljavce izjem. V primeru, da imamo znotraj sistema več

poslovnih procesov, moramo za vsak proces posebej definirati upravljavce izjem.

Zaradi tega lahko pride do primera, ko moramo isti ali podoben upravljavec izjem



definirati večkrat. Rezultat tega je podvojenost programske kode upravljavcev izjem.

Podvojenost programske kode je velik problem in lahko povzroči številne težave, ki

se kažejo v obliki otežene berljivosti, povečanega obsega in kompleksnosti procesnih

modelov [12].

1.2 Cilji doktorske disertacije

Na podlagi opredelitve raziskovalnega problema je glavni cilj disertacije predlagati in

vpeljati celovit model obravnave izjem v storitveno usmerjeno arhitekturo. Cilj

izdelave predlaganega formalnega modela je njegova neodvisnost od notacij in jezika

za implementiranje in izvajanje poslovnih procesov. Za namen ovrednotenja

izvedljivosti in učinkovitosti predlaganega formalnega modela je dodatni cilj tudi

vključitev formalnega modela v specifikacijo za implementiranje poslovnih procesov

v storitveno usmerjeno arhitekturo na podlagi vpeljave razširitve specifikacije BPEL.

Razvoj kompleksnega procesnega modela nam omogoča poglobljen vpogled v

načrtovanje, razvoj, strukturo in izvajanje poslovnega procesa. Zato je eden izmed

ciljev doktorske disertacije implementirati kompleksni delovni tok, saj to omogoča

identifikacijo pomanjkljivosti, ki nastanejo pri izvajanju poslovnih procesov. V

disertaciji opravimo tudi analizo obstoječih mehanizmov obravnave izjem ter njihov

doprinos k učinkovitejšemu izvajanju poslovnih procesov. Osredotočimo se na

pomanjkljivosti obravnave izjem v SOA in predstavimo vidike obravnave izjem, ki so

potrebni za implementacijo poslovnega procesa po dobrih praksah.

1.2.1 Teza in hipoteze doktorske disertacije

Na osnovi glavnega cilja doktorske disertacije smo oblikovali sledečo tezo:

Na podlagi identificiranih najpogostejših težav glede obravnave izjem v SOA je mogoče

predlagati model obravnave izjem, ki te težave odpravlja, ga vpeljati v to arhitekturo in

s tem zmanjšati kompleksnost modelov poslovnih procesov.



Iz podane teze doktorske disertacije lahko izpeljemo naslednji hipotezi:

– Mogoče je definirati in razviti model obravnave izjem, ki celovito

obravnava izjeme in odpravlja identificirane pomanjkljivosti1, ter ga vpeljati v

SOA.

– Z uporabo predlaganega modela je mogoče zmanjšati kompleksnost2

modelov poslovnih procesov iz domen, ki zahtevajo obravnavanje izjem 3.

1.2.2 Pričakovani izvirni znanstveni prispevki

V doktorski disertaciji analiziramo izjeme, njihov nastanek in vpliv na izvršljive

modele poslovnih procesov znotraj storitveno usmerjene arhitekture. Analizo

izvedemo v dveh delih:

Sistematični pregled sorodne literature.

Identifikacija vzorcev obravnave izjem poslovnih procesov ter preverjanje

njihove podpore s strani trenutno najbolj aktualnih procesnih jezikov (BPEL,

BPMN (Business Process Model and Notation) in XPDL (XML Process

Definition Language)).

Na podlagi analize razvijemo formalni model, ki omogoča zaznavo ter obravnavo vseh

relevantnih izjem znotraj storitveno usmerjene arhitekture. Predlagan model je

neodvisen od jezika za izvajanje poslovnih procesov. Razviti model preslikamo v de-

facto standard za izvajanje poslovnih procesov BPEL ter tako pokažemo izvedljivost

predlaganega modela. Preslikava je izpeljana z razširitvijo specifikacije WS-BPEL 2.0

in uvedbo novih kontekstnih gradnikov za obravnavo izjem. Razširitve temeljijo na

osnovi trenutne specifikacije WS-BPEL 2.0 ter standardiziranih razširitvenih

mehanizmov, ki jih specifikacija ponuja v ta namen. Učinkovitost predlaganega

modela preverimo z merjenjem kompleksnosti modelov poslovnih procesov, pri

čemer uporabimo procesno orientirane metrike za merjenje kompleksnosti.

Pokažemo, da predlagane razširitve izpolnjujejo uveljavljene kriterije obravnave

1 Predstavljene v poglavju 4.1.

2 Meritve opravljene z razširjenimi relevantnimi metrikami (predstavljene v poglavju 6.3).

3 To so domene temeljnih poslovnih procesov v organizacijah na vseh nivojih dekompozicije

(predstavljeno v poglavju 6.1).



izjem pri izvajanju poslovnih procesov in da so učinkovitejše s stališča strukturne

kompleksnosti poslovnega procesa v primerjavi z obstoječo specifikacijo.

1.3 Uporabljene metode znanstvenega raziskovanja

V raziskovalnem delu uporabimo sistemski pristop ter opravimo sistematični in

celoviti pregled znanstvene ter strokovne literature s področja obravnave izjem

izvršljivih procesnih jezikov znotraj storitveno usmerjene arhitekture.

Na podlagi znanja in ugotovitev, ki so bila pridobljena z analizo raziskovalnega

področja in trenutnega stanja, definiramo formalni model za izboljšano in

učinkovitejšo obravnavo izjem izvršljivih procesnih jezikov znotraj storitveno

usmerjene arhitekture. Pri tem uporabimo znanja s področja upravljanja in izvajanja

izvršljivih procesnih modelov, obravnave izjem, storitveno usmerjene arhitekture ter

vpeljave politik obravnave izjem s podporo aktivnosti obnovitve izvajanja primerkov

poslovnih procesov. Predstavljeni formalni model obravnave izjem izvršljivih

procesnih modelov je neodvisen od procesnega jezika.

Izvedljivost predlagane rešitve preverimo s preslikavo formalnega modela v

konkreten izvršljiv jezik, BPEL. Pri tem si pomagamo z uporabo standardiziranih

razširitvenih mehanizmov specifikacije tega jezika, WS-BPEL 2.0 in notacije

razširljivega označevalnega jezika (angl. Extensible Markup Language, krat. XML)

[13]. Dodatno z implementacijo formalnega modela zagotovimo osnovo za

ovrednotenje njegove učinkovitosti. Učinkovitost predlagane rešitve v smislu znižanja

kompleksnosti modelov poslovnih procesov analiziramo in preverimo z empiričnimi

meritvami. Meritve izvedemo s pomočjo procesno orientiranih metrik na realnih

poslovnih procesih. Rezultate merjenja kompleksnosti analiziramo in tako natančno

ovrednotimo učinkovitost in zanesljivost predlagane rešitve.

1.4 Predpostavke in omejitve

Na podlagi lastnih izkušenj in razpoložljive literature [4, 14, 15, 16] predpostavljamo,

da se poslovni procesi pri izvajanju srečujejo s številnimi izjemami in napakami, do

katerih prihaja zaradi dinamičnega poslovnega okolja. Nadalje predpostavljamo, da je



obravnava izjem zelo pomemben vidik za uspešno izvajanje poslovnih procesov, ki pa

ni dobro pokrit [3, 4, 14, 17, 18, 19].

Ko govorimo o obravnavi izjem, moramo nasloviti tako tehnične kot poslovne izjeme

[20]. Osredotočimo se na vse možne izjeme (poslovne in tehnične) ter omogočimo

razširljivost na tiste, ki so odvisne od konkretnega izvajalnega okolja.

Pri vpeljavi modela obravnave izjem znotraj storitveno usmerjene arhitekture na

podlagi razširitev specifikacije WS-BPEL 2.0 upoštevamo priporočila in navodila te

specifikacije glede uporabe razširitvenih tehnologij s področja spletnih storitev. V ta

namen uporabimo jezik XML [13] za definicijo formalnih zapisov.

1.5 Struktura disertacije

Doktorska disertacija je organizirana v devet poglavij. Drugo poglavje podaja pregled

raziskovalnega področja, kjer predstavimo literaturo in njeno analizo. Poglavje

dopolnimo s predstavitvijo sorodnih znanstveno-raziskovalnih del. Sorodna dela se

navezujejo na naslednja področja: (1) obravnava izjem kompozitnih storitev znotraj

sistemov za izvajanje poslovnih procesov, (2) obravnava izjem poslovnih procesov na

podlagi uporabe mehanizmov vpeljave politik, (3) obravnava izjem BPEL na podlagi

uporabe pravil dogodek-pogoj-akcija (angl. Event Condition Action, krat. ECA), (4)

uporaba koncepta anotacij pri obravnavi izjem brez spreminjanja kontrolnega toka

poslovnega procesa in (5) uveljavljene razširitve jezika BPEL. V tretjem poglavju

predstavimo raziskovalno področje, kjer najprej predstavimo procesno usmerjene

informacijske sisteme, njihov kronološki razvoj in dejavnike za njihovo široko

uporabo. Sledi pregled in predstavitev jezikov za upravljanje poslovnih procesov

(tako za modeliranje kot za izvajanje). Podrobneje opišemo storitveno usmerjeno

arhitekturo in izvršljiv jezik BPEL, ki ga uporabimo pri vpeljavi naše rešitve. Na koncu

poglavja izvedemo še analizo vzorcev obravnave izjem in preverimo njihovo podporo

znotraj izvršljivih procesnih modelov.

V četrtem poglavju predstavimo rešitev, ki je zasnovana na podlagi formalnega

modela. Formalni model podamo s pomočjo matematičnega zapisa. V poglavju

izpostavimo in opišemo ključne probleme pri obravnavi izjem pri izvajanju izvršljivih

procesnih modelov BPEL. V petem poglavju predstavimo standardni razširitveni



mehanizem BPEL, ki ga nato tudi uporabimo pri preslikavi predlaganega formalnega

modela v izvršljiv jezik BPEL.

Učinkovitost predlagane rešitve preverimo v šestem poglavju. Ovrednotenje

učinkovitosti predlagane rešitve in analiza poteka v petih korakih: (1) zbiranje

procesnih modelov za ovrednotenje učinkovitosti predlagane rešitve, (2) priprava in

razširitev nabora procesnih modelov, (3) identifikacija in izbira metrik za merjenje

kompleksnosti procesnih modelov, (4) izvajanje meritev kompleksnosti procesnih

modelov in (5) analiza pridobljenih rezultatov.

V sedmem poglavju razpravljamo o zastavljenih hipotezah in podamo sklepe

obravnave. Doktorsko disertacijo s sklepom zaključimo v osmem poglavju, kjer

povzamemo rezultate in ugotovitve prejšnjih poglavij.



Pregled raziskovalnega področja 2

V doktorski disertaciji predstavimo formalni model obravnave izjem, s katerim

vpeljemo celovito obravnavo izjem v storitveno usmerjeno arhitekturo. Sorodna

znanstveno-raziskovalna dela, ki so predstavljena v tem poglavju, se osredotočajo na

obravnavo izjem znotraj sistemov za upravljanje poslovnih procesov. Dodatno

pozornost namenimo rešitvam, ki se navezujejo na izvajanje poslovnih procesov v

storitveno usmerjeni arhitekturi. V prvem delu smo izvedli pregled obstoječe

literature, v drugem pa opisali pomembna sorodna znanstveno-raziskovalna dela in

raziskave.

Pregled literature je potekal na področju obravnave izjem znotraj storitveno

usmerjene arhitekture. Povečana osredotočenost je bila na rešitve, ki vpeljujejo

mehanizme obravnave izjem znotraj jezika BPEL in uporabljajo razširitvene

mehanizme. Pregled literature je bil opravljen v skladu s smernicami in priporočili, ki

se uporabljajo pri sistematičnih pregledih literature znotraj računalniškega

inženiringa [21].

Namen pregleda literature je pridobitev informacij o aktualnosti, smernicah in

trenutnem stanju obravnave izjem poslovnih procesov. Pri tem smo si pomagali z

naslednjimi raziskovalnimi vprašanji:

RV1: Na kakšen način se obravnavajo izjeme, ki nastanejo pri izvajanju

primerkov poslovnih procesov?

RV2: Kakšni mehanizmi obravnave izjem znotraj SOA obstajajo?

RV3: Kateri razširitveni mehanizmi obstajajo pri obravnavi izjem jezika BPEL?

V nadaljevanju predstavimo sorodna znanstveno-raziskovalna dela s področja

obravnave izjem znotraj storitveno usmerjene arhitekture in jih primerjamo s

strategijami in rešitvami, ki so predstavljene v naši disertaciji. Splošne metode in

strategije obravnave izjem, ki so predstavljene v analiziranih sorodnih delih,

uporabljajo različne pristope, s katerimi avtorji poskušajo odpraviti pomanjkljivosti

in slabosti obravnave izjem v poslovnih procesih. Analiza sorodnih del je

predstavljena v naslednjih točkah:



Obravnava izjem kompozitnih storitev znotraj sistemov za izvajanje poslovnih

procesov.

Obravnava izjem poslovnih procesov na podlagi uporabe mehanizmov

vpeljave politik.

Obravnava izjem BPEL na podlagi uporabe pravil ECA.

Uporaba koncepta anotacij pri obravnavi izjem brez spreminjanja kontrolnega

toka poslovnega procesa.

2.1 Obravnava izjem kompozitnih storitev znotraj

sistemov za izvajanje poslovnih procesov

Nekateri avtorji [22, 23, 24, 25] uvrščajo splošne strategije in metode za obravnavo

izjem kompozitnih storitev v dve različni kategoriji obravnave izjem. Prva kategorija

obravnave izjem se osredotoča na izjeme, ki nastanejo pri klicu storitve. Za obravnavo

teh izjem se uporablja podvajanje storitve (angl. service replication) [26].

Načrtovalcem in razvijalcem procesa sta na voljo dve različni vrsti podvojevanja:

časovno in prostorsko [15, 27]. Časovno podvojevanje uporablja dodatni

komunikacijski čas, ki je na voljo za obravnavo izjem, medtem ko prostorsko

podvojevanje uporabi dodatne vire (npr. strojne in programske). Prostorsko

podvojevanje lahko dodatno klasificiramo na aktivno in pasivno podvojevanje [28].

Aktivno podvojevanje aktivira istočasno vse nadomestne storitve in za nadaljnjo

izvajanje uporabi odgovor storitve, ki je bil najprej podan. Pasivno podvojevanje pa

aktivira najprej primarnega kandidata in v primeru, da ta ni dosegljiv, nadaljuje z

zaporednim klicanjem ostalih storitev. Predlagana rešitev, ki vključuje podvojevanje,

ima pomanjkljivosti, saj ne predvideva, da imajo različni poslovni procesi različne

zahteve in toleranco do izjem [28]. Tako pogosto ne moremo enostavno kar ponoviti

ali podvojiti klic storitve.

V drugo kategorijo spadajo strategije in metode obravnave izjem, ki prekinejo

izvajanje procesnega toka, da ta preide v fazo obravnave izjem. Tudi ta rešitev ni

primerna, saj so nekateri sistemi (npr. zdravstveni, finančni, itd.) ključnega pomena

za poslovanje in si posledično ne morejo dovoliti, da bi se enostavno prekinili. Z



rešitvijo tega problema se je v svojem delu »Strategy-based Two-Level Fault Handling

Mechanism for Composite Service« ukvarjal Fang [25], ki je predlagal dvonivojski

mehanizem obravnave izjem. V raziskovalnem delu se osredotoča na spremembe

procesnega nivoja, ki temeljijo na razvoju kompozitne storitve v času izvajanja. Na ta

način lahko administratorji procesa obravnavajo izjemo brez potrebe po zaustavitvi

poslovnega procesa. Z metodami, ki jih je Fang vključil in opisal v svojem delu, se

dodatno izboljšajo sposobnosti obravnave izjem kompozitnih storitev, zmanjša se

tveganje za ustavitev sistema in izboljša zanesljivost kompozitnih storitev za

poslovne procese.

Večnivojski mehanizem obravnave napak so predhodno že obravnavali drugi avtorji,

in sicer: Alonso v delu »Enhancing the Fault Tolerance of Workflow« [23], ki opisuje

dva vidika obravnave izjem in za izboljšanje obravnave izjem predlaga organizacijo

procesov v tri kategorije, ter Hwang v delu »Grid Workflow : A Flexible Failure

Handling Framework for the Grid« [24], ki predlaga prilagodljivo ogrodje za

obravnavo izjem poslovnega procesa znotraj mrež ter se predvsem ukvarja z različno

granuliranostjo izjem. Večina mehanizmov obravnave izjem kompozitnih storitev, ki

so bili predlagani s strani avtorjev [22, 23, 24, 25], se osredotočajo na reševanje

problemov, ki nastanejo pri klicu spletne storitve. Način večnivojske obravnave izjem

celoviteje uporabimo tudi znotraj naše rešitve. V ta namen vpeljemo nove strategije

obravnave izjem, ki omogočajo izvajanje primerka poslovnega procesa tudi takrat, ko

pride do izjeme, ki je zgoraj omenjene rešitve ne znajo obravnavati. Pri tem imamo v

mislih predvsem strategije, ki omogočijo, da se izjeme le zabeležijo in da imajo

načrtovalci procesov možnost zakasnitvene obravnave izjem. Poleg tega pa

omogočimo ponovno uporabo definicij za večnivojsko obravnavo izjem.

2.2 Obravnava izjem poslovnih procesov na podlagi

uporabe mehanizmov vpeljave politik

Vpeljava logike obravnave izjem znotraj procesa je dolgotrajno opravilo. Razloga za to

sta dva. Prvič, združitev poslovne logike procesa in logike obravnave izjem otežuje

razvoj, vzdrževanje in posodabljanje obeh vrst logike. Drugič, BPEL uveljavlja izvedbo



kompenzacije pred prekinitvijo celotnega procesa. Rešitev tega problema je ločitev

logike obravnave izjem od poslovne logike procesa. S tem se je ukvarjalo že več

avtorjev [4, 28, 29], ki so potrdili pomen prilagodljivega in inovativnega pristopa

uporabe politik pri reševanju težav, ki nastanejo pri obravnavi spletnih storitev. Tang

et al. [4] so v delu »Policy driven and multi-agent based fault tolerance for Web

services« predlagali arhitekturni model za obravnavo izjem porazdeljenih spletnih

storitev, ki je zasnovan na agentih in ga vodijo politike. Predlagana metoda uporablja

vnaprej definirane politike, ki določajo ovrednotene funkcije specifikacije izjem in

ustrezne mehanizme za obravnavo izjem, nastalih pri izvajanju spletnih storitev.

Specifikacije napak in mehanizmi obravnave so zapisani v politiki, ki je zapisana v

jeziku XML. Agenti poskrbijo, da med izvajanjem spletne storitve zaznajo nastanek

izjeme in jo obravnavajo glede na definicijo politike. Pomanjkljivost predlaganega

pristopa se kaže v tem, da moramo za vsako posamezno spletno storitev definirati

svojo politiko. Posledično lahko pride do podvojenosti definicij pravil za obravnavo

izjem (npr. izjeme, do katerih pride pri izvajanju različnih spletnih storitev, moramo

obravnavati na podoben način), zaradi česar lahko nastopijo težave, ki jih omenimo v

poglavju 4.1. Naša disertacija prav tako naslavlja koncept uporabe politik pri

obravnavi izjem. Vendar v nasprotju z rešitvijo, ki jo je predlagal Tang, naša rešitev

omogoča uporabo iste politike znotraj celotnega poslovnega procesa in ne samo na

nivoju posamezne spletne storitve. Posledično lahko več domensko različnih spletnih

storitvah uporablja isto politiko.

Liu et al. [28] so v svojem raziskovalnem delu »FACTS: A Framework for Fault-

Tolerant Composition of Transactional Web Service« predstavili ogrodje za obravnavo

izjem transakcijskih spletnih storitev FACTS. Identificirajo niz visokonivojskih

strategij obravnave izjem in vpeljavo nove taksonomije transakcijskih spletnih

storitev, ki združuje obravnavo izjem in transakcijske tehnike. V svojem delu

pripravijo modul specifikacij in verifikacije, s katerima načrtovalcem storitev

omogočijo enostavno in pravilno konstrukcijo gradnikov za obravnavo izjem. Prav

tako predstavijo nov pristop obravnave izjem z ogrodjem FACTS, ki dodatno vsebuje

hibridni mehanizem EXTRA, ki obravnava izjeme in tehnike transakcij. Zanesljivost

kompozitnih storitev se izboljša z vpeljavo deklarativnega pristopa uporabe pravil

ECA. FACTS vpeljuje tudi ločitev programske logike normalnega procesnega toka in



logike obravnave izjem. Predlagan je tudi modul za samodejno implementacijo logike

obravnave izjem pri uporabi načrtovanja procesov BPEL. Čeprav rešitev podpira

izvršljiv procesni jezik BPEL, ima nekaj pomanjkljivosti, saj nekatere lastnosti EXTRA

ni mogoče neposredno podpreti z BPEL. Prvič, BPEL ne definira strategij obravnave

izjem z jasno semantiko za razliko od EXTRA, pri katerem je semantika ključni del

sestave. Drugič, čeprav BPEL lahko samodejno sproži operacije kompenzacije ali

prekinitve, s katerimi razveljavi učinek storitve, ne more preveriti, v kakšnem stanju

se bo kompozitna storitev prekinila.

Wang [29] je v delu »Policy-based exception handling for BPEL processes« predlagal

metodo uporabe politik pri načrtovanju poslovnih procesov, s katerimi se izboljša

zmogljivosti obravnave izjem BPEL. Razvil je nov opisni jezik (angl. Exception

Handling Policy Description Language for BPEL Processes, krat. EHPDL-P) in ogrodje

za obravnavo izjem znotraj procesov BPEL. Namen tega pristopa je zagotavljanje

prilagodljivega jezika in podpornega ogrodja za razvoj in vzdrževanje procesov BPEL,

katerih logika obravnave izjem temelji na uporabi politik. Načrtovalcem, ki pokrivajo

razvoj obravnave izjem procesov BPEL, je omogočena konfiguracija tako statičnih kot

dinamičnih politik s katerimi se izboljša prilagodljivost obravnave izjem procesov

BPEL. Konceptualni model EHPDL-P sestavljajo štirje različni nivoji: nastavitve

uporabe politik obravnave izjem (angl. Exception Handling Policy Set, krat.

EHPOLICYSET), politika obravnave izjem (angl. Exception Handling Policy, krat.

EHPOLICY), pravila obravnave izjem (angl. Exception Handling Rules, krat. EHRULE)

in akcije obravnave izjem (angl. Exception Handling Actions, krat. EHACTION).

EHPOLICYSET s pomočjo nastavljanja spremenljivk politike opisuje vodenje in

upravljanje obravnave izjem na najvišjem nivoju abstrakcije. EHPOLICY je skupek

pravil za obravnavo izjem. EHACTION definira skupino akcij (atomarne in

kompozitne akcije) s katerimi lahko operira EHRULE. Atomarne akcije predstavljajo

aktivnosti; ignore, retry, replace, skip, itd. Kompozitne akcije so skupek atomarnih

akcij in jih lahko predstavimo kot zaporedje (krat. EHSEQUENCE), tok (krat.

EHFLOW) in stikalo (EHSWITCH). Pristop uporabe politik predstavlja učinkovito

obravnavo izjem in ga uporabimo tudi v naši rešitvi. Vendar je Wang v ta namen

predstavil nov opisni jezik EHPDL-P, ki doda nove konstrukte pri implementaciji

poslovnih procesov. Dodatni konstrukti otežijo razvoj poslovnih procesov in naredijo



procesne modele manj berljive. V nasprotju s predlagano rešitvijo uporabimo pristop,

ki temelji na razširljivosti jezika BPEL in s tem ohranimo standardizacijo

implementacije poslovnih procesov. Še pomembneje pa je, da definiramo model, ki ni

omejen na BPEL, ampak ga je mogoče preslikati v poljuben izvršljiv procesni jezik.

Zeng et al. so v delu »Policy-Driven Exception-Management for Composite Web

Services« [30] predlagali novo ogrodje, ki na podlagi vodenega pristopa uporabe

politik pri obravnavi izjem bistveno poenostavi razvoj poslovnih procesov. Uporaba

njihovega pristopa načrtovalcem poslovnih procesov omogoča opredelitev politik na

deklarativen način. Ogrodje poskrbi, da se pred izvajanjem poslovnih procesov

politike obravnave izjem integrirajo z logiko poslovnega toka. Skladno s tem se

generirajo procesne sheme, ki so zmožne zaznave in obravnave izjem. Aktivnosti

obravnave izjem so definirane znotraj politik in vključene v BPEL s pomočjo

upravljavcev izjem in dogodkov. Velikokrat se zgodi, da vstavljanje aktivnosti

obravnave izjem znotraj upravljavcev izjem ne deluje učinkovito, čeprav se zdi takšen

pristop preprosta rešitev. Na primer nadomestna storitev se vstavi znotraj

upravljavca izjem, ki se nahaja v obsegu, z namenom izvedbe strategije »zamenjaj

storitev«. Problem, ki tukaj nastopi, je ta, da nadomestna storitev izgubi možnost

kompenzacije, saj specifikacija BPEL predvideva, da obseg znotraj katerega je prišlo

do izjeme, ne more biti kompenziran. Zato je potrebno, da se nadomestna storitev

definira znotraj drugega obsega, kar omogoča naša rešitev.

2.3 Obravnava izjem BPEL na podlagi uporabe pravil

ECA

Pravila dogodek-pogoj-akcija (angl. Event Condition Action, krat. ECA) tvorijo naravne

kandidate za sisteme, kjer je potrebna reaktivna funkcionalnost. Vsako pravilo je

okarakterizirano z dogodkom, ki lahko proži pripadajočo pravilo ECA. Ko se pravilo

proži in če je zahtevan pogoj izpolnjen, se izvrši akcija pravila. Pravila imajo jezike za

opis dogodkov, poizvedb, akcij in pogoje. Vsak posamezen jezik opisuje metapodatke

in ontologije, ki so povezane s procesnim strežnikom [31]. Številni avtorji [14, 29, 32,



33, 34, 35] so predstavili različna raziskovalna dela, v katerih opisujejo mehanizme

obravnave izjem BPEL, ki vključujejo pravila ECA.

Liu et al. so v raziskavi »A Declarative Approach to Enhancing the Reliability of BPEL

Processes« [35] predlagali deklarativen pristop obravnave izjem, katerega cilj je

povečanje zanesljivosti procesov BPEL. Rešitev, ki so jo predlagali, določa logiko

obravnave izjem z uporaba niza pravil ECA. Pravila ECA temeljijo na razširljivem

naboru vzorcev obravnave izjem in se z logiko poslovnega procesa integrirajo, še

preden se poslovni proces namesti na procesni strežnik. Opredeljeni vzorci

obravnave izjem procesa BPEL na podlagi vnaprej definiranih obnovitvenih akcij

omogočajo preslikavo posamezne obnovitvene strategije v proces BPEL. Za

preslikavo poskrbi generator, ki ustvari robusten poslovni proces, odporen na izjeme.

Nov procesni model je sestavljen iz začetnega procesnega modela BPEL in pravil ECA.

Avtorji so razvili tudi uporabniški vmesnik, ki načrtovalcem procesa pomaga pri

določevanju pravil ECA, ki se uporabijo pri obravnavi izjem določenega procesnega

modela. Predlagana rešitev ima pomanjkljivosti, saj ne vzpostavlja učinkovitega

mehanizma obravnave izjem, ki bi v času izvajanja primerka poslovnega procesa

omogočil dinamično izbiranje obnovitvenih strategij. Rešitev tudi ne rešuje in ne

obravnava situacij, kjer zunanja pravila obravnave ECA pridejo v stik s standardnim

mehanizmom obravnave izjem BPEL. Njihova rešitev vpeljuje koncept ločitve razvoja

logike obravnave izjem od načrtovanja logike poslovnega procesa. Predlagan koncept

ločitve obeh logik smo uporabili pri vpeljavi našega celovitega modela obravnave

izjem znotraj SOA.

Zaid et al. [14] so v raziskovalnem delu »Leveraging the BPEL Event Model to Support

QoS-aware Process Execution« predstavili pristop za dopolnitev standardnega

mehanizma obravnave izjem BPEL, kjer so lastnosti kvalitete storitev (angl. Quality of

Services, krat. QoS) in potrebne aktivnosti obravnave izjem deklarativno opredeljene

v obliki pravil ECA. Njihov glavni prispevek je izboljšava standardnega modela

dogodkov BPEL, ki je uporabljen pri kreiranju pravil ECA. S fleksibilnim in

deklarativnim pristopom, ki ga vzpostavijo znotraj predlaganega modela,

obravnavajo izjeme QoS, ki nastanejo pri izvajanju primerkov procesov BPEL, in v

času izvajanja na dogodke aplicirajo pravila ECA. Rešitev je ovrednotena z razširitvijo

procesnega strežnika BPEL. Predlagana rešitev se osredotoča samo na obravnavo



izjem QoS, kar je komplementarno z našo rešitvijo, v kateri naslavljamo celoten

seznam izjem BPEL, ki so opisane v poglavju 3.4.4.5

Vpeljava pravil ECA se ne uporablja samo na področju obravnave izjem poslovnih

procesov, ampak so bila uporabljena tudi na številnih ostalih področjih, kot so npr.

reaktivni sistemi [36, 37], tehnologija objavi/naroči [38] ali aktivno spremljanje

podatkov [39].

2.4 Uporaba koncepta anotacij pri obravnavi izjem

brez spreminjanja kontrolnega toka poslovnega

procesa

Modafferi in Conforti [40] sta v raziskovalnem delu »Methods for Enabling Recovery

Actions in WS-BPEL« za reševanja problemov, ki nastanejo pri obravnavi izjem BPEL,

predlagala uporabo anotacij (angl. annotations). Anotacije oziroma označbe vsebujejo

informacije o akcijah obnovitve stanja aktivnosti. Predlagan pristop v fazi načrtovanja

poslovnega procesa definira dodajanje novih označb v XML zapis procesa BPEL.

Dodane označbe se kasneje v fazi predprocesiranja odstranijo, saj označen proces

BPEL ni izvršljiv s strani standardnih strežnikov poslovnih procesov in je zato

potrebno predhodno vedno narediti preslikavo označenega procesa BPEL v

standarden procesni model BPEL. Uporaba predlaganega pristopa ne zahteva

sprememb procesnega strežnika BPEL, kar predstavlja določeno prednost. Kljub

temu ima omenjen pristop nekaj pomanjkljivosti, saj uporaba dodatnih označb pri

načrtovanju procesa predstavlja zamudno delo in je zelo nagnjeno k dodatnim

napakam.

2.5 Uveljavljene razširitve jezika BPEL

Jezik BPEL določa razširitveni mehanizem, ki znotraj jezika na standardiziran način

omogoča dodajanje novih razširitvenih konstruktov. V naši disertaciji omenjeni

razširitveni mehanizem uporabimo z namenom dodajanja novih možnosti obravnave

izjem znotraj mehanizma obravnave izjem. Z razširjanjem jezika BPEL so se v svojih



študijah ukvarjali že številni avtorji. Prav tako so dodatne razširitve znotraj jezika

BPEL vpeljali različni ponudniki programske opreme. Pri načrtovanju in modeliranju

poslovnih procesov lahko razširitve zajemajo le naslednje faze: načrtovanje procesa,

načrtovanje in izvajaje procesa ali samo izvajanje procesa znotraj izvajalnega okolja

[41]. Tabela 1 predstavlja nekatere razširitve jezika BPEL, ki so bile izvedene s strani

raziskovalcev in ponudnikov programske opreme.

Tabela 1: Predstavitev razširitev jezika BPEL.

Razširitev jezika BPEL Opis razširitve

BPEL Extensions for Sub-

Processes (krat. BPEL-SPE) [42]

Razširitev omogoča uporabo posameznega poslovnega procesa v

obliki podprocesa znotraj drugega poslovnega procesa. Življenjski

cikel podprocesa je povezan z življenjskim ciklom nadprocesa. Cilj

razširitve je zagotoviti večjo berljivost in ponovno uporabo

procesov.

BPEL Extension for People (krat.

BPEL4People) [43]

Razširitev obravnava človeške interakcije in vpeljuje nov tip

osnovnih aktivnosti, ki za implementacijo uporabljajo človeška

opravila (angl. human task). Omogoča specificiranje opravil

lokalno znotraj procesa ali uporabo opravil, ki so definirana izven

definicije procesa. Razširitev temelji na specifikaciji opravil (angl.

WS-HumanTask Specification) [44], ki definira opravila, vključno

z njihovimi lastnostmi in obnašanjem ter operacijami, ki so nujne

za upravljanje opravil.

AO4BPEL [45] Razširitev uvaja vidik aspektnih razširitev BPEL. Podobna je

razširitvi BPEL‘n‘Aspects [46] vendar dodatno omogoča

vključevanje izsekov kode (angl. BPEL snippets) v BPEL.

AdaptiveBPEL [47] Razširitev podpira razvoj diferencialnih in prilagodljivih procesov

BPEL in temelji na aspektno usmerjenih konceptih (angl. aspect-

oriented concepts).

C-BPEL [48] Razširitev vključuje kontekstne informacije in jih uporablja pri

kompoziciji storitev.

BPEL4Chor [49] Razširitev, ki se uporablja za modeliranje koreografije procesov.

Koreografija opisuje izmenjavo sporočil med množico sodelujočih

odjemalcev poslovnega procesa. BPEL4Chor opisuje obnašanje

posameznega udeleženca znotraj koreografije.

BPEL Extensions for Versioning

[50]

Razširitev podpira verzioniranje (angl. versioning) procesov in

partnerskih povezav (angl. partner links). Vpeljuje nove in

razširja obstoječe aktivnosti, vključno z aktivnostmi



Razširitev jezika BPEL Opis razširitve

<partnerLinks>, <receive>, <import> in <onMessage>. Razširitev

predlaga razširitvene spremenljivke za shranjevanje različic in

dodatno vpeljuje upravljavce različic.

BPEL for Java (krat. BPELJ) [51] Razširitev združuje programska jezika BPEL in Java. Namen

razširitve je zagotavljanje načina integracije programske kode

Java znotraj definicije procesa BPEL. Glavni učinek omenjene

razširitve je povečana uporabnost in udobnost pri načrtovanju

procesov BPEL.

BPEL data transitions (krat.

BPEL-DT) [52]

Rešitev razširi jezik BPEL s pomočjo podatkovnih transakcij in z

namenom obravnave velike količine podatkov. Omenjen pristop

pride v poštev predvsem pri ETL (Extract, Transform and Load),

ki temelji na orkestriranih spletnih storitvah, realiziranih z

jezikom BPEL.

Retry Scopes [53] Razširitev razširi jezik BPEL z novim obsegom, ki vsebuje

možnost ponovitve. Problem ponovnega zagona obsega je rešen z

eksplicitno aktivnostjo <restart>.

SH-BPEL [54] Razširitev predstavlja aktivnost neuspeha in obnovitve ter

izpostavlja izboljšano obravnavo izjem s strani procesnega

strežnika BPEL. Obravnava izjem vključuje zamenjavo storitev ali

proženje vključevanja uporabniškega posredovanja.

Extended WS-RM [55] Razširitev obravnava zanesljivost izvajanja primerkov poslovnih

procesov. Razširitev razširja standard WS-Reliable Messaging z

namenom vzpostavitve podpore večstranskih pogovorov,

specificiranih znotraj BPEL.



Predstavitev raziskovalnega 3področja

3.1 Predstavitev procesno umerjenih informacijskih

sistemov

Organizacije neprestano stremijo k izboljšanju učinkovitosti njihovega delovanja.

Eden izmed ključnih elementov za dosego tega cilja je razumevanje, kaj organizacije

počnejo in na kakšen način bi se lahko to izboljšalo. Pojem poslovni proces

predstavlja ključni element pri pridobivanju tega razumevanja. V preteklih letih so se

pojavili različni pristopi, ki temeljijo na izboljšanju poslovnih praks, kot sta prenova

poslovnih procesov (angl. Business Process Re-engineering, krat. BPR) [56, 57] in

izboljšanje poslovnih procesov (angl. Business Process Improvement, krat. BPI) [58].

V zadnjih letih se je zaradi nenehne navzočnosti poslovnih procesov znotraj

organizacij in potrebe po njihovem stalnem upravljanju (na enak način kot druga

poslovna sredstva) razvilo področje upravljanja poslovnih procesov [59]. BPM lahko

definiramo kot podporo izvajanju poslovnih procesov z uporabo metod, tehnik in

programske opreme za načrtovanje, izvajanje, spremljanje ter nadzorovanje

poslovnih procesov, ki vključujejo uporabnike, organizacijo, aplikacije, dokumente in

druge vire informacij [60]. Pojav informacijske tehnologije je spremenil delovanje

poslovnih procesov znotraj organizacij ter vplival na spremembe pri medsebojnem

sodelovanju in komunikaciji. Posledično se vedno več poslovnih procesov izvaja pod

nadzorom informacijskih sistemov, ki jih poganjajo procesni modeli [61]. Ena izmed

pomembnejših strategij vpeljave učinkovitega BPM je izbira in uporaba ustrezne

uveljavljene tehnologije. Trenutno obstaja širok spekter možnih programskih

tehnologij in metod, s katerimi lahko vpeljemo temeljit BPM. Kljub temu, da obstajajo

pomembne razlike med posameznimi možnostmi, vse temeljijo na podlagi modela

poslovnih procesov. Skladno s tem lahko to področje tehnologij označimo kot

procesno usmerjeni informacijski sistemi (angl. Process Aware Information Systems,

krat. PAIS).



PAIS predstavlja programsko opremo sistemov, katerih funkcija je upravljanje in

izvajanje operativnih procesov, vključujoč ljudi, aplikacij in informacijskih virov, ki

temeljijo na osnovi procesnih modelov [62]. Z drugimi besedami so PAIS sistemi, ki

poskrbijo za upravljanje in izvajanje poslovnih procesov.

Procesna usmerjenost predstavlja pomembno lastnost informacijskih sistemov. Tako

preusmeritev iz opravilno usmerjenih sistemov do PAIS prinaša številne prednosti

[63]:

Uporaba jasno definiranih procesnih modelov za učinkovito komunikacijo med

akterji.

Sistemi, ki temeljijo na procesnih modelih in ne programski kodi, imajo manj

težav pri vpeljavi sprememb (potrebno je spremeniti samo modele za podporo

razvoja poslovnega procesa).

Jasna predstavitev poslovnih procesov omogoča njihovo avtomatizacijo, kar

lahko vodi do večje učinkovitosti.

Jasna predstavitev poslovnih procesov omogoča njihovo lažje načrtovanje.

Omogočena je tudi podpora nadzoru izvajanja poslovnih procesov. Generično

spremljanje procesov in rudarjenje podatkov zagotovita koristne informacije o

izvajanju procesov. Pridobljene informacije pomagajo izboljšati upravljanje in

načrtovanje procesov.

3.1.1 Kronološki pregled razvoja jezikov za izvajanje poslovnih

procesov

Prvi informacijski sistemi (Slika 1) so se pojavili leta 1960 in so služili shranjevanju in

obnovi podatkov [63]. Kasneje, leta 1970, so se na tržišču pojavili poslovni sistemi za

avtomatizacijo pisarniškega poslovanja (angl. Office Automation Systems) z

namenom podpore vsakodnevnim podatkovnim procesom, kot sta obdelava

podatkov in kreiranje dokumentov. Začetnika sistemov za avtomatizacijo

pisarniškega poslovanja sta bila Ellis in Nutt, ki sta sodelovala pri razvoju prototipnih

sistemov Officetalk-Zero, Backtalk, Officetalk-P in OfficeTalk-D [64]. Sistemi za

avtomatizacijo pisarniškega poslovanja so poenostavili opravila za procesiranje z

informacijami (npr. sistemi za procesiranje teksta in slik, programi preglednic za



izvajanje izračunov, koledarji, itd.). Čeprav so sistemi za avtomatizacijo pisarniškega

poslovanja poenostavili opravila, so pogosto zapostavljali modeliranje poslovnih

procesov [65].

S pojavom interneta se je razvoj informacijskih sistemov osredotočil na komunikacijo

med uporabniki z uporabo elektronske pošte, video in telefonskih konferenc ter

izmenjavo informacij v različnih podatkovnih oblikah. Od takrat naprej se je obseg

komunikacije usmeril v različne smeri razvoja. Sistemi za skupinsko delo (angl.

Groupware Systems), ki so se pojavili v poznih osemdesetih, so nudili pomoč

skupinam, ki so medsebojno sodelovale z izmenjavo informacij [66].

Slika 1: Razvoj informacijskih sistemov [63].

Z uporabo avtomatizacije so organizacije ugotovile, da je imenovana tehnologija

precej pripomogla k lažjemu in učinkovitejšemu načrtovanju opravil, organizaciji

shranjevanja in dostopa do podatkov ter obdelavi elektronske pošte in dokumentov.

Na podlagi tega so organizacije postopoma začele preusmerjati pozornost od

podatkov k procesom. Ta preusmeritev je vplivala na razvoj procesno usmerjenega

pristopa in pojavili so se novi sistemi za upravljanje s poslovnimi procesi (angl.

Workflow Management Systems, krat. WFMS), ki so temeljili na BPM. BPM si

Usmeritev od podatkov do

procesov

Prilagodljivost, prožnost

Osredotočenost na storitve

Osredotočenost na procese

Osredotočenost na podatke

1975 1970 2005 2000 1995 1990 1985 1980

Komercialni sistemi za upravljanje poslovnih

procesov

Znanstveni sistemi za upravljanje

poslovnih procesov

Sistemi za avtomatizacijo

pisarniškega poslovanja



prizadeva za nenehno izboljševanje procesov s pomočjo spremljanja delovanja

primerkov poslovnih procesov ter definiranjem in kasneje izpopolnjevanjem različnih

kazalcev uspešnosti [67]. Procesi oziroma delovni tokovi omogočajo natančen opis

opravil, udeležencev procesa in virov. BPM vzpostavlja spremljanje kazalnikov med in

po izvajanju procesa. Postopek zbiranja podatkov za namene spremljanja procesa se

je razvil iz dnevnikov dogodkov, v katerih so zabeleženi dogodki, ki se zgodijo med

izvajanjem procesa [66].

Izvirno so WFMS bili namenjeni aplikacijam, ki so se ukvarjale s kompleksnim

procesiranjem slik [68]. Čeprav je na začetku razvoja WMFS bila uporaba precej

omejena, je bilo do leta 1997 razvitih več kot 200 različnih raziskovalnih in

komercialnih sistemov [65]. Medtem ko so nekateri sistemi bili procesno usmerjeni,

so bili ostali namenjeni predvsem upravljanju slik, dokumentov ter relacijskih

podatkovnih baz [69].

Zaradi velikih razlik med funkcionalnostmi, ki so jih nudili različni sistemi WFMS, je

konzorcij za upravljanje poslovnih procesov oziroma delovnih tokov (angl. Workflow

Management Coalition, krat. WfMC) [69] leta 1995 poskušal poenotiti terminologijo

znotraj domene sistemov za izvajanje delovnih tokov in posledično definiral skupino

splošno sprejetih standardov. Cilj WfMC je bil povečati stopnjo interoperabilnosti

rešitev in zmanjšati odvisnost organizacij od posameznega ponudnika sistemov. V ta

namen je WfMC definirala referenčni model poslovnih tokov (angl. Workflow

Reference Model). Referenčni model zagotavlja funkcionalni opis potrebnih

programskih komponent znotraj WFMS ter vpeljuje vmesnike za interakcijo WFMS z

zunanjimi sistemi.

Predstavljeni referenčni model je imel nekaj pomanjkljivosti (npr. ne zagotavlja

notacije za opis interakcij med distribuiranimi sistemi) in posledično v praksi ni

prinesel želenega učinka [59]. To vrzel sta zapolnila dva nova standarda: (1) BPEL

[70] in (2) WS-CDL (Web Services Choreography Description Language) [71]. WfMC

je z ozaveščanjem, da morajo osnovne procesne zahteve izpolnjevati in izboljšati

izvajanje poslovnih procesov, precej vplivala na razvoj procesno usmerjenih sistemov

[72]. BPEL predstavlja konvergenco predhodnih jezikov za modeliranje poslovnih

procesov WSFL in XLANG. IBM, BEA in Microsoft so avgusta leta 2002 s skupnimi

močmi razvili prvo verzijo jezika BPEL. Kasneje so se jim pridružili številni drugi



partnerji in marca 2003 je bila sprejeta nova verzija 1.1. Aprila 2003 je z namenom

standardizacije bil BPEL predložen organizaciji OASIS (Organization for the

Advancement of Structured Information Standards). V odgovor po standardizaciji se

je ustanovil poseben komite WSBPEL TC (Web Services Business Process Execution

Language Technical Committee) [73]. Leta 2007 je OASIS potrdil specifikacijo WS-

BPEL 2.0. [70].

3.1.2 Referenčni model poslovnih procesov

Referenčni model poslovnih procesov, ki je bil predlagan s strani WfMC, opredeljuje

pet skupin interoperabilnosti in komunikacijskih standardov, ki omogočajo

sodelovanje in interoperabilnost poslovnih procesov v uporabniškem okolju [69].

Slika 2 prikazuje predlagan referenčni model. Model je sestavljen iz sistemov za

izvajanje poslovnih procesov (angl. Workflow Enactment Service, krat. WEC) in petih

tipov vmesnikov, ki jih dopolnjujejo zunanja orodja in aplikacije.

Slika 2: Referenčni model poslovnih procesov [69].

WEC predstavlja jedro sistemov za upravljanje poslovnih procesov in je sestavljen iz

enega ali več procesnih strežnikov. Z zunanjimi orodji in aplikacijami komunicira

preko različnih programskih vmesnikov:

Sistem za izvajanje poslovnih procesov

Procesni strežniki

Procesni API in formati za izmenjavo

Orodja za definicijo procesov

Vmesnik 1

Drugi sistem za izvajanje poslovnih procesov

Vmesnik 4

Sprožene aplikacije

Odjemalci

Vmesnik 2 Vmesnik 3

Orodja za administracijo in spremljanje

Vmesnik 5



Vmesnik 1 – orodja za definicijo procesov. Določa splošen jezik za definicijo

poslovnih procesov, ki opisuje splošne procesne elemente in medsebojne

relacije. Uporabijo se lahko različna orodja za definiranje procesov, ki jih v

času izvajanja interpretirajo procesni strežniki. Uporabljen je generičen jezik

za definicijo poslovnih procesov (angl. Workflow Process Definition Language,

krat. WPDL).

Vmesnik 2 – odjemalci. Opisuje komunikacijo med procesnim strežnikom in

odjemalci (npr. uporabniško opravilo, preko katerega uporabniki upravljajo s

poslovnimi procesi).

Vmesnik 3 – sprožene aplikacije. Opisuje vmesnik, za proženje oddaljenih

aplikacij.

Vmesnik 4 – drugi sistemi za izvajanje poslovnih procesov. Zagotavlja

vmesnik za interakcijo enega poslovnega procesa z drugimi preko procesnega

strežnika. Omogočen je enoten pogled na definicije procesnih objektov in

atributov s strani vseh poslovnih procesov [69].

Vmesnik 5 – orodja za administracijo in spremljanje. Uporaba orodij za

administracijo in spremljanje poslovnih procesov omogoča analizo

parametrov procesa. Definiran je prikaz sledi procesa in s tem vpogled v

izvajanje primerka.

Vsi predlagani vmesniki so bili uporabljeni v praksi s strani različnih ponudnikov.

Čeprav Vmesnik 1 omogoča dober pregled nad elementi procesa znotraj sistemov za

upravljanje poslovnih procesov, ni dosegel širše uporabe [65]. Na podlagi tega je bila

pozneje predlagana različica XPDL v obliki XML. Omenjen pristop je bil bolje sprejet

in posledično se danes še vedno uporablja za prenos procesnih modelov med

različnimi produkti.

Vmesnika 2 in 3, ki se uporabljata za interakcijo procesa z odjemalci in drugimi

aplikacijami, sta v praksi bila precej bolje sprejeta in so jih tako v svojih orodjih

uporabili številni ponudniki. Vmesnik 4 je bil prav tako implementiran v številnih

orodjih. Čeprav predlagan referenčni model ni prinesel želenega učinka, je večina

vidikov, ki so definirani znotraj modela, zajetih tudi v definicijah konkurenčnih

standardov, kot so: BPML, BPEL in WS-CDL.



3.1.3 Življenjski cikel PAIS

Z vidika načrtovanja in implementacije sistemov PAIS življenjski cikel PAIS prikazuje

Slika 3. Kot je razvidno iz slike, je cikel sestavljen iz štirih faz, ki so: (1) načrtovanje

procesa, (2) implementacija procesa, (3) izvajanje procesa in (4) analiza procesa.

Slika 3: Življenjski cikel PAIS.

V fazi načrtovanja procesa, ki temelji na predhodni analizi zahtev procesa, se poslovni

procesi opredelijo, identificirajo, pregledajo, validirajo in predstavijo v obliki

procesnega modela [75]. S tem se definira načrt za prihodne primerke procesa.

Načrtovanje procesnih modelov je običajno podprto s strani orodij za procesno

modeliranje. V fazi implementacije procesa, se procesni model preoblikuje ali zgolj

dopolni v izvršljiv procesni model [4], npr.: XPDL ali BPEL, ki temeljita na osnovi XML.

Verificira se pravilnost procesa in v primeru ustreznosti se proces namesti na

procesni strežnik. Naslednja faza življenjskega cikla je izvajanje procesa, kjer se

proces izvaja na način, kot ga predhodno definira procesni model. Ta korak je podprt

tako s strani sistemov WfMS kot sistemov, ki temeljijo na storitveno usmerjeni

arhitekturi.

Po končani izvedbi procesa se lahko analizirajo ustrezne informacije, ki so bile zbrane

med izvajanjem procesa. V četrti fazi življenjskega cikla, fazi analiza procesa, se

najprej identificira probleme, ki so nastali pri izvajanju procesa, nato pa se izvedejo

možne rešitve za odstranitev teh težav. Informacije, ki se uporabijo pri analizi, so



zbrane s pomočjo sistemov WfMS ali s sledenjem primerku procesa (angl. audit trail).

Uporabijo se lahko tudi ostala namenska orodja za upravljanje s procesi. Rezultati

analize se nato uporabijo za preoblikovanje poslovnega procesa in tako ponovno

vstopimo v fazo načrtovanja procesa.

3.2 Upravljanje poslovnih procesov

Koncept poslovnih procesov je bil že opredeljen s strani številnih avtorjev [76, 77,

78]. Davenport [76] definira proces kot strukturiran, merjen nabor aktivnosti, ki

ponuja specifični izhod za določenega odjemalca. Proces tako predstavlja specifično

urejanje delovnih aktivnosti v okviru časa in prostora, z začetkom in koncem ter jasno

opredeljenimi vhodi in izhodi. Definicija opredeljuje značilnosti, ki jih mora vsebovati

proces. Imenovane značilnosti so dosežene s fokusiranjem na poslovno logiko

procesa (kako je delo opravljeno) in ne s fokusiranjem na perspektivo izdelka (kaj je

potrebno narediti). Hammer in Champy [77] sta za osnovo vzela definicijo, ki jo je

predlagal Davenport [76] in definirala proces kot zbirko aktivnosti, ki imajo en ali več

vhodov ter izhod, ki predstavlja vrednost za odjemalca. Predlagana definicija ni

popolna, saj ne poudarja vloge povezav med aktivnostmi in transformacijami, ki

potekajo v okviru procesa. Na podlagi tega je Johansson [78] definiral proces kot niz

povezanih aktivnosti, ki vhodno sporočilo transformirajo v izhodno. V idealnem

primeru transformacija doda vrednost vhodu in ustvari izhod, ki je učinkovitejši in

koristnejši za odjemalca. Poslovni proces je tako sestavljen iz niza aktivnosti, ki se

izvajajo v medsebojnem sodelovanju organizacijskega in tehničnega okolja. Skupek

teh aktivnosti realizira zadane poslovne cilje. Posamezni proces se uporablja s strani

ene organizacije, vendar pa lahko ta proces komunicira z ostalimi procesi, ki se

izvajajo v drugih organizacijah [79].

Upravljanje poslovnih procesov je opredeljeno kot niz upravljalnih aktivnosti in

tehnik za načrtovanje, implementiranje, vrednotenje ter izvajanje poslovnih procesov

[80]. Sistemi BPM so namenjeni usklajevanju poslovnih procesov z želenimi

poslovnimi rezultati in zagotavljajo podporo s strani sistemov IT. Sistemi BPM

poslovnim uporabnikom omogočajo, da v obliki grafov predstavijo delovanje



poslovnega procesa, t.j. v obliki modela poslovnih procesov. Model poslovnih

procesov je lahko kasneje implementiran s strani razvijalcev.

Edinstvenost BPM je predstavljena kot jasna ločitev poslovne logike procesa od ostale

aplikacijske kode, kar se izraža v obliki povečane produktivnosti, zmanjšanju

operativnih stroškov in izboljšanju agilnosti. Po uspešni vzpostavitvi BPM se

organizacije lahko hitreje odzivajo na spreminjajoče se, dinamične razmere in

izkoristijo priložnosti za konkurenčno prednost [81].

BPM pospešuje poslovno uspešnost in učinkovitost ter si prizadeva za prilagodljivost,

integracijo s tehnologijami in razvoj inovacij. Glavni cilj BPM je neprestano

izboljševanje procesov tako znotraj organizacije kot v sodelovanju z drugimi

organizacijami [82].

Pristop SOA zagotavlja velike prihranke, saj so aplikacije precej bolje usklajene s

poslovnimi procesi. Zmanjša se tudi čas, ki je potreben za vpeljavo sprememb pri

delovanju poslovnih procesov in omogoča večjo prilagodljivost sistemov IT.

Fleksibilnost SOA omogoča uveljavitev sprememb poslovnih procesov v okviru

majhnih korakov. IT lahko z uporabo prehodov korak za korakom (angl. step-by-step)

spremembam sledi brez odvečnega napora in časovnih zamud. To omogoča

enostavnejšo in naravnejšo evolucijo procesov iz stanja as-is (obstoječe stanje

poslovnih procesov znotraj organizacije) v stanje to-be (želeno stanje poslovnih

procesov znotraj organizacije). Optimizacija procesov s sistematičnim pristopom

korak za korakom omogoča zbiranje povratnih informacij o izvedenih spremembah in

spodbuja prilagajanje procesov dejanskim potrebam. Zaradi tega obstaja večja

verjetnost, da bodo procesi to-be dejansko bolj koristni in učinkoviti.

3.3 Jeziki za upravljanje poslovnih procesov

Jeziki za upravljanje poslovnih procesov predstavljajo pomembno vlogo pri

definiranju poslovnih procesov in dokumentiranju poslovnih zahtev ter so ključni del

sistemov PAIS. Tudi po več kot desetih letih prizadevanj po standardizaciji so

primarni jeziki BPM še vedno heterogeni v sintaksi in semantiki [83]. Za takšno stanje

sta kriva predvsem dva problema: (1) identificiranih je več različnih jezikovnih

konceptov BPM, ki jih je potrebno specificirati pri definiranju podatkovnega [84] in



kontrolnega toka [85], ter (2) paradigma predstavitve, ki se uporablja znotraj jezikov

BPM, predstavlja raznovrstnost [86]. Drugi problem je še posebej pomembno

obravnavati pri transformacijah med jeziki BPM (npr. transformacija med procesnimi

modeli v izvršljive procesne jezike). Jezike BPM lahko razdelimo v dve skupini, jezike

v obliki grafov in blokovno orientirane [86]:

Jeziki v obliki grafov. Kontrolni tok (vrstni red izvajanja aktivnosti) je

določen s povezavami, ki predstavljajo časovne in logične odvisnosti med

vozlišči. Posamezni jeziki v obliki grafov lahko imajo različne tipe vozlišč. V to

skupino jezikov spadajo Petrijeve mreže, EPC, YAWL, XPDL in BPMN. Jezik EPC

[87] dodatno vključuje funkcije, dogodke in konektor vozlišča. YAWL [88]

uporablja vozlišča v obliki grafov, ki predstavljajo opravila in pogoje.

Blokovno orientirani jeziki. Kontrolni tok je definiran z gnezdenjem

kontrolnih gradnikov, ki omogočajo sočasnost, alternative in zanke. Primer

tipičnega predstavnika blokovno orientiranega jezika predstavlja XLANG [89].

BPML [90] in BPEL [91], ki sta prav tako blokovno orientirana jezika, dodatno

vključujeta nekatere koncepte, ki temeljijo na teoriji grafov, kot so povezave

(angl. links). V jeziku BPEL se kontrolni gradniki imenujejo tudi strukturirane

aktivnosti. Ker je BPEL vsesplošno sprejet, ga v nadaljevanju uporabljamo kot

primer blokovno orientiranega jezika. Potrebno je upoštevati, da so lahko

koncepti, ki jih v nadaljevanju uporabljamo, primerni tudi za druge blokovno

orientirane jezike.

V praksi se pogosto izvajajo transformacije med blokovno orientiranimi jeziki in

jeziki v obliki grafov, saj so nekateri jeziki (npr. BPMN 1.x in EPC) uporabni samo za

modeliranje in ne podpirajo izvršljivih modelov procesnih jezikov (kot npr. BPEL).

Mnogo komercialnih orodij za upravljanje poslovnih procesov tako podpira uvoz in

izvoz različnih jezikovnih formatov. S tem je omogočena transformacija modelov v

izvršljiv procesni jezik in obratno. Veliko jezikov v obliki grafov nudi podporo

transformacije procesnega modela v BPEL z namenom podpore interoperabilnosti

[86]. Transformacija med BPEL in Petrijevimi mrežami je namenjena verifikaciji

modela, saj BPEL nima formalne semantike in posledično ne more biti ovrednoten

[92]. Za boljše razumevanje obnašanja poslovnega procesa s strani poslovnih



analitikov, ki so vajeni vizualne predstavitve, se BPEL pogosto transformira v jezik

EPC [93]. Potrebno je opozoriti, da se pri transformacijah med posameznimi jeziki

lahko srečamo z različnimi težavami, ki nastopijo zaradi naslednjih vzrokov: (1)

nekateri izvršljivi jeziki (npr. BPEL) nimajo formalne semantike in jih tako ne

moremo ovrednotiti [92] ter (2) nekateri jeziki v obliki grafov (npr. BPMN) podpirajo

nekatere kontrolne vzorce (npr. večkratno spajanje, arbitrarni cikli, diskriminator), ki

jih blokovno orientirani jeziki ne podpirajo [94].

3.3.1 Petrijeve mreže

Koncept Petrijevih mrež je leta 1962 v svoji doktorski disertaciji predstavil Carl Adam

Petri [95]. Petrijeve mreže predstavljajo grafično in matematično orodje za

modeliranje, ki se lahko uporablja znotraj številnih distribuiranih sistemov. Kot

grafično orodje se Petrijeve mreže lahko uporabljajo v namen vizualne predstavitve,

ki je podobna diagramom poteka [96].

Za uporabo Petrijevih mrež pri modeliranju poslovnih procesov obstaja več razlogov

[97]:

Formalna semantika (angl. formal semantics). Delovni tok, ki je določen s

Petrijevemi mrežami, ima jasno in natančno definicijo, saj je semantika

klasičnih Petrijevih mrež in njenih razširitev (barva, čas, hierarhija) jasno

formulirana.

Grafična predstavitev (angl. graphical nature). Ker so Petrijeve mreže

predstavljene v obliki grafov, so enostavne za učenje in komunikacijo s

končnimi uporabniki.

Izraznost (angl. expressiveness). Petrijeve mreže podpirajo vse gradnike, ki

so potrebni za modeliranje poslovnih procesov. Posledično je možno

modelirati vse usmerjevalne konstrukte, ki se pojavljajo v današnjih sistemih

za upravljanje s poslovnimi procesi.

Analiza (angl. analysis). Številne analitične tehnike lahko razpolagajo s

Petrijevemi mrežami. Tehnike se lahko uporabijo za izračun učinkovitosti

(npr. odzivni čas, čakalne dobe, itd).



Neodvisnost od ponudnika (angl. vendor independet). Petrijeve mreže

zagotavljajo neodvisno ogrodje za modeliranje in analizo poslovnih procesov.

Ne temeljijo na programskem paketu določenega ponudnika.

3.3.2 YAWL

V odgovor na omejitve, ki jih imajo Petrijeve mreže, je univerza Eindhoven University

of Technology s sodelovanjem univerze Queensland University of Technology razvila

nov jezik YAWL (Yet Another Workflow Language) [88]. Jezik YAWL je precej dobro

poznan v akademskem okolju. Uporablja se predvsem na področju verificiranja in

konfiguracij poslovnih procesov, obravnave izjem, vizualizacije in stroškovnega

ozaveščanja [98]. Ker je okolje YAWL zgrajeno na storitveno usmerjeni arhitekturi,

omogoča enostavno razširitev procesnega strežnika z razvojem storitev z dodano

vrednostjo. YAWL temelji na Petrijevih mrežah in je razširjen z dodatnimi konstrukti

(npr. uporaba večkratnih primerkov, napredne sinhronizacije sestavljenih opravil,

diskriminatorja, vzorca prekinitve), ki jih Petrijeve mreže ne podpirajo, in tako

omogoča lažje modeliranje kompleksnih procesnih modelov. Poleg tega YAWL

omogoča tudi hierarhično dekompozicijo in upravlja s kompleksnimi podatki [99].

YAWL ima formalno semantiko in ponuja grafično predstavitev za večino njegovih

konceptov [99]. Grafična notacija YAWL je za načrtovalce, domenske strokovnjakove

in interesne skupine enostavno razumljiva [98].

Čeprav se YAWL uporablja predvsem v akademskem okolju, se uporablja tudi v

industriji. Ključne prednosti uporabe jezika YAWL v industrijskem svetu so [100]:

Ekspresivna uporaba jezika YAWL, ki podpira vse potrebne gradnike za

implementacijo aplikativnih projektov.

Hitra izdelava prototipov.

Razširljivost in odprtokodnost jezika omogočata razvoj prilagojenih storitev.

Omogočen je razvoj prilagojenih uporabniških vmesnikov, ki organizacijam

omogoča konsistenten videz aplikacij.



3.3.3 EPC

Keller je leta 1992 v sodelovanju z inštitutom Institute for Information Systems in

Saarbruecken predstavil jezik EPC (Event-driven Process Chain), ki je bil namenjen

modeliranju poslovnih procesov in uporablja ogrodje ARIS (Architecture of

Integrated Information Systems) [99]. Proces EPC je dogodkovno usmerjen oz. temelji

na stanjih, kar pomeni, da je procesni model bolj osredotočen na stanja sistema in

njihova obnašanja, kot pa na interakcijo in komunikacijo med organizacijami [101].

Kontrolni tok procesa EPC je predstavljen v obliki usmerjenega grafa, ki vsebuje

funkcije, dogodke in logične operatorje (AND, OR, XOR) [102]. Funkcije predstavljajo

aktivnosti poslovnega procesa. Dogodki izražajo predpogoj (sprožilec) za funkcijo oz.

pogoj, ki signalizira zaključek funkcije. Z uvedbo logičnih operatorjev se lahko

dogodkovno usmerjene kontrolne strukture razširijo v kompleksen kontrolni tok, ki

opisuje ustrezne poslovne odločitve [99]. Preprosta in enostavno razumljiva notacija

modela EPC predstavlja splošno sprejeto tehniko za opisovanje poslovnih procesov.

Notacija EPC je bila kasneje razširjena z dodatnimi gradniki z namenom podpore

modeliranja podatkov, virov, časovne perspektive itd. Razširjena notacija se imenuje

razširjen EPC (angl. Extended EPC, krat. eEPC) [103].

3.3.4 WPDL in XPDL

Jezik WPDL je bil objavljen kot del vmesnika WfMC 1 in predstavlja obliko namenjeno

prenosu poslovnih definicij med posameznimi poslovnimi procesi [104]. Jezik XPDL

je predstavitev jezika WPDL v obliki sheme XML [105]. Definicija poslovnega procesa

WPDL je sestavljena iz ene ali več aktivnosti poslovnih procesov, ki so med seboj

povezane s prehodi. Prehodi predstavljajo kontrolni tok procesa. Aktivnost WPDL je

lahko atomarna ali kompleksna (npr. podproces) [106]. Ker WPDL temelji na notaciji

acikličnega grafa, je zanka predstavljena kot eksplicitna aktivnost (podproces, ki se

ponavlja, dokler ni izpolnjen izhodni pogoj). V gospodarstvu se jezika WPDL in XPDL

nista uveljavila in posledično nista prejela velike podpore s strani ponudnikov. Kljub

temu so nekateri odprtokodni sistemi (npr. Enhydra Shark, procesni urejevalnik

JaWE (Java Workflow Editor)) predstavili svoje modele v XPDL.



3.3.5 BPML

Iniciativa BPMI [59] (angl. Business Process Management Initiative) je kot standard

za modeliranje poslovnih procesov predstavila jezik BPML (Business Process

Modeling Language). BPML je podprt s strani mnogih priznanih organizacij, kot so:

Intalio, Oracle, Versata in SAP. Intalio je bil pobudnik za BPML in tako predstavlja

pomembno vlogo pri njegovi uveljavitvi. BPML je meta jezik za modeliranje poslovnih

procesov in zagotavlja abstraktno izvajanje modela za opisovanje sodelovanja in

transakcij [107]. Opredeljuje formalni model za opisovanje abstraktnih in izvršljivih

modelov poslovnih procesov in podpira upravljanje s podatki, obravnavo izjem in

semantiko. BPML nudi podporo sinhronim in asinhronim porazdeljenim

transakcijam, različnim spletnim specifikacijam (WS-Security, WS-Coordination in

WS-Transactions) ter se lahko uporabi za sestavne dele procesa že obstoječih

aplikacij. BPML podpira modeliranje kompleksnih poslovnih procesov s podporo

napredne semantike, kot so ugnezdeni procesi in kompleksne transakcije. Razširitve

BPML z dodatnimi gradniki (poslovna opravila, upravljanje opravil, človeške

interakcije itn.) so definirane v BPXL (Business Process Extension Layers) [107].

Glavni gradniki jezika BPML so aktivnosti, procesi, konteksti, lastnosti in signali

[108]:

Aktivnosti (angl. activites) so komponente, ki predstavljajo specifične

funkcionalnosti. Obstaja dva tipa aktivnosti: enostavne in kompleksne

aktivnosti, ki se razčlenijo na enostavnejše aktivnosti.

Proces (angl. process) predstavlja kompleksno aktivnost. Obstajata dva tipa

procesov: visokonivojski (neodvisen od drugih procesov) in ugnezdeni procesi

(izvajajo se z drugimi procesi).

Konteksti (angl. contexts) so pri BPML zelo pomembni in definirajo okolje za

izvajanje povezanih aktivnosti.

Lastnosti (angl. properties) se uporabljajo za izmenjavo informacij in se lahko

uporabijo samo znotraj konteksta.

Signali (angl. signals) se uporabijo za usklajevanje izvršljivih aktivnosti v

skupnem kontekstu.



3.3.6 XLANG

Microsoft je leta 2000 razvil jezik XLANG, ki predstavlja enega izmed prvih

orkestracijskih jezikov [107]. Razvit je bil z namenom doseči jasno ločevanje

procesov od implementacije. Uporabljen je znotraj ogrodja Microsoft BizTalk in ni

dokumentiran v celoti. Jezik XLANG je blokovno orientiran izvršljiv jezik ter vsebuje

osnovne kontrolne strukture kot so: zaporedja, pogojna stikala, zanke, paralelno

usmerjenost, časovne in zunanje prožilce [109]. Naslednik jezika XLANG je jezik

XLANG/s in specificira visokonivojske konstrukte, ki se uporabijo za definiranje in

izvajanje kompleksnih poslovnih procesov. Semantika XLANG/s je odsev semantike

BPEL. Microsoft ni znotraj BizTalk-a nikoli uporabil BPEL, ampak je nadaljeval z

uporabo XLANG/s in zato omogočil pretvorbo med XLANG/s in BPEL.

3.3.7 WSFL

Jezik WSFL (Web Services Flow Language) je prav tako eden izmed prvih

orkestracijskih jezikov. Razvit je bil s strani IBM v sklopu podpore tehnologij spletnih

storitev. WSFL je jezik v obliki grafov in temelji predvsem na konceptu kontrolnih

povezav [109]. WSFL podpira dva tipa kompozicij [107]: (1) izvršljiv procesni model,

ki definira natančne interakcije med storitvami v obliki izvršljivega procesa, in (2)

globalni model, ki definira splošne interakcije med storitvami in je abstrakten. WSFL

je precej podoben jeziku BPEL. Za razliko od Microsoft-a, ki ni nikoli sprejel BPEL, je

IBM prevzel BPEL kot glavni jezik za kompozicijo in zagotavlja popolno podporo v

njihovih različnih produktih, kot je npr. IBM Business Process Manager.

3.3.8 WSCL

Jezik WSCL (Web Services Conversation Language) [110] je bil razvit s strani podjetja

HP. Za razliko od prej omenjenih jezikov, ki so osredotočeni na orkestracijo, je WSCL

osredotočen na koreografijo storitev [107]. Zasnovan je bil za opis pogovorov na

nivoju organizacij (B2B) in javnih procesov ob podpori ustreznih storitev. WSCL

določa definicijo dokumentov XML in zaporedje izmenjave teh dokumentov znotraj

organizacije. WSCL ne predstavlja neposredne alternative jeziku BPEL, saj ne podpira



izvršljivih orkestracijskih procesov. WSCL je podoben abstraktnim procesom BPEL. S

strani ponudnikov WSCL ni bil dobro sprejet in zaradi tega ne predstavlja pomembne

vloge znotraj storitveno usmerjene arhitekture.

3.3.9 BPMN

Jezik BPMN (Business Process Model and Notation) je bil najprej razvit s strani

iniciative BPMI, ki pa se je kasneje, leta 2005, združila s skupino OMG (Object

Management Group). BPMN predstavlja standard za modeliranje poslovnih procesov

in je bil s strani načrtovalcev široko sprejet. BPMN se uporablja za pripravo

diagramov poslovnih procesov. Diagrami vsebujejo aktivnosti, opravila in njihovo

zaporedje. Za predstavitev logike poslovnih procesov je uporabljen koncept diagrama

poteka [107]. OMG navaja 76 ponudnikov, ki ponujajo orodja s podporo BPMN [111].

Ta uspeh temelji na dejstvu, da BPMN omogoča standardizirano notacijo v obliki

grafov, ki poslovnim analitikom nudi enostavno razumevanje poslovnih procesov ter

vzpostavlja preprosto komunikacijo med poslovnimi partnerji. Trenutna verzija je

BPMN 2.0, ki pa je z novimi funkcionalnostmi BPMN dvignil na novi nivo [112]:

Standardiziran metamodel in oblika serializacije (angl. serialization)

uporabnikom omogoča prenos poslovnih modelov med orodji različnih

ponudnikov.

Standardizirana izvršljiva semantika ponudnikom omogoča implementacijo

interoperabilnih strežnikov za izvajanje poslovnih procesov.

Diagram za izmenjavo uporabnikom omogoča izmenjavo informacij o

diagramu poslovnega procesa.

Razširjena notacija za interakcije med organizacijami (procesna koreografija)

omogoča nove primere uporabe, ki so avtomatizirano podprti s strani

procesnih orodij, ki vključujejo številne poslovne partnerje.

Podrobne preslikave med BPMN in BPEL predstavljajo uskladitev z

obstoječimi standardi.

Vpeljani so dodatni elementi (npr. neprekinjajoči dogodki (angl. non-

interrupting events), dogodkovni podprocesi (angl. event subprocesses), itd.)

za modeliranje poslovnih procesov.



Največja novost v BPMN 2.0 je specifikacija formalnega metamodela, ki definira tudi

izvršljivo semantiko. Tako se notacija BMPN 2.0 ne uporablja več samo za

modeliranje poslovnih procesov, ampak je možno procesne modele BPMN direktno

implementirati in izvajati. Pretvorba v drug izvršljiv jezik tako ni več potrebna.

Omenjena novost spodbuja sodelovanje med poslovnimi analitiki in tehničnimi

razvijalci sistemov ter omogoča agilnejši pristop od razvoja do končne uporabe

informacijskih sistemov.

3.3.10 WS-CDL

Jezik WS-CDL [113] (Web Services Choreography Description Language) je namenjen

specifikaciji koreografije sodelujočih storitev in naslavlja interoperabilnost med

storitvami. Z uporabo jezika WS-CDL lahko na način vsak z vsakim (angl. peer-to-

peer, krat. P2P) vzpostavimo medsebojne sodelovanje spletnih storitev z

opredelitvijo njihovega obnašanja [107]. Določijo se lahko sklopi pravil, ki

opredeljujejo, na kakšen način in v kakšnem vrstnem redu naj storitve medsebojno

sodelujejo. Takšen pristop zagotavlja prilagodljiv sistemski vidik poslovnega procesa.

Specifikacija koreografije WS-CDL je uporabna v primeru, ko poslovni partnerji želijo

preveriti, če so njihovi interni poslovni procesi opredeljeni na način, ki omogoča

njihovo sodelovanje v koreografiji. WS-CDL se lahko uporabi tudi pri generiranju

javnih vmesnikov (npr. uporaba abstraktnih procesov BPEL). Znotraj industrije WS-

CDL ni dobil veliko podpore in ga posledično večina ponudnikov ne podpira.

3.3.11 BPEL

BPEL je standardiziran jezik, s katerim opisujemo interakcije spletnih storitev z

izvršljivimi modeli poslovnih procesov [114]. Specifikacija BPEL je bila razvita s

strani tehničnega komiteja OASIS. BPEL je koreografijski jezik in temelji na

razširljivem označevalnem jeziku (angl. Extensible Markup Language, krat. XML).

Cilj procesa BPEL je ponovno uporabljiva definicija, ki je lahko nameščena na različne

načine v različnih scenarijih, medtem pa ohranja uniformirano obnašanje na

aplikacijskem nivoju. Jezik BPEL definira model in slovnico za opis obnašanja

poslovnega procesa, temelječega na interakciji med procesom in partnerji. Dodatno



BPEL definira, na kakšen način je sodelovanje večjega števila storitev koordinirano s

temi partnerji, da se doseže tako poslovni cilj, kot tudi stanje in logiko, ki je potrebna

za takšno koordinacijo. BPEL vpeljuje sistematični mehanizem za delo s poslovnimi

izjemami in procesiranjem napak. Še več, BPEL vpeljuje tudi mehanizem za

definiranje, kako morajo biti individualne ali kompozitne aktivnosti znotraj enote

dela kompenzirane v primeru, ko se pojavi izjema ali partner zahteva spremembo.

Za BPEL ni grafične predstavitve, saj je bila odločitev tehničnega komiteje, da je to

izven obsega standarda. Nekateri proizvajalci so razvili lastno notacijo. Te notacije

navadno temeljijo na dejstvu, da je večina konstruktov v BPEL blokovno orientiranih

(npr. sequence, while, pick, scope, itd.). To dejstvo omogoča neposredno

vizualno predstavitev BPEL procesov v obliki diagramov. Na drugi strani so nekateri

proizvajalci uporabili različne jezike za modeliranje procesov, največkrat BPMN kot

grafični jezik za predstavitev BPEL procesov.

BPEL se uporablja za modeliranje obnašanja tako izvršljivih kot abstraktnih procesov.

Modeliranje vključuje [115]:

Sekvenčenje procesnih aktivnosti, še posebej interakcij s spletnimi storitvami.

Korelacija sporočil in procesnih instanc.

Obnovitveno obnašanje v primeru napak in izjemnih situacij.

Obojestransko razmerje med procesnimi vlogami na osnovi spletnih storitev.

Slika 4 prikazuje časovno premico razvoja specifikacije BPEL. Prva zasnova BPEL je

bila leta 2002. Velika podjetja (IBM, Microsoft in BEA) so takrat skupaj izdelala

specifikacijo BPEL4WS 1.0 [116]. Dokument je predlagal orkestracijski jezik, ki se je

zgledoval po predhodnih variacijah, predvsem IBM WSFL in Microsoft XLANG

specifikacijah.



Slika 4: Časovni razvoj specifikacije BPEL.

Po izidu verzije 1.0 so se skupini pridružili novi sodelavci iz podjetij SAP in Siebel

Systems in skupaj so manj kot leto kasneje izdali BPEL4WS verzije 1.1 [117]. Nova

verzija je bila deležna precej več pozornosti in podpore s strani proizvajalcev, kar je

privedlo do obsežnejše komercialne rabe BPEL4WS v orodjih za orkestracijo. Tik

pred izdajo je bila omenjena verzija predložena tudi tehničnemu komiteju OASIS, kar

je omogočilo razvoj specifikacije v uraden odprti standard [114]. Trenutna verzija je

BPEL 2.0 in je evolucija prejšnje različice BPEL4WS 1.1 in prinaša nekatere novosti:

Nove aktivnosti: repeatUntil, validate, forEach, rethrow, extensionActivity,

compensateScope.

Preimenovane aktivnosti: switch/case v if/else, terminate v exit.

Uporaba inicializacije spremenljivk.

Uporaba XSLT za transformacijo spremenljivk.

bpws:doXslTransform ter Xpath dostop do podatkov.

Abstraktni proces je sintaktično in semantično pojasnjen.

Omogočena lokalna deklaracija messageExchange.

3.4 Izvajanje poslovnih procesov znotraj storitveno

usmerjene arhitekture

SOA predstavlja poslovno arhitekturo, kjer so aplikacije zasnovane na način, da se

zagotovi groba granuliranost storitev, ki so uporabljene s strani poslovnih procesov

ali drugih integracijskih aplikacij [118]. SOA zagotavlja tehnično infrastrukturo za

razvoj celovite (angl. end-to-end) podpore poslovnim procesom [73]. SOA dosega ta

2000 2001 2002 2003 2004 2005

XLang(Microsoft)

WSFL(IBM)

BPML 0.1(Intalio)

WSCI(BEA, SAP,

Intalio, Sun)

BPML 1.0(BPML.org)

BPEL4WS 1.0(IBM, BEA, Microsoft)

BPEL4WS 1.1(OASIS)

WSBPEL 2.0(OASIS)



cilj z izpostavitvijo sredstev IT znotraj organizacije v obliki ponovno uporabljivih

spletnih storitev, ki jih lahko sestavimo v procese. S tem je omogočena lažja

integracija in komunikacija med storitvami. SOA tako ponuja odprto platformo za

integracijo notranjih in zunanjih komponent programske opreme v obliki storitev v

enoten in večkratno uporaben pristop [119]. Arhitekti programske opreme s pomočjo

SOA razvijajo visokonivojsko integracijsko arhitekturo, ki uporablja splošne koncepte

za izmenjavo podatkov, informacij in poslovne logike med aplikacijami v

nadzorovanem transakcijskem načinu. Pri tem se uporablja storitveno vodilo in druge

podporne aplikacije, kot so stroji za izvajanje poslovnih pravil (angl. business rules

engines), registri in repozitoriji. SOA temelji na izmenjavi sporočil, ki jih definirajo

skupne sheme. SOA uporablja tudi poslovne dogodke, ki zagotavljajo alternativni

pristop k uresničitvi enega izmed najpomembnejših ciljev SOA – šibka sklopljenost.

Šibka sklopljenost predstavlja pristop, kjer sta odjemalec in storitev izolirana od

sprememb drug drugega in imata najmanjšo možno stopnjo medsebojne odvisnosti

[120]. SOA je tudi arhitektura za načrtovanje, avtomatizacijo in optimizacijo

poslovnih procesov. Poslovni procesi znotraj SOA temeljijo na kompoziciji storitev in

procesov in za implementacijo uporabljajo jezik BPEL. Poslovni procesi BPEL

omogočajo hiter razvoj, so fleksibilni in jih je enostavno spreminjati.

Naslednja pomembna lastnost arhitekture SOA je zmanjšanje semantičnega

razkoraka med poslovnimi modeli in izvršljivo programsko kodo. Zmanjšanje

razkoraka se je doseglo z zagotavljanjem skupnega jezika za poslovne uporabnike,

arhitekte IT in razvijalce. Skupen jezik je BPMN in predstavlja notacijo za modeliranje

poslovnih procesov. BPMN 1.x je le notacija za modeliranje poslovnih procesov in

posledično diagramov BMPN 1.x ni možno direktno implementirati in izvajati. Tako

so se pojavili postopki in orodja za avtomatično preslikavo diagramov BPMN v

izvršljiv jezik (npr. BPEL). S predstavitvijo BPMN 2.0, ki opredeljuje izvršljivo

semantiko konstruktov, je omogočena direktna implementacija in izvajanje

diagramov BPMN (oz. modelov, katere predstavljajo) [121]. Preslikava med BPMN 2.0

in BPEL tako ni več potrebna. Celotno arhitekturo SOA predstavlja Slika 5.



Arhitekturo SOA povezujejo naslednje tehnologije:

BPMN – modeliranje poslovnih procesov. BPMN 2.0 tudi za izvajanje poslovnih

procesov.

BPEL – izvajanje poslovnih procesov.

Storitve – predstavljajo poslovno logiko na različnih nivojih abstrakcije in so

osnovni gradniki SOA.

Storitveno vodilo (ang. Enterprise Service Bus, krat. ESB) – upravljanje

komunikacije med procesi in storitvami.

Register in repozitorij – registracija storitev in procesov za ponovno uporabo

in upravljanje.

Stroj za izvajanje poslovnih pravil (angl. rules engine) – centralno mesto za

hrambo in izvajanje poslovnih pravil.

Človeška interakcija – uporaba opravil.

BAM (Business Activity Monitoring) – spremljanje aktivnosti in procesov za

večjo uspešnost in optimizacijo procesa.



Slika 5: Storitveno usmerjena arhitektura [82].

3.4.1 Prednosti uporabe SOA pri izvajanju poslovnih procesov

Uporaba SOA pri izvajanju poslovnih procesov ima takojšne prednosti kot tudi (in morda

predvsem) dolgoročne koristi [122, 123]:

Razčlenitev kompleksnih problemov na manjše segmente omogoča

enostavnejše načrtovanje in implementacijo programske opreme.

Izboljšana uporaba programske opreme s pomočjo povečane ponovne

uporabljivosti obstoječih informacijskih virov.



Izboljšana prilagodljivost spreminjajočih se poslovnih procesov. Zaradi

pogostih sprememb so oddelki IT pod stalnim pritiskom. SOA omogoča

enostavnejšo prilagoditev na spremembe in zmanjša negativne učinke

sprememb.

Podvajanje podatkov v različnih podatkovnih bazah in sistemih je precej

pogosta težava obstoječih sistemov IT. SOA spodbuja združevanje podatkov in

uvaja pristop upravljanja matičnih podatkov (angl. Master Data Management,

krat. MDM), ki temelji na konceptih SOA, storitev in šibke sklopljenosti.

SOA spodbuja združevanje podvojenih funkcij znotraj obstoječih aplikacij.

Uporaba storitev izpostavlja sestavljene funkcionalnosti.

SOA omogoča dostop do procesov preko različnih kanalov (osebni računalnik,

dlančniki, tablice, mobilne naprave itd.)

Hitrejša prilagodljivost na spremembe in boljše prilagajanje poslovnega

procesa.

Izboljšana učinkovitost poslovnih procesov.

Boljše usklajevanje s poslovnimi zahtevami in zahtevami IT.

3.4.2 Tehnične komponente

3.4.2.1 Storitve

Pristop, ki ga uporablja SOA se zanaša na uporabo storitev, ki so sestavljene v proces.

Storitve so diskretni samostojni gradniki SOA, ki vsebujejo poslovno logiko. Poslovna

logika je izpostavljena skozi dobro definirane vmesnike. Storitve zagotavljajo

poslovne funkcije v obliki različnih aplikacij. Zelo pomembno je, da storitve

zagotavljajo poslovno vrednost, skrijejo podrobnosti implementacije in da so

avtonomne. Storitve so opisane z jezikom WSDL (Web Services Description

Language) in uporabljajo vhodna in izhodna sporočila, katera imajo obliko sheme

XML. Uspeh SOA temelji na storitvah in zmožnosti opredelitve teh storitev na

ustreznem nivoju abstrakcije, da se vzpostavi ponovna uporaba, t.j. da jih je mogoče

uporabiti pri implementaciji različnih procesov. S tega vidika lahko rečemo, da SOA

predstavlja celosten razvoj arhitekture IT. S tehničnega vidika se procesi in storitve

med seboj ne razlikujejo. Oboji izpostavljajo vmesnike, ki so opisani v jeziku WSDL. S



tem je omogočena ponovna uporaba storitev in procesov. Za implementacijo storitev

lahko uporabimo različne tehnologije. V večini primerih se uporabljajo spletne

storitve. Spletne storitve komunicirajo s pomočjo protokola SOAP Version 1.2, ki se

lahko uporablja nad enim od transportnih protokolov, npr. HTTP (Hypertext Transfer

Protocol).

3.4.2.2 Vmesniki storitev

Vmesnik storitve definira niz javnih podpisov delovanja in predstavlja pogodbo med

ponudnikom in odjemalcem storitev. Vmesnik je ločen od implementacije storitve, je

samo opisan in je neodvisen od platforme izvajanja. Uspešna opredelitev poslovnih

storitev zahteva osredotočenost na ustrezen nivo granuliranosti operacij. Najboljši

način modeliranja storitev SOA je uporaba grobe granulacije [124].

3.4.2.3 Sporočila

Sporočila opisujejo podatke, ki se izmenjujejo neodvisno od platforme sistema.

Storitve izmenjujejo le nujne podatke, kar se znatno razlikuje od objektnega in

sestavljenega pristopa.

3.4.2.4 Komunikacijski načini izmenjave sporočil

Odjemalci storitev lahko uporabijo sinhrono ali asinhrono komunikacijo. Pri

sinhronem načinu delovanja operacije storitev odjemalcu odgovorijo, ko je obdelava

podatkov končana. Odjemalec storitev mora na odgovor čakati tako dolgo, dokler se

ne zaključi izvajanje storitve. Sinhroni način komunikacije se običajno uporabi takrat,

ko pričakujemo, da bodo operacije storitev svojo obdelavo zaključile v kratkem času.

Pri asinhronem načinu komunikacije odjemalec ne čaka na odgovor storitve in

nadaljuje z izvajanjem. V določenih primerih lahko odjemalec zahteva, da mu storitev

vrne potrdilo o prejetju sporočila. Na tak način odjemalec ve, da je bila operacija

storitve uspešno zagnana. Če odjemalec kljub temu zahteva odgovor, se uporabi

povratni klic od storitve do odjemalca. V tem primeru se izvede korelacija sporočila.



3.4.2.5 Šibka sklopljenost

Šibka sklopljenost storitev se doseže z uporabo samoopisnih vmesnikov storitev,

grobo granulacijo, izmenjavo podatkovnih struktur in podporo sinhronim in

asinhronim komunikacijskim načinom. Šibko sklopljene storitve so storitve, ki

izpostavljajo le potrebne odvisnosti in zmanjšajo vse vrste umetnih odvisnosti. Ta

lastnost je še posebej pomembna, če so storitve podvržene pogostim spremembam.

Kadar pride do spremembe storitev, minimalna odvisnost zagotavlja, da so

spremembe na drugih storitvah prav tako minimalne. Takšen pristop izboljša

robustnost (sistemi postanejo odpornejši na spremembe) in spodbuja ponovno

uporabo storitev.

Šibka sklopljenost izključuje kakršnokoli znanje ali predpostavke o implementaciji

storitev, formatov in protokolov, ki se uporabljajo za interoperabilnost med

storitvami. Prav tako ne vključuje specifikacije platform, na kateri se izvajajo storitve

ponudnika in odjemalci. [125].

3.4.2.6 Kvaliteta storitev

Pri razvoju resnično ponovno uporabljivih storitev je pomembno, da se osredotočimo

na lastnosti kvalitete storitev (angl. Quality of Services, krat. QoS), kot so:

dosegljivost, zmogljivost, zanesljivost, varnost, učinkovitost in odpornost na izjeme

[126]. Zelo pomembno je, da upoštevamo QoS pri implementaciji velikih sistemov. Pri

spletnih storitvah so QoS zajete znotraj različnih specifikacij WS–* (npr. WS–Security,

WS–Addressing, WS–Coordination). Zagotavljanje visoke stopnje QoS predstavlja

izhodišče k sporazumu o ravni storitev (angl. Service Level Agreement, krat. SLA)

[107]. Ohranjanje visoke stopnje QoS ob prisotnosti različnih vrst izjem znotraj SOA

predstavlja zahtevno nalogo, saj takšni sistemi tečejo v dinamičnem in odprtem

okolju [127].

3.4.2.7 Storitveno vodilo

Storitveno vodilo (angl. Enterprise Service Bus, krat. ESB) upravlja komunikacijo med

storitvami in procesi. Primarna naloga ESB je ločitev aplikacij odjemalca od storitev,

kot prikazuje Slika 6.



Slika 6: Ločitev aplikacij odjemalca od storitev [128].

Enkapsulacija storitev z uporabo ESB pomeni, da aplikaciji odjemalca ni treba vedeti

ničesar o lokaciji storitve ali različnih komunikacijskih protokolih, ki jih storitev

uporablja. S tem je omogočena uporaba skupnih poslovnih storitev iz različnih

poslovnih procesov [129].

ESB zagotavlja naslednje funkcionalnosti [82, 130]:

Usmerjanje in sporočanje. V nekaterih primerih želimo usmeriti sporočilo k

točno določeni storitvi in takrat nam ESB lahko služi kot usmerjevalnik

sporočil. Takšno usmerjanje se običajno izvaja na podlagi determinističnih

poslovnih pravil ali pa temelji na vsebini sporočila, informacijah o uporabniku

(npr. kateri uporabnik je ustvaril sporočilo ali kateri uporabnik je prejemnik

sporočila) ali času kreiranja sporočila.

Komunikacijsko vodilo, ki široki paleti sistemov z vnaprej določenimi

adapterji omogoča lažjo integracijo.

Preslikava protokolov. Večina spletnih storitev uporablja protokol HTTP.

Protokol HTTP je nezanesljiv protokol in zaradi tega ni primeren za

implementacijo kritičnih aplikacij. ESB naslavlja probleme protokola HTTP in

zagotavlja zanesljiv mehanizem za komunikacijo med storitvami. Dodatno ESB

omogoča preslikavo protokolov iz enega v drugega (npr. SOAP to JMS (Java

Message Service) [131] in obratno). To je zelo pomembno, saj imajo nekateri

poslovni informacijski sistemi običajno komponente že razvite v različnih

tehnologijah. ESB tako s preslikavo protokolov omogoča poenostavljeno

integracijo sistemov.

Izvajanje transformacij med različnimi podatkovnimi shemami.

Praviloma vse storitve v nekem ekosistemu nimajo enake definicije shem

(razlike so predvsem med lastnimi in tistimi, ki so v lasti drugih organizacij).



Zaradi tega moramo velikokrat narediti transformacijo med vsebino XML

izhodne sheme ene storitve v vhod druge storitve. Za transformacije takšne

oblike običajno uporabimo XSLT (Extensible Stylesheet Language

Transformations), XPath ali XQuery. ESB omogoča pregledno transformacijo

vsebine shem neposredno na vodilu brez dodatnega preoblikovanja obstoječih

storitev ali procesov. Ta sposobnost je še posebej pomembna, kadar

nameščamo nove storitve ali procese.

Mehanizem za izvajanje procesov in poslovnih pravil.

Podpora vrsti standardnih vmesnikov. JMS, JCA (Java Connector

Architecture) [129], SOAP/HTTP ipd.

3.4.2.8 Spremljanje aktivnosti procesa

Spremljanje aktivnosti procesa nam pomaga pri odgovarjanju na vprašanje »Kje lahko

optimiziramo poslovne procese?«. Po končani vzpostavitvi končne verzije

avtomatiziranega poslovnega procesa nam SOA zagotavlja količinske podatke o

uspešnosti procesa, ki jih lahko uporabimo pri analiziranju. BAM zbira podatke o

časovnih okvirih, potrebnih za izvedbo različnih aktivnosti procesa. Na podlagi

pridobljenih podatkov se lahko generirajo poročila z agregiranimi vrednostmi

posamezne aktivnosti. Te informacije so precej koristne, saj se lahko uporabijo pri

ugotavljanju, katera aktivnost potrebuje največ časa za izvedbo. Na ta način

identificiramo tiste dele procesa, kjer z optimizacijo procesa pridobimo največ koristi.

Dodatno lahko BAM zagotavlja druge koristne informacije, kot so: koliko primerkov

procesa je aktivnih v določenem trenutku, kako dolgo v povprečju traja, da se

primerek procesa zaključi itd. S tem se zagotavlja skladnost z SLA in QoS [133].

3.4.2.9 Register in repozitorij

Zelo pomembna lastnost SOA je ponovna uporaba. Ponovna uporaba storitev pomeni,

da pri implementaciji procesa uporabimo obstoječo storitev, kolikokrat je le mogoče.

Vzpostavitev učinkovite ponovne uporabe storitev je težko doseči in moramo pri

njeni vzpostavitvi upoštevati naslednje:

Razvoj ponovno uporabljive storitve sprva traja dlje kot razvoj enonamenske

storitve, vendar se prednosti ponovne uporabe pokažejo komaj kasneje v



razvoju procesov, ko se storitev dejansko ponovno uporabi. Večkrat je storitev

ponovno uporabljena, bolj upravičljiv je njen daljši začetni razvoj.

Iskanje in identifikacija najbolj primerne storitve zahteva precej motiviranosti

s strani razvijalcev procesa. V nekaterih primerih je celo potrebno spremeniti

obnašanje storitve. V takih primerih morajo razvijalci vedeti, kdo uporablja

storitve in poznati meje, znotraj katerih se lahko opravijo spremembe.

Za dosego maksimalnega nivoja ponovne uporabe je koristno imeti neko vrsto

upravljanja (angl. governance) storitev. Postopki upravljanja storitev

zahtevajo obravnavo naslednjih informacij: »Kdo uporablja storitev?«

»Kolikokrat je bila storitev že uporabljena?« »Kakšna stopnja ponovne

uporabe je dosežena v procesu?« itd.

Ob upoštevanju zgoraj naštetih pogledov je implementacija procesa precej otežena.

Zato je potrebno, da imamo na razpolago seznam vseh storitev, ki so na voljo. Registri

in repozitoriji upoštevajo te poglede in se uporabljajo za registracijo storitev na

centralni lokaciji. Ko so storitve enkrat registrirane, imamo v času razvoja možnost

poiskati ustrezno storitev. Več metapodatkov vključimo za posamezno storitev, večje

možnosti pri iskanju želene storitev zagotavljata register in repozitorij.

Učinkoviti registri in repozitoriji imajo naslednje lastnosti:

Možnost kategoriziranja in razvrstitve storitev in procesov na osnovi ene ali

več klasifikacijskih shem. S tem poenostavimo poizvedovanje in omogočimo

lažje lociranje najprimernejše storitve ali procesa za ponovno uporabo.

Funkcije upravljanja, ki omogočajo opredelitev lastniških življenjskih ciklov

storitev ali procesov skupaj s pogoji prenosa iz ene faze življenjskega cikla v

drugo.

Nadzorovan dostop posameznih odjemalcev do ustreznih storitev. Takšen

nadzor dostopa lahko temelji na jeziku XACML (eXtensible Access Control

Markup Language). Trenutna verzija je XACML 3.0 [134].

Uporabniški, administrativni in programski vmesnik.



3.4.2.10 Stroj za izvajanje poslovnih pravil

Poslovna pravila predstavljajo pomemben del vsakdanjega poslovanja. Poslovna

pravila so pogosto kodirana neposredno v različne aplikacije in so tesno povezana z

implementacijo sistemskih aplikacij. Izkušnje kažejo, da se poslovna pravila lahko

pogosto spreminjajo. Sprememba teh pravil zahteva modifikacijo aplikacij, kar lahko

predstavlja zelo težko delo. Vsaka modifikacija aplikacije zahteva testiranje, kar še

dodatno oteži izvajanje sprememb. Pri tem lahko naletimo na nepričakovane

rezultate izvajanja aplikacij, česar pa si razvijalci ne želijo.

Poslovna opravila se pogosto uporabljajo pri implementaciji poslovnih procesov.

Pristop SOA loči poslovna pravila od izvršljive programske kode (npr. BPEL) in jih

shrani v centralnem delu (angl. rules engine), kjer:

Se poslovna pravila lahko ponovno uporabijo pri implementaciji različnih

storitev, procesov in aplikacij.

Uporabniku prijazni vmesniki omogočajo spreminjanje poslovnih opravil.

Pomembno je, da poslovna pravila vpeljemo že na začetku razvoja poslovnih

procesov, saj kasnejša vpeljava poslovnih pravil otežuje implementacijo poslovnih

procesov.

3.4.3 Kompozicija spletnih storitev znotraj storitveno usmerjene

arhitekture

BPEL trenutno predstavlja najbolj priznan standard na področju kompozicije spletnih

storitev, saj izpolnjuje naslednje glavne zahteve, ki so pomemben sestavni del

poslovno procesnih storitev:

Fleksibilnost. Eden izmed najpomembnejših vidikov predstavlja fleksibilnost

jezika. Fleksibilnost se lahko doseže z jasno ločitvijo logike kontrolnega toka

poslovnega procesa od klicanih spletnih storitev. Ločitev je dosežena preko

orkestracijskega okolja, ki obravnava celoten kontrolni tok. S to fleksibilnostjo

lahko organizacije enostavno spremenijo in preoblikujejo storitve glede na

spremembe poslovnih zahtev.



Osnovne in strukturirane aktivnosti. Orkestracijski jezik mora podpirati

aktivnosti obvladovanja semantike kontrolnega toka in komunikacijo s

spletnimi storitvami. Osnovne aktivnosti predstavljajo komponente, s katerimi

vzpostavimo interakcijo poslovnega procesa z zunanjimi komponentami. V

nasprotju z osnovnimi aktivnostmi strukturirane aktivnosti upravljajo celotni

kontrolni tok procesa in določajo vrstni red izvajanja aktivnosti.

Rekurzivna kompozicija. Posamezen poslovni proces lahko sodeluje z več

spletnimi storitvami. Lahko pa je tudi sam poslovni proces izpostavljen kot

spletna storitev. To omogoča združevanje poslovnih procesov na višjem

nivoju.

Obstojnost in korelacija. Sposobnost ohranjanja stanja zahtev spletnih

storitev predstavlja pomemben pogoj, še zlasti takrat, ko so v uporabi

asinhrone spletne storitve. Arhitektura mora zagotavljati mehanizem za

upravljanje obstojnosti podatkov in korelirati zahteve z namenom

vzpostavitve višjega nivoja komunikacije.

Obravnava izjem in transakcije. Dolgo trajajoče orkestrirane spletne

storitve morajo biti sposobne obravnave izjem in transakcijske integritete.

3.4.4 WS – BPEL

Orkestracijski jezik BPEL je v praktičnem pomenu vrhnja plast jezika WSDL. WSDL

vsebuje informacije za definiranje tipa sporočila (angl. message type) in vrat (angl.

port type), ki predstavlja operacije, podprte s strani storitve, in načine medsebojnega

sodelovanja. Te informacije so nato uporabljene znotraj BPEL, s katerim

specificiramo procesni tok. Dokument BPEL temelji na XML in se lahko izvede znotraj

orkestracijskega strežnika, ki je osrednji koordinator. Strežnik obdela dokument

BPEL in sproži izvajanje spletnih storitev v določenem vrstnem redu. Poslovni proces

dodatno samega sebe predstavlja kot storitev in se lahko proži na podoben način kot

ostale spletne storitve. Struktura procesa BPEL 2.0 je definirana z naslednjo shemo

XML [135] (Izsek 1):

Izsek 1: Struktura procesa BPEL 2.0.

<process name="NCName" targetNamespace="anyURI" queryLanguage="anyURI"?

expressionLanguage="anyURI"? suppressJoinFailure="yes|no"?

exitOnStandardFault="yes|no"?

xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable">

<extensions>?

<extension namespace="anyURI" mustUnderstand="yes|no" />+

</extensions>

<import namespace="anyURI"? location="anyURI"? importType="anyURI" />*

<partnerLinks>?

<partnerLink name="NCName" partnerLinkType="QName"

myRole="NCName"? partnerRole="NCName"? initializePartnerRole="yes|no"?>+

</partnerLink>

</partnerLinks>

<messageExchanges>?

<messageExchange name="NCName" />+

</messageExchanges>

<variables>?

<variable name="BPELVariableName" messageType="QName"?

type="QName"? element="QName"?>+

from-spec?

</variable>

</variables>

<correlationSets>?

<correlationSet name="NCName" properties="QName-list" />+

</correlationSets>

<faultHandlers>?

<catch faultName="QName"? faultVariable="BPELVariableName"?

( faultMessageType="QName" | faultElement="QName" )? >*

activity

</catch>

<catchAll>? activity </catchAll>

</faultHandlers>

<eventHandlers>?



<onEvent partnerLink="NCName" portType="QName"? operation="NCName"

( messageType="QName" | element="QName" )? variable="BPELVariableName"?

messageExchange="NCName"?>*

<correlations>?

<correlation set="NCName" initiate="yes|join|no"? />+

</correlations>

<fromParts>?

<fromPart part="NCName" toVariable="BPELVariableName" />+

</fromParts>

<scope ...>...</scope>

</onEvent>

<onAlarm>*



( <for expressionLanguage="anyURI"?>duration-expr</for> |

<until expressionLanguage="anyURI"?>deadline-expr</until> )?

<repeatEvery expressionLanguage="anyURI"?>

duration-expr

</repeatEvery>?


</onAlarm>

</eventHandlers>

activity

</process>



Proces BPEL je tako sestavljen iz [1, 136]: (1) nabora partnerjev, ki so vključeni v

proces, in njihovih vlog, (2) spremenljivk, (3) mehanizma za upravljanje dogodkov

(t.i. eventHandlers) in izrednih situacij (t.i. faultHandlers in compensatonHandler) ter

(4) poslovnega procesa, ki vsebuje aktivnosti, ki se morajo izvesti za izpolnitev cilja.

Aktivnosti dejansko zagotavljajo pošiljanje sporočil (osnovne aktivnosti), sočasnost in

sinhronizacijo komunikacije (strukturirane aktivnosti) [135]:

Proces. Proces (aktivnost <proces>) je osnovni vsebnik oziroma tako

imenovani korenski element procesa BPEL.

Povezave s partnerji. Povezave s partnerji (aktivnost <partnerLinks>)

predstavljajo storitve, s katerimi sodeluje poslovni proces. Vsaka povezava

<partnerLink> je poimenovana z atributom name (se uporabi pri

sklicevanju) in tipizirana z atributom partnerLinkType. Proces ima lahko

več povezav s partnerji istega tipa. Povezavi s partnerji s pomočjo atributov

myRole ali parterRole definiramo operacijo, ki se izvede ob klicu

povezave s partnerjem.

Spremenljivke. Spremenljivke (aktivnost <variables>) so konstrukti, ki

zagotavljajo mehanizem za shranjevanje sporočil, ki jih proces običajno

izmenjuje s partnerji, in predstavljajo del stanja poslovnega procesa . Dodatno

lahko spremenljivke tudi shranjujejo podatke, ki služijo izključno ohranjanju

stanja poslovnega procesa in niso namenjeni pošiljanju partnerjem.

Specifikacija BPEL opredeljuje tri vrste spremenljivk:

o WSDL message type.

o XML Schema type.

o XML Schema element.

Skladno s tem mora vsaka spremenljivka (<variable>) vsebovati natančno

enega izmed atributov messageType, type ali element, ki definirajo njeno

strukturo.

Spremenljivke so lahko definirane v globalnem obsegu procesa in jih

imenujemo globalne spremenljivke, ali pa pripadajo posameznim obsegom

(aktivnost <scope>) in jih imenujemo lokalne spremenljivke. Vsaka

spremenljivka je vidna samo v obsegu, v katerem je definirana. V primeru, da



so lokalne spremenljivke nižjih obsegov poimenovane identično kot tiste iz

višjih obsegov, jih te prekrijejo.

Korelacijska množica. V BPEL je korelacija odvisna zgolj od deklarativnih

lastnosti sporočila. Te lastnosti so polja znotraj sporočila, ki so identificirana s

poizvedbo, za kar pa je nujno, da je struktura sporočila natančno definirana,

npr. s shemo XML. BPEL naslavlja korelacijske scenarije z zagotavljanjem

deklarativnih mehanizmov za specificiranje korelacijskih skupin operacij

znotraj procesne instance. Nabor korelacijskih žetonov je definiran kot nabor

lastnosti, ki si jih delijo vsa sporočila v neki korelacijski skupini. Ta nabor

žetonov imenujemo korelacijska množica oziroma <correlationSet>.

Aktivnost <correlationSet> lahko deklariramo znotraj procesa ali obsega

na podoben način kot deklariramo spremenljivko. Korelacijska množica

procesa je na začetku procesa v neinicializiranem stanju, kot tudi vse

korelacijske množice obsegov ob začetku le-teh. Inicializacija korelacijske

množice je možna samo enkrat in zadrži to vrednost, ne glede na kakršnekoli

posodobitve spremenljivk.

Obseg (aktivnost <scope>) je konstrukt, ki zagotavlja kontekst, ki vpliva na

izvajalno obnašanje vsebovanih aktivnosti. To obnašanje vključuje

spremenljivke, povezave s partnerji, izmenjavo sporočil, korelacijske množice

ter upravljavce izjem, dogodkov, kompenzacij in prekinitev [137]. Vsak obseg

zahteva primarno aktivnost, ki definira njegovo normalno obnašanje. Ta

primarna aktivnost pa je lahko tudi kompleksna strukturirana aktivnost z

gnezdenimi aktivnostmi do poljubne globine. Konteksti, definirani s

konstruktom <scope> so lahko hierarhično gnezdeni, pri čemer je izvorni

kontekst definiran s konstruktom <process>. Konstrukt <scope> je tako

glavna strukturirana aktivnost za hierarhično predstavitev posameznih delov

procesa BPEL. Konstrukta <process> in <scope> si torej delita sintaktične

konstrukte z isto semantiko, vendar pa se razlikujeta po tem, da prvi ne

predstavlja aktivnosti, zaradi česar ne more vsebovati standardnih elementov

in atributov. Prav tako na konstrukt <process> ne moremo povezati



obdelovalcev kompenzacij in prekinitev in mu ne moremo definirati atributa

isolated.

3.4.4.1 Osnovne aktivnosti

Osnovne aktivnosti BPEL (<invoke>, <receive>, <reply>, <wait>, <exit>,

<assign>, <throw>, <compensate> in <empty>) so tiste, ki opisujejo elementarne

korake obnašanja procesa [135]:

Klic (aktivnost <invoke>). Aktivnost <invoke> služi klicanju spletnih

storitev, ki jih nudijo ponudniki storitev. Tipična uporaba vključuje proženje

operacije na storitvi, kar smatramo kot osnovno aktivnost. Aktivnost

<invoke> lahko vključuje druge aktivnosti, vsebovane v upravljavcih

kompenzacij in izjem. Operacije so lahko dvosmerne (angl. request-response)

ali enosmerne (angl. one-way). BPEL uporablja v obeh primerih enako

osnovno sintakso, vendar so v primeru dvosmerne operacije na voljo nekatere

dodatne opcije. Enosmerna operacija zahteva samo atribut inputVariable,

saj odgovor ni predviden, dvosmerna operacija pa zahteva tudi atribut

outputVariable. Namesto omenjenih atributov lahko vhodne in izhodne

spremenljivke definiramo tudi s pomočjo elementov fromPart in toPart.

Prejem (aktivnost <receive>). Aktivnost <receive> določa aktivnost

<partnerLink>, ki vsebuje atribute myRole, portType in operation, s

katerimi definira operacije, ki jih partnerji lahko prožijo. Aktivnost

<receive> opredeljuje atribut variable, ki določa spremenljivko, v katero

se shrani prejeto sporočilo. Podobno kot pri aktivnosti <invoke> lahko tudi

pri aktivnosti <receive> atribut variable nadomestimo z elementom

fromPart. Aktivnost <receive> igra posebno vlogo v življenjskem ciklu

poslovnega procesa, saj poleg aktivnosti <pick> edini omogoča način za

kreiranje nove instance procesa z atributom createInstance nastavljenim

na yes. Takšno aktivnost imenujemo začetna aktivnost (»start

activity«).

Odgovor (aktivnost <reply>). Aktivnost <reply> služi pošiljanju odgovora

na zahtevo, ki je bilo predhodno preko vhodnega sporočila prejeto s pomočjo



aktivnosti (npr. aktivnost <receive>). Aktivnost <reply>je tako smiselna le

v primeru dvosmerne operacije. Aktivnost <reply> vsebuje atribut

variable, ki se sklicuje na spremenljivko, ki vsebuje podatke namenjene za

pošiljanje partnerju v okviru odgovora na zahtevo.

Prirejanje (aktivnost <assign>). Aktivnost <assign> je namenjena

kopiranju podatkov iz ene v drugo spremenljivko in konstruiranju ter

vstavljanju novih podatkov s pomočjo izrazov. Motivacija za uporabo slednjih

je predvsem izvajanje preprostih preračunavanj (npr. povečevanje zaporednih

številk). Izrazi operirajo nad spremenljivkami, lastnostmi in konstantami ter

kreirajo nove vrednosti. Aktivnost <assign> lahko uporabimo tudi za

kopiranje referenc na končne točke iz ene v drugo povezavo s partnerjem.

Dodatno lahko vključuje tudi razširjene operacije, definirane v obliki

razširitvenih elementov v okviru drugih imenskih področij za manipulacijo

podatkov. Vsaka aktivnost prirejanja vsebuje eno ali več elementarnih

operacij.

Proženje izjem (aktivnost <throw>). Aktivnost <throw> je namenjena

eksplicitnemu signaliziranju interne izjeme v poslovnem procesu. Aktivnost

<throw> vsebuje atribut faultName za specificiranje imena izjeme, opcijsko

pa lahko vsebuje tudi atribut faultVariable, ki specificira ime

spremenljivke, v kateri so shranjeni podrobni podatki o izjemi. BPEL ne

zahteva, da pred uporabo aktivnosti proženja izjem definiramo imena izjem.

Prazna aktivnost (aktivnost <empty>). Velikokrat se pojavi potreba po

aktivnosti, ki ne naredi ničesar, npr. ko želimo ujeti in zatreti izjemo. Takrat v

poštev pride prazna aktivnost <empty>. Še en primer uporabe te aktivnosti

vključuje zagotavljanje točke sinhronizacije v toku.

Aktivnost razširitve (aktivnost <exstensionActivity>. Proces BPEL ima

možnost vključevanja novih aktivnosti, ki niso definirane v osnovni

specifikaciji. To je omogočeno z umestitvijo novih aktivnosti v konstrukt

<exstensionActivity>. Te aktivnosti imenujemo razširitvene aktivnosti.

Konstrukt <exstensionActivity> mora vsebovati en sam element,



kvalificiran z ustreznim imenskim prostorom. Razširjena aktivnost je lahko

tudi strukturirana in vsebuje druge aktivnosti.

Izhod (aktivnost <exit>). Aktivnost <exit> je namenjena takojšnjemu

končanju izvajanja primerka poslovnega procesa. Vse takrat izvajajoče se

aktivnosti so v trenutku prekinjene brez kakršnegakoli vključevanja

obravnave prekinitev, izjem ali kompenzacij.

Ponovno proženje izjem (aktivnost <rethrow>). Aktivnost <rethrow> je

namenjena upravljavcem izjem, da lahko ponovno prožijo izjemo, ki so jo

predhodno ujeli. Aktivnost je lahko uporabljena zgolj v okviru upravljavca

izjem, hkrati pa ignorira spremembe v podatkih o izjemi. Čeprav morda

upravljavec izjem po ujetju le-te manipulira z vsebovanimi podatki, se bodo ob

uporabi aktivnosti <rethrow> ponovno posredovali originalni podatki, ki so

bili vsebovani v prvotnem opisu izjeme.

3.4.4.2 Strukturirane aktivnosti

Strukturirane aktivnosti so namenjene upravljanju toka procesa in imajo možnost

rekurzivne vključitve drugih osnovnih ali strukturiranih aktivnosti. Strukturirane

aktivnosti so lahko na arbitrarni način ugnezdene in združene, kar omogoča

predstavitev kompleksnih struktur procesa BPEL [138]. Opisujejo zaporedje, v

katerem se izvede množica aktivnosti. Definirajo kreiranje procesa in strukture, ki

izražajo upravljavske vzorce, obravnavo izjem in zunanjih dogodkov, ter koordinirajo

izmenjavo sporočil med procesnimi instancami [135]:

Zaporedje (aktivnost <sequence>). Aktivnost <sequence> vsebuje eno ali

več aktivnosti, ki se izvajajo v leksičnem zaporedju, kot se pojavijo znotraj

aktivnosti. Zaporedje je končano takrat, ko se znotraj aktivnosti <sequence>

zaključi zadnja zaporedna aktivnost.

Pogojna aktivnost (aktivnost <if>). Pogojna aktivnost <if> zagotavlja

opredelitev pogojnega obnašanja. Aktivnost je sestavljena iz urejenega

seznama ene ali več pogojnih vej, ki so opredeljene z aktivnostmi <if> in

opcijskimi <elseif>. Definirane veje se ovrednotijo v istem zaporedju, kot

se pojavijo v sami aktivnosti. Izbere se veja, katere pogoj se prvi ovrednoti kot



resničen in posledično se izvede vsebovana aktivnost. V primeru, da ni izbrana

nobena veja s pogojem, se, v kolikor je prisotna, izbere veja <else>, sicer pa

se aktivnost takoj zaključi.

Dokler (aktivnost <while>). Aktivnost <while> omogoča ponavljajoče se

izvajanje vsebovanih aktivnosti. Vsebovane aktivnosti se ponavljajo tako dolgo

dokler se pogoj, ki je določen z elementom <condition>, ne ovrednoti kot

resničen (vrednotenje na začetku vsake iteracije).

Ponavljaj dokler (aktivnost <repeatUntil>). Aktivnost <repeatUntil>

je podobno kot aktivnost <while> namenjena ponavljajočemu se izvajanju

vsebovanih aktivnosti. Vsebovane aktivnosti se ponavljajo tako dolgo, dokler

specificirani pogoj (uporaba elementa <condition>) ni ovrednoten kot

resničen. Pogoj se preverja po vsaki izvedbi telesa zanke. V nasprotju z

aktivnostjo <while> aktivnost <repeatUntil> v vsakem primeru izvede

vsebovane aktivnosti vsaj enkrat.

Čakaj (aktivnost <wait>). Aktivnost <wait> omogoči časovni zamik izvedbe

naslednjih aktivnosti. Časovni zamik se lahko definira na dva načina: (1)

časovno obdobje, ki določa kako dolgo je aktivnost v čakanju ali (2) dokler se

ne doseže določenega časovnega trenutka. Navesti je potrebno natanko eno

merilo prenehanja veljavnosti (angl. expiration criteria).

Izberi (aktivnost <pick>). Aktivnost <pick> čaka na pojav natančno enega

izmed množice dogodkov in nato izvede aktivnost, ki je povezana s tem

dogodkom. Ko je bil dogodek enkrat izbran, aktivnost ne sprejema več ostalih

dogodkov. V primeru, da sta prisotna dva dogodka, ki sta med seboj

konkurenčna, je izbira dogodka odvisna od implementacije. Aktivnost <pick>

je sestavljena iz množice vej, kjer vsaka vsebuje par dogodek in aktivnost.

Aktivnost <pick> se konča, ko se konča izbrana aktivnost. Dogodki so lahko v

dveh oblikah: (1) dogodek <onMessage>, ki je podoben aktivnosti

<receive> in čaka na prejem vhodnega sporočila in (2) dogodek

<onAlarm>, ki odgovarja časovnemu alarmu, podobno kot aktivnost <wait>.

Vsaka aktivnost <pick> mora vsebovati vsaj en dogodek <onMessage>.



Tok (aktivnost <flow>). Aktivnost <flow> omogoča sinhronizacijo in

vzporednost. Osnovna prednost združevanja nabora različnih aktivnosti v tok

je omogočanje vzporednega izvajanja. Tok se zaključi, ko se zaključijo vse

vsebovane aktivnosti. V kolikor se povezan pogoj ovrednoti kot napačen, se

posamezna aktivnost preskoči in prav tako smatra kot zaključena.

3.4.4.3 Mehanizem za upravljanje dogodkov

Vsak poslovni proces in obseg znotraj njega je lahko povezan z upravljavci

dogodkov (aktivnost <eventHandlers>). Življenjski cikel upravljavcev dogodkov

je enak kot pri povezanih obsegih (zaključi se lahko uspešno ali z napako). Vsak

upravljavec dogodkov (Izsek 2) je povezan z določenim dogodkom in opredeljuje

aktivnost, ki se v primeru pojava dogodka izvede. Sporočila, ki jih zajamejo

upravljavci, so obdelana in ni dovoljeno, da bi bilo posamezno sporočilo istočasno

obdelano z več kot enim upravljavcem dogodkov. Znotraj upravljavca dogodkov lahko

uporabimo vse aktivnosti razen aktivnosti <compensate>.

Izsek 2: Sintaksa upravljavcev dogodkov.

3.4.4.4 Mehanizem za upravljanje izrednih situacij

BPEL za upravljanje izrednih situacij uporablja upravljavce izjem in kompenzacije:

<eventHandlers>?

<onEvent partnerLink="NCName" portType="QName"? operation="NCName"

( messageType="QName" | element="QName" )? variable="BPELVariableName"?

messageExchange="NCName"?>*

<correlations>?

<correlation set="NCName" initiate="yes|join|no"? />+

</correlations>

<fromParts>?

<fromPart part="NCName" toVariable="BPELVariableName" />+

</fromParts>


</onEvent>

<onAlarm>*

( <for expressionLanguage="anyURI"?>duration-expr</for> |

<until expressionLanguage="anyURI"?>deadline-expr</until> )?

<repeatEvery expressionLanguage="anyURI"?>

duration-expr

</repeatEvery>?


</onAlarm>

</eventHandlers>



Upravljavci izjem (aktivnost <faultHandlers>). Upravljavci izjem se

uporabijo za obravnavo tehničnih, poslovnih in standardnih izjem. Vsebuje

aktivnosti, ki jih je potrebno izvesti v primeru, da pride do izjeme. Podrobneje

so upravljavci izjem razloženi v poglavju 3.4.5.2.

Upravljavci kompenzacije (aktivnost <compensationHandler>).

Upravljavci kompenzacije se uporabijo za opredelitev aktivnosti

nadomeščanja. Vsebuje vse aktivnosti, ki jih je potrebno izvesti kot

nadomestilo druge aktivnosti. Opredelimo jih lahko: za celoten proces, za

obseg ter znotraj aktivnosti <invoke>. Če želimo uporabiti upravljavce

kompenzacije v sklopu celotnega procesa BPEL, jih moramo opredeliti

neposredno za upravljavci izjem in pred glavno aktivnostjo procesa. Znotraj

obsega so upravljavci kompenzacije prav tako opredeljeni za upravljavci izjem.

3.4.4.5 Kategorizacija izjem BPEL

Izjeme BPEL lahko kategoriziramo v tri različne skupine: poslovne, tehnične in

standardne izjeme [136]. Pregled izjem podaja Tabela 2. Poslovne izjeme so

specifične izjeme aplikacij in so posledica nepravilne obdelave podatkov (npr. stanje

na računu uporabnika je manjše od zahtevanega dviga). Pojavijo se lahko v dveh

primerih: (1) izvedba aktivnosti <throw>, ki izrecno signalizira pojav izjeme in (2)

aktivnost <invoke>, ko v odgovor sporočila prejme izjemo. Znotraj konstrukta

<faultHandlers> se lahko za lovljenje in obravnavo poslovnih izjem uporabita

atributa <faultName> in <faultVariable>. Ime poslovne izjeme je določeno s

procesom BPEL, tip sporočila (faultMesasgeType) pa je definiran v WSDL [71].

Tehnične izjeme niso definirane s strani uporabnika ampak so sprožene s strani

sistema. So posledica težav, ki se pojavijo pri izvajanju poslovnega procesa ali klicu

spletne storitve (npr. izvajanje izraza XPath (XML Path Language) [140] znotraj

aktivnosti <assign>). Tehnične izjeme je možno tudi samodejno signalizirati z

aktivnostjo <throw>, vendar to ne predstavlja najboljše prakse in se zato ta način

signaliziranja tehničnih izjem redko uporablja. Tehnične izjeme niso povezane s

sporočilom WSDL [14]. Specifikacija BPEL definira tudi standardne izjeme [70].

Standardne izjeme so brez tipa in niso povezane s sporočilom WSDL. Tako jih



zajemamo brez uporabe tipa spremenljivke definirane v WSDL (npr. <catch

faultName="bpws:selectionFault">) [139]. Seznam standardnih izjem si

lahko podrobenje pogledamo v specifikaciji BPEL 2.0. [70]. Znotraj te kategorizacije

lahko izjeme dodatno kategoriziramo med pričakovane, ki morajo biti upravljane s

strani aktivnosti <catch>, in nepričakovane izjeme, ki so obravnavane s strani

aktivnosti <catchAll> [141]. Med vsemi izjemami so pričakovane izjeme (t.i.

nenavadne situacije, ki so načrtovalcem poslovnega procesa znane v naprej) najbolj

uveljavljene in pomembne [142]. Pri pričakovanih izjemah se lahko upravljavec izjem

sklicuje na del semantike poslovnih procesov, ki je zadolžen za uspešno obravnavo

izjem [143]. V primeru nepričakovane izjeme upravljavec izjem načeloma ustavi

izvajanje poslovnega procesa in sproži zahtevo po človeškem posredovanju (angl.

human intervention).

Tabela 2: Kategorizacija izjem BPEL.

Kategorija izjem BPEL Opis Primer

Poslovne izjeme Specifične izjeme aplikacij.

Definirane v WSDL.

Signalizirane s strani aplikacij ali

izrecne zahteve procesa (uporaba

aktivnosti <throw>).

Razpoložljivo stanje na računu

uporabnika je manjše od

zahtevanega dviga.

Tehnične izjeme Sistemske izjeme.

Signalizirane s strani sistema ali izrecne

zahteve procesa (uporaba aktivnosti

<throw>, vendar ne predstavlja dobre

prakse).

Izvajanje izraza XPath znotraj

aktivnosti <assign>.

Standardne izjeme

BPEL

Brez tipa, kar pomeni, da niso povezane

s tipom sporočila (messageTypes).

Niso povezane s sporočilom WSDL.

Validacija spremenljivke glede na

shemo (bpel:invalidVariables).

3.4.5 Signalizacija in obravnava izjem poslovnih procesov

Poslovni procesi BPEL medsebojno komunicirajo z uporabo pozivnih operacij

spletnih storitev. Komunikacija med spletnimi storitvami poteka preko medmrežne

povezave, ki je lahko tako zanesljiva kot tudi nezanesljiva. Zaradi nezanesljivosti



medmrežne povezave in problemov, ki nastanejo pri izvajanju spletnih storitev kot

posledica nepravilnega delovanja infrastrukture, lahko znotraj spletnih storitev pride

do izjeme. Procesi BPEL morajo poskrbeti za ustrezno obravnavo izjem. Poslovni

procesi imajo tudi možnost samodejne signalizacije izjem. Podrobnejši opis delovanja

signalizacije je predstavljen v podpoglavju 3.4.5.1. Signalizacija in obravnava izjem

predstavljata pomemben vidik načrtovanja poslovnih procesov BPEL.

3.4.5.1 Signalizacija izjem poslovnih procesov

V določenih primerih se zgodi, da poslovni proces izrecno zahteva (signalizira)

nastanek izjeme. V ta namen BPEL definira aktivnost <throw> [70]. Sintaksa je

naslednja:

Izsek 3: Izrecna zahteva nastanka izjeme BPEL.

Pri uporabi aktivnosti <throw> BPEL ne zahteva, da v naprej znotraj procesa

definiramo imena izjem, kar lahko privede do napak pri preverjanju imena izjeme

med preverjanjem veljavnosti modela BPEL. Posledično se lahko zgodi, da napačno

zapisana izjema ni obravnavana s strani upravljavca izjem, kar privede do nepravilne

prekinitve izvajanja primerka poslovnega procesa. Izjeme lahko tudi vsebujejo

spremenljivko s podatki, vezane na izjemo. V primeru, da je spremenljivka povezana z

izjemo, moramo to specificirati pri signaliziranju izjeme. V ta namen na aktivnosti

<throw> uporabimo opcijski atribut faultVariable, ki definira tip

spremenljivke, definiran v WSDL [70].

Izsek 4: Izrecna zahteva proženja izjeme BPEL z uporabo spremenljivke.

Izjeme, ki so posledica signalizacije z uporabo aktivnosti <throw>, se morajo

obravnavati znotraj procesa BPEL, saj se izjeme samodejno ne propagirajo do

odjemalca, kot je to v primeru modernih programskih jezikov (npr. Java ali C#) [144].

Če jih proces ne obravnava, pride do nepravilne prekinitve izvajanja primerka

poslovnega procesa.

Signalizacija izjem sinhronega klica poslovnega procesa. Proces BPEL za

komunikacijo z odjemalci uporablja aktivnost <receive>. Če želimo

<throw faultName="name" />

<throw faultName="name" faultVariable="variable-name" />



vzpostaviti sinhroniziran način komunikacije (zahteva/odgovor), proces

uporabi aktivnost <reply>, ki poda odgovor na začetno aktivnost

<receive>. Pri sinhroni komunikaciji se uporabi vhodno in izhodno

sporočilo ter opcijsko sporočilo o napaki.

Signalizacija izjem asinhronega klica poslovnega procesa. Pri asinhrono

delujočem procesu ne moremo uporabiti aktivnosti <reply>, saj odjemalec

ne čaka na odgovor, ampak proces uporablja povratni klic (angl. callback). V ta

namen definiramo novo operacijo na istem tipu vrat (angl. port type). S

pomočjo teh operacij lahko signaliziramo nastanek izjeme, ki je preprečila

normalno izvajanje primerka poslovnega procesa.

3.4.5.2 Obravnava izjem poslovnih procesov BPEL

Nastanek izjeme pri izvajanju poslovnega procesa lahko povzroči, da se njegov

primerek zaključi neuspešno. Zato je pomembno, da so procesi BPEL zasnovani na

način, da pravočasno zaznajo izjeme in jih nato uspešno obravnavajo. Specifikacija

BPEL definira obravnavo izjem z uporabo enega ali več upravljavcev izjem (angl. fault

handlers) [70]. Upravljavci izjem so primerljivi z mehanizmi obravnave izjem

programskih jezikov, kot sta Java in C#, ki uporabljajo poskusi – sproži – zajemi način

delovanja (angl. try – throw – catch) [28]. Vendar pa je treba poudariti, da upravljavci

izjem BPEL samodejno ne propagirajo izjeme nazaj do odjemalca, kot je to definirano

v drugih programskih jezikih [144]. Upravljavci izjem so lahko eksplicitni ali

implicitni.

Eksplicitni upravljavci izjem se uporabijo znotraj aktivnosti <process> in

<scope>. Znotraj aktivnosti <process> se definirajo takrat, ko želimo splošen

upravljavec izjem uporabiti v sklopu celotnega poslovnega procesa. Upravljavci izjem,

ki so definirani znotraj aktivnosti <scope> obravnavajo samo izjeme, ki se zgodijo v

tem določenem obsegu. Definirani so s konstruktom <faultHandlers>, v katerem

uporabimo konstrukta <catch> in <catchAll>. Konstrukt <catch> se lahko

uporabi večkrat, medtem ko se konstrukt <catchAll> lahko definira samo enkrat

znotraj posameznega upravljavca izjem. Vsak konstrukt <catch> je definiran za

prestrezanje in obravnavanje specifičnih izjem, ki so definirane z imenom izjeme

(QName). Za uspešno delovanje aktivnosti moramo definirati vsaj enega izmed dveh

opcijskih atributov: ime izjeme (atribut faultName) ali tip spremenljivke, ki se

uporablja za podatke o izjemi (atribut faultVariable). Aktivnost <catchAll>

se uporabi za obravnavo vseh izjem, ki niso obravnavane s strani <catch>

aktivnosti. Izsek 5 prikazuje sintakso primera eksplicitnega upravljavca izjem.

Izsek 5: Sintaksa eksplicitnega upravljavca izjem.

Implicitne upravljavce izjem definiramo neposredno na <invoke> aktivnost z

uporabo aktivnosti <catch> in <catchAll>. Ta pristop predstavlja učinkovitejši

način obravnave izjem za aktivnost <invoke>, saj se uporabijo specifični upravljavci

izjem namesto splošnih, ki so definirani v konstruktu <faultHandlers>. Sintaksa

implicitnih upravljavcev izjem je podobna eksplicitnim. Uporabimo lahko nič ali več

aktivnosti <catch> in največ eno <catchAll> aktivnost. Edina razlika je v tem, da

moramo pri implicitnih upravljavcih izjem specificirati ime izjeme. Izsek 6 prikazuje

sintakso primera implicitnega upravljavca izjem.

<process ...>

<partnerLinks> … </partnerLinks>

<variables> … </variables>

<faultHandlers>

<catch ... >



</catch>

<catch ... >


</catch>

...



<catchAll>


</catchAll>

</faultHandlers>

<sequence> … </sequence>

</process>



Izsek 6: Sintaksa implicitnega upravljavca izjem.

Pri obravnavi izjem moramo, prav tako kot pri signaliziranju izjem, biti pozorni na

vrsto komunikacije, ki poteka med odjemalci storitev. Komunikacija je lahko sinhrona

ali pa asinhrona.

3.5 Vzorci obravnave izjem

Iniciativa Workflow Patterns (krat. WPI) [145] je svoje delovanje začela leta 1999, ko

je želela vzpostaviti konceptualno podlago za procesno tehnologijo, ki bi se lahko

uporabila za ocenjevanje prednosti in slabosti različnih pristopov pri specifikaciji

procesov. Uporabila je empiričen pristop za identifikacijo zahtev sistemov PAIS ter jih

nato dokumentirala v obliki vzorcev. Koncept vzorcev je uvedel Christopher

Alexander, ki je na arhitekturni način opredelil vrsto ponovno uporabnih struktur

[85]. Alexander je definiral vzorec kot razmerje med problemom in rešitvijo, ki se

uporabi v določenem kontekstu. Vzorci so se izkazali za zelo uspešne pri uporabi

preizkušenih in zanesljivih rešitev za pogosto ponavljajoče se težave na različnih

področjih [146].

Slika 7 prikazuje, kako je IPW najprej predlagala kontrolne vzorce poslovnih

procesov. Van der Aalst ter drugi so empirično analizirali izbor sistemov za

upravljanje s poslovnimi procesi in identificirali dvajset splošnih vzorčnih kontrolnih

struktur [21, 147]. Kmalu za tem so Russell in ostali raziskali področje podatkovnih

virov in perspektiv in skladno s tem leta 2005 objavili štirideset podatkovnih vzorcev

in triinštirideset vzorcev vira. Vzorci opisujejo različne načine predstavitve in

izkoriščanja podatkov ter virov pri izvajanju poslovnih procesov [148, 149].

<invoke ... >

<catch faultName="ImeIzjeme" >


</catch>

...

<catch faultName="ImeIzjeme" faultVariable="SpremenljivkaIzjeme" >


</catch>

...

<catchAll>


</catchAll>

</invoke>



Omenjenim raziskavam je sledila opredelitev vzorcev za upravljanje z izjemami, ki so

posledica nenormalnega izvajanja primerka poslovnega procesa [150].

Slika 7: Razvoj kontrolnih vzorcev poslovnih procesov s strani IPW [24].

WPI predlaga klasifikacijsko ogrodje za obravnavo izjem sistemov PAIS, ki temeljijo

na vzorcih. Ogrodje je predstavljeno na konceptualni ravni in je tako neodvisno od

posameznih pristopov in tehnologij modeliranja ter jezika za izvajanje poslovnih

procesov. Obseg izjem, ki jih zaznajo sistemi PAIS, lahko razdelimo v pet različnih

skupin: (1) odpoved aktivnosti, (2) iztek skrajnega roka, (3) nerazpoložljivost virov,

(4) zunanji prožilec in (5) kršitev omejitev.

Odpoved aktivnosti (angl. work item failure). Med izvajanjem primerka

poslovnega procesa odpoved aktivnosti predstavlja nezmožnost delovanja

primerka poslovnega procesa. To se lahko manifestira zaradi več možnih

vzrokov; okvara programske ali strojne opreme, mrežnih komponent ali

uporabnik, ki procesnemu stroju signalizira prekinitev izvajanja poslovnega

procesa. Ker procesni model ne zajema in obravnava obdelave teh izjem,

moramo poskrbeti za njihovo obravnavo na drugem mestu in s tem omogočiti

pravilno obnašanje poslovnega procesa.

Iztek skrajnega roka (angl. deadline expiry). Znotraj procesnega modela se

za aktivnost pogosto določi skrajni rok. Skrajni rok običajno pokaže, kdaj se

mora določena aktivnost zaključiti. Možno ga je definirati tudi za inicializacijo

aktivnosti. Pri načrtovanju modela poslovnega procesa je koristno definirati

tudi način izvajanja procesa ob dosegu skrajnega roka.

Nerazpoložljivost virov (angl. resource unavailability). Izvajanje aktivnosti

pogosto zahteva dostop do enega ali več podatkovnih virov. Če pri inicializaciji

aktivnosti podatkovni viri niso dosegljivi, se aktivnost ne more uspešno

izvesti. Podobno sistemi PAIS temeljijo na dejstvu, da so aktivnosti dodeljene



virom, ki jih ti izvršijo. Pri tem lahko pride do različnih problemov (npr. Sistem

v času dodelovanja ne najde vira, ki bi ustrezal zahtevam opravila.).

Zunanji prožilec (angl. external trigger). Zunanji prožilci se pogosto

uporabljajo za signaliziranje dogodkov, ki vplivajo na aktivnost in zahtevajo

njihovo obravnavo. Običajno prožilci niso povezani direktno z aktivnostjo

(kateri pošljejo signal za proženje), ampak so definirani na drugih aktivnostih

znotraj procesnega modela. Čeprav aktivnosti lahko predvidevajo dogodke,

kot je prožilec, in se jih lahko vključi pri načrtovanju procesa, ni možno

predvidevati, če in kdaj se bodo ti dogodki izvršili. Zaradi tega ni primerno, da

dogodke obdelamo pri normalnem izvajanju aktivnosti, temveč da jih

obravnavamo preko upravljavcev izjem.

Kršitev omejitev (ang. constraint violation). Omejitve v okviru sistemov PAIS

predstavljajo nespremenljivost elementov delovnega toka, ki jih je potrebno

vzdrževati, da se zagotovi celovitost in operativna doslednost procesa.

3.5.1 Obravnava izjem na nivoju aktivnosti

V večini primerov pri izvajanju poslovnih procesov izjeme nastanejo ob neuspešni

izvedbi poslovne aktivnosti. Izjeme se lahko obravnavajo na različne načine in da bi

razumeli, kateri način uporabiti, si poglejmo življenjski cikel aktivnosti [145]. Slika 8

prikazuje življenjski cikel aktivnosti z vidika posameznega vira. Polne puščice

prikazujejo potek stanj ob normalni izvedbi aktivnosti, medtem ko črtkaste puščice

predstavljajo potek stanj izvajanja aktivnosti v primeru pojava izjeme.



Slika 8: Življenjski cikel aktivnosti z vidika posameznega vira [145].

Aktivnost se najprej nahaja v stanju ponujeno (angl. offered) in skladno s tem je

aktivnost ponujena enemu ali več virov. Kadar želi vir izvesti izvajanje aktivnost,

aktivnosti pošlje zahtevo po dodelitvi (angl. allocate) in aktivnost preide v stanje

dodeljeno (angl. allocated). Običajno se s tem aktivnost dodeli v vrsto vira, kjer je na

razpolago za izvajanje. Ko želi vir začeti z izvajanjem aktivnosti, le-tej pošlje zahtevo

začetek (angl. start) in stanje aktivnosti se spremeni v začeto (angl. started). Po

uspešni izvedbi aktivnosti ta preide v novo stanje končano (angl. completed).

Potrebno je upoštevati, da obstajata dva možna odstopanja od normalnega izvajanja

aktivnosti: (1) če nov vir izbere aktivnost, ki je že ponujena prvemu viru, se aktivnost

odstrani iz seznama prvega in preide v stanje odstranjeno (angl. withdrawn), ter (2)

neuspešna (angl. failed) izvedba aktivnosti. Kot smo že omenili, na Slika 8 črtkaste

črte predstavljajo različne možnosti obravnave izjem, ki nastanejo pri izvajanju

posameznih stanj aktivnosti. Obstaja petnajst različnih prehodov obravnave izjem

med katerimi so minimalno opazne razlike [145]:

Nadaljuj-ponudi (angl. continue-offer) – OCO. Aktivnost je ponujena enemu

ali več virom. Ob pojavu izjeme se stanje aktivnosti ne spremeni.

ponujeno

nadaljuj-ponudi

ponovnaponudba

dodeljenodedelitev začetozačetek

neuspešno

zaključek

končano

odstranjeno

odstranitev

prisilna neuspešnost (p)

ponovna ponudba (z)

prisilni zaključek (p)

nadaljuj-dodeli

ponovnadodelitev

nadaljuj-izvajaj

ponovnizačetek

prisilni zaključek (d)

prisilni zaključek

ponovnaponudba (d)

ponovnadodelitev (z)

prisilna neuspešnost (d)

prisilna neuspešnost

neuspešnost



Ponovna ponudba (angl. reoffer) – ORO. Aktivnost je ponujena enemu ali več

virom. Ob pojavu izjeme se aktivnost odstrani in se ponovno ponudi virom. Ni

nujno, da se ponudi istim virom kot prej.

Prisilna neuspešnost (p) (angl. force-fail-o) – OFF. Aktivnost je ponujena

enemu ali več virom. Ob pojavu izjeme se aktivnost odstrani in stanje

aktivnosti se spremeni v neuspešno. Nobena naslednja aktivnost procesnega

toka se ne proži.

Prisilni zaključek (p) (angl. force-complete-o) – OFC. Aktivnost je ponujena

enemu ali več virom. Ob pojavu izjeme se aktivnost odstrani in stanje

aktivnosti se spremeni v končano. Vse naslednje aktivnost procesnega toka se

prožijo.

Nadaljuj-dodeli (angl. continue–allocation) – ACA. Aktivnost je dodeljena

posameznemu viru in bo izvedena v bližnji prihodnosti. Stanje aktivnosti se ne

spremeni.

Ponovna dodelitev (angl. reallocate) – ARA. Aktivnost je v stanju dodeljena

viru. Dodelitev aktivnosti se odstrani in aktivnost se dodeli novemu viru.

Ponovna ponudba (d) (angl. reoffer-a) – ARO. Aktivnost je v stanju dodeljena

viru. Dodelitev aktivnosti se odstrani in aktivnost se ponudi novemu viru.

Prisilna neuspešnost (d) (angl. force-fail-a) – AFF. Aktivnost je v stanju

dodeljena viru. Dodelitev aktivnosti se odstrani in stanje aktivnosti se

spremeni v neuspešno. Nobena naslednja aktivnost procesnega toka se ne

proži.

Prisilni zaključek (d) (angl. force-complete-a) – AFC. Aktivnost je v stanju

dodeljena viru. Dodelitev aktivnosti se odstrani in stanje aktivnosti se

spremeni v končano. Vse naslednje aktivnost procesnega toka se prožijo.

Nadaljuj-izvajaj (angl. continue-execution) – SCE. Aktivnost je v stanju začeto.

Nastanek izjeme ne spremeni stanja aktivnosti.

Ponovni začetek (angl. restart) – SRC. Aktivnost je v stanju začeto. Izvajanje

trenutnega primerka se ustavi. Aktivnost se ponovno zažene od začetka.

Ponovno se uporabi vir, ki je bil predhodno uporabljen



Ponovna dodelitev (z) (angl. reallocate-s) – SRA. Aktivnost je v stanju začeto.

Izvajanje trenutnega primerka se ustavi. Aktivnost se za poznejšo izvedbo

dodeli drugemu viru.

Ponovna ponudba (z) (angl. reoffer-s) – SRO. Aktivnost je v stanju začeto.

Izvajanje trenutnega primerka se ustavi. Aktivnost se za poznejšo izvedbo

ponudi enemu ali več virom. Ni njuno, da se uporabi vir, ki je bil predhodno

uporabljen.

Prisilna neuspešnost (angl. force-fail) – SFF. Aktivnost je v stanju izvajanja.

Vsako nadaljnjo izvajanje je zaustavljeno. Stanje aktivnosti se spremeni v

neuspešno. Nobena naslednja aktivnost procesnega toka se ne proži.

Prisilni zaključek (angl. force-complete) – SFC. Aktivnost je v stanju izvajanja.

Vsako nadaljnjo izvajanje je zaustavljeno. Stanje aktivnosti se spremeni v

končano. Vse naslednje aktivnost procesnega toka se prožijo.

3.5.2 Obravnava izjem na nivoju primera

Izjeme se pogosto pojavijo v zvezi z enim ali več primerov (angl. case) znotraj

poslovnega procesa. Primer predstavlja skupek kontekstno povezanih aktivnosti. To

pomeni, da se ne smemo osredotočiti samo na določeno aktivnost, temveč moramo v

okvir vzeti celoten kontekst izvajanja primerka poslovnega procesa. Skladno s tem

moramo upoštevati delovanje drugih aktivnosti, ki jih proces definira. Obstajajo tri

alternative za obravnavo primerov poslovnih procesov [145]:

Nadaljuj s primerom (angl. continue with case) – CWC. Izvajanje primera se

nadaljuje brez posredovanja na druge aktivnosti.

Odstrani trenuten primer (angl. remove current case) – RCC. Izbrane ali vse

preostale aktivnosti znotraj primera se lahko odstranijo.

Ostrani vse primere (angl. remove all cases) – RAC. Izbrane ali vse preostale

aktivnosti znotraj določenega ali drugih primerov se lahko odstranijo.



3.5.3 Aktivnosti obnovitve

Pri obravnavi izjem moramo pozornost nameniti tudi načinu odprave posledic, ki

nastanejo zaradi pojava izjeme pri izvajanju primerka poslovnega procesa. Obstajajo

tri alternativne možnosti ukrepanja:

Brez ukrepanja (angl. no action) – NIL. Nič se ne zgodi.

Razveljavitev (angl. rollback) – RBK. Vzpostavitev prejšnjega stanja

aktivnosti. Dogodki izvajanja se zapišejo v dnevnik izjem.

Kompenzacija (angl. compensate) – COM. Učinki izjem se nadomestijo.

3.5.4 Mehanizem obravnave izjem

Mehanizem obravnave izjem sistemov WFMS mora biti sposoben zaznave in zajema

izrednih dogodkov ter vzpostaviti učinkovito strategijo odzivnosti [143]. Za vsak

odziv se mora najprej oceniti stanje procesa in nato sprejeti korektivne ukrepe. V

nekaterih primerih dogodki ustrezajo lažnim alarmom in zato ni potrebno, da bi

sledili korektivni ukrepi. Omenjeni mehanizem je precej podoben strategiji

upravljanja prožilcev, ki se uporabljajo v aktivnih podatkovnih bazah [151].

Mehanizem obravnave izjem je sestavljen iz naslednjih komponent:

Dogodek. Opredeljuje simptome izjem (npr. sprememba podatkovne baze ali

signala, ki prihaja iz drugih delov poslovnega toka itd.).

Pogoj. Predstavlja logičen predikat, ki preveri, če simptomi predstavljajo

izjemo, ki jo je potrebno obravnavati. Pogoj se lahko uporabi tudi pri izbiri ene

izmed več možnih načinov obravnave izjem.

Ukrep. Opisuje posodobitve in postopke, ki jih je potrebno izvesti kot odziv na

nastanek izjeme.

3.5.5 Strategije obravnave izjem

Dejanski odziv na izjemo se lahko določi kot vzorec, ki jedrnato opisuje obliko in

način obravnave izjeme. Pri načrtovanju danega poslovnega procesa se lahko

uporabijo posamezni vzorci obravnave izjem, ki jih lahko vključimo na različne

načine. Pri izbiri ustreznega vzorca si lahko pomagamo z naslednjimi vprašanji:



Na kakšen način se naj obravnava aktivnost, pri kateri je prišlo do izjeme?

Na kakšen način se naj obravnavajo vse aktivnosti (tudi tiste, pri katerih ni

prišlo do izjeme) v procesu?

Katere aktivnosti obnovitve se naj izvedejo?

Tabela 3 predstavlja obliko uporabe vzorcev za obravnavo izjem znotraj poslovnega

procesa. Zasnovanih je 135 različnih vzorcev, ki so povzeti po viru [145]. Posamezen

vzorec je sestavljen iz treh zaporednih aktivnosti, ki so vzete iz treh različnih skupin

ukrepanja. Te skupine smo opisali v predhodnem poglavju. Skladno s tem mora vsak

vzorec vsebovati ukrepe na nivoju posamezne aktivnosti, celotnega primera procesa

in aktivnosti obnovitve. Kot je razvidno iz Tabela 3 smo sestavljene vzorce razporedili

v skupine obsega dogodkov izjem. Sestavljene strategije za obravnavo izjem se lahko

uporabijo na vseh procesnih konstruktih, kot so posamezna aktivnost, obseg, blok,

proces in procesno okolje (vsi procesni modeli znotraj okolja).



Tabela 3: Razporeditev sestavljenih vzorcev v skupine obsega dogodkov izjem [145].

Odpoved

aktivnosti

Iztek skrajnega

roka

Nerazpoložljivost

virov

Zunanji prožilec Omejitev kršitev

OFF-CWC-NIL

OFF-CWC-COM

OFC-CWC-NIL

OFC-CWC-COM

AFF-CWC-NIL

AFF-CWC-COM

AFC-CWC-NIL

AFC-CWC-COM

SRS-CWS-NIL

SRS-CWC-COM

SRS-CWC-RBK

SFF-CWC-NIL

SFF-CWC-COM

SFF-CWC-RBK

SFF-RCC-NIL

SFF-RCC-COM

SFF-RCC-RBK

SFC-CWC-NIL

SFC-CWC-COM

SFC-CWC-RBK

OCO-CWC-NIL

ORO-CWC-NIL

OFF-CWC-NIL

OFF-RCC-NIL

OFC-CWC-NIL

ACA-CWC-NIL

ARA-CWC-NIL

ARO-CWC-NIL

AFF-CWC-NIL

AFF-RCC-NIL

AFC-CWC-NIL

SCE-CWC-NIL

SCE-CWC-COM

SRS-CWC-NIL

SRS-CWC-COM

SRS-CWC-RBK

SRA-CWC-NIL

SRA-CWC-COM

SRA-CWC-RBK

SRO-CWC-NIL

SRO-CWC-COM

SRO-CWC-RBK

SFF-CWC-NIL

SFF-CWC-COM

SFF-CWG-RBK

SFF-RCC-NIL

SFF-RCC-COM

SFF-RCC-RBK

SFC-CWC-NIL

SFC-CWC-COM

ORO-CWC-NIL

OFF-CWC-NIL

OFF-RCC-NIL

OFC-CWC-NIL

ARO-CWC-NIL

ARA-CWC-NIL

AFF-CWC-NIL

AFF-RCC-NIL

AFC-CWC-NIL

SRA-CWC-NIL

SRA-CWC-COM

SRA-CWC-RBK

SRO-CWC-NIL

SRO-CWC-COM

SRO-CWC-RBK

SFF-CWC-NIL

SFF-CWC-COM

SFF-CWC-RBK

SFF-BCC-NIL

SFF-BCC-COM

SFF-RCC-RBK

SFF-RAC-NIL

SFC-CWC-NIL

SFC-CWC-COM

OCO-CWC-NIL

OFF-CWC-NIL

OFF-RCC-NIL

OFC-CWC-NIL

ACA-CWC-NIL

AFF-CWC-NIL

AFF-RCC-NIL

AFC-CWC-NIL

SCE-CWC-NIL

SRS-CWC-NIL

SRS-CWC-COM

SRS-CWC-RBK

SFF-CWC-NIL

SFF-CWC-COM

SFF-CWC-RBK

SFF-RCC-NIL

SFF-RCC-COM

SFF-RCC-RBK

SFF-RAC-NIL

SFC-CWC-NIL

SFC-CWC-COM

SCE-CWC-NIL

SRS-CWC-NIL

SRS-CWC-COM

SRS-CWC-RBK

SFF-CWC-NIL

SFF-CWC-COM

SFF-CWC-RBK

SFF-RCC-NIL

SFF-RCC-COM

SFF-RCC-RBK

SFF-RAC-NIL

SFC-CWC-NIL

SFC-CWC-COM



Da bi posamezno delovanje vzorcev bolje razumeli, si poglejmo nekaj primerov

uporabe, ki smo jih uporabili pri raziskovanju našega dela.

Vzorec SFF-CWC-COM. Če izjema nastane v trenutku, ko aktivnost preide v

stanje začeto, je potrebno aktivnosti zaključiti, stanje aktivnosti spremeniti v

neuspešno in prožiti nadomestno aktivnost. Nobena druga aktivnost znotraj

istega primerka se ne sme izvesti. Kot lahko opazimo, se ta vzorec lahko

uporabi samo pri aktivnosti, ki se je že začela izvajati. Če je aktivnost v stanju

ponujeno ali dodeljeno, je potrebno uporabiti drug nabor vzorcev (npr. OFF-

CWC-COM oz. AFF-CWC-COM).

Vzorec OFF-RCC-NIL. Če izjema nastane v trenutku, ko je aktivnost v stanju

ponujeno, je potrebno spremeniti stanje aktivnosti v neuspešno in vse ostale

aktivnosti znotraj tega primerka odstraniti iz obdelave. Nobena druga

aktivnost se ne sme izvesti.

Vzorec AFC-CWC-NIL. Če izjema nastane v trenutku, ko je aktivnost v stanju

dodeljeno viru in ta vir postane nedosegljiv preden se aktivnost začne, mora

aktivnost preiti v stanje končano. Druge aktivnosti znotraj primerka se morajo

nadaljevati. Nobena aktivnost obnovitve se ne zažene. Če je vir, kateremu je

bila aktivnost dodeljena, nedosegljiv, se aktivnost lahko preskoči.

V nadaljevanju (Tabela 4) predstavimo rezultate analize podpore posameznih

vzorcev s strani procesnih jezikov: XPDL, ki je trenutno na področju obravnave izjem

najbolj aktualen procesni jezik v raziskovalnem okolju [105], in BPEL, ki se trenutno

najbolj uporablja v realno-praktičnem okolju. Podpora vzorcev za jezik XPDL 2.0

[145], BPEL 1.1 [145] je povzeta po viru. Podpora s strani jezika BPEL 2.0 in BPMN

2.0 je rezultat lastnega raziskovalnega dela.



Tabela 4: Analize podpore posameznim vzorcem s strani procesnih jezikov.

Podpora Odpoved

aktivnosti Iztek skrajnega roka

Zunanji prožilec Omejitev kršitev

BPEL 1.1 SFF-CWC-COM

SFF-CWC-NIL

SFF-RCC-COM

SFF-RCC-NIL

SCE-CWC-COM

SCE-CWC-NIL

SFF-CWC-COM

SFF-CWC-NIL

SFF-RCC-COM

SFF-RCC-NIL

SCE-CWC-COM

SCE-CWC-NIL

SFF-CWC-COM

SFF-CSC-NIL

SFF-RCC-COM

SFF-RCC-NIL

XPDL 2.0

(WfMC)

SFF-CWC-COM

SFF-CWC-NIL

SFF-RCC-COM

SFF-RCC-NIL

SCE-CWC-COM

SCE-CWC-NIL

SFF-CWC-COM

SFF-CWC-NIL

SFF-RCC-COM

SFF-RCC-NIL

SFF-CWC-COM

SFF-CWC-NIL

SFF-RCC-COM

SFF-RCC-NIL

SFF-CWC-COM

SFF-CWC-NIL

SFF-RCC-COM

SFF-RCC

BPEL 2.0 SFF-CWC-COM

SFF-CWC-NIL

SFF-RCC-COM

SFF-RCC-NIL

SFC-CWC-COM

SFC-CWC-NIL

SRS-CWC-COM

SRS-CWC-NIL

SCE-CWC-COM

SCE-CWC-NIL

SFF-CWC-COM

SFF-CWC-NIL

SFF-RCC-COM

SFF-RCC-NIL

SFC-CWC-COM

SFC-CWC-NIL

SRS-CWC-COM

SRS-CWC-NIL

SCE-CWC-COM

SCE-CWC-NIL

SFF-CWC-COM

SFF-CSC-NIL

SFF-RCC-COM

SFF-RCC-NIL

SFC-CWC-COM

SFC-CWC-NIL

SRS-CWC-COM

SRS-CWC-NIL

SFF-CWC-COM

SFF-CWC-NIL

BPMN 2.0 SFF-CWC-COM

SFF-CWC-NIL

SFC-CWC-COM

SFC-CWC-NIL

SRS-CWC-COM

SRS-CWC-NIL

SFF-RCC-COM

SFF-RCC-NIL

SFF-CWC-COM

SFF-CWC-NIL

SFC-CWC-COM

SFC-CWC-NIL

SRS-CWC-COM

SRS-CWC-NIL

SFF-RCC-COM

SFF-RCC-NIL

SFF-CWC-COM

SFF-CWC-NIL

SFC-CWC-COM

SFC-CWC-NIL

SRS-CWC-COM

SRS-CWC-NIL

SFF-RCC-COM

SFF-RCC-NIL

SFF-CWC-COM

SFF-CWC-NIL

SFC-CWC-COM

SFC-CWC-NIL

SRS-CWC-COM

SRS-CWC-NIL

SFF-RCC-COM

SFF-RCC-NIL



3.5.6 Predstavitev primera uporabe vzorcev strategij obravnave

izjem

Za boljše razumevanje omenjenih konceptov je WPI predlagala nabor primitivnih

gradnikov za obravnavo izjem, ki se lahko pojavijo pri izvajanju poslovnega procesa

in na splošen način predstavljajo mehanizem za integracijo omenjenih gradnikov s

procesnim modelom [59]. Slika 9 predstavlja omenjene primitivne gradnike.

Slika 9: Primitivni gradniki za obravnavo izjem. [59]

Gradniki se lahko sestavijo v zaporedje ukrepov, ki določajo strategijo za obravnavo

izjem. Predlagan konceptualni model obravnave izjem je sestavljen iz treh različnih

dimenzij:

Obravnava trenutne aktivnosti, na kateri pride do izjeme.

o Sestavljajo jo gradniki 1 – 4, 8 in 12 – 14.

Obravnava ostalih aktivnih aktivnosti.

o Sestavljajo jo gradniki 5 – 7 in 9 – 11.

Uporaba obnovitvenih aktivnosti.

1. Odstrani trenutno aktivnost

5. Odstrani izbrane/vseaktivnosti trenutnega primera

9. Odstrani izbrane/vseaktivnosti vseh primerov

13. Ponovno dodeli trenutno aktivnost

2. Zaustavi trenutno aktivnost

6. Zaustavi izbrane/vseaktivnosti trenutnega primera

10. Zaustavi izbrane/vseaktivnosti vseh primerov

14. Ponovno ponudi trenutno aktivnost

3. Nadaljuj trenutno aktivnost

7. Nadaljuj izbrane/vseaktivnosti trenutnega primera

11. Nadaljuj izbrane/vseaktivnosti vseh primerov

15. Kompenzacija

4. Ponovi začetek trenutne aktivnosti

8. Prisilni zaključek trenutne aktivnosti

12. Prisilna neuspešnost trenutne aktivnosti

16. Vrni aktivnost na začetek



o Gradnika 15 in 16.

Primitivne gradnike lahko združimo v različne strategije obravnave izjem. Vzorčno

uporabo primarnih gradnikov za obravnavo izjem ponazarja Slika 10, kjer lahko pri

procesu Izterjava vidimo uporabo različnih vzorcev strategij obravnave izjem za

aktivnost Pridobivanje podatkov o zapadlih terjatvah. Pri modeliranju poslovnega

procesa smo za uporabo vzorcev obravnave izjem uporabili omenjene konceptualne

primarne gradnike. Za modeliranje smo uporabili notacijo BPMN.

Slika 10: Vzorčna uporaba primarnih gradnikov za obravnavo izjem.

Pri ponazoritvi vzorčne uporabe primarnih gradnikov za obravnavo izjem smo

uporabili precej poenostavljen primer poslovnega procesa Izterjava (Slika 11), ki smo

ga implementirali v času našega raziskovalnega dela. Izterjava se prične z zahtevo, ki

jo poda skrbnik dolžnika. Zahtevek vsebuje številko dolžnika, na podlagi katerega se

iz finančno-računovodskega sistema pridobijo podatki o zapadlih terjatvah (aktivnost

Pridobivanje podatkov o zapadlih terjatvah), iz sistema za upravljanje odnosov s

strankami pa podatki oz. podrobnosti o dolžniku (aktivnost Pridobivanje podatkov

dolžnika). Vse zbrane podatke (zapadle terjatve in podrobnosti dolžnika) mora

skrbnik pregledati (aktivnost Preverjanje ustreznosti dolžnika). Pred nadaljevanjem

postopka izterjave ima skrbnik možnost, da po potrebi določene terjatve izloči iz

Kreiranje zahtevka po

dolžniku

Pridobivanje podrobnosti o

dolžniku

Pridobivanje podatkov o

zapadlih terjatvah

Preverjanje ustreznosti

dolžnika

Izločitev določenih

izterjav

Dogovarjanje z dolžnikom

IzvršbaOdpis oziroma

tožba

definicija obravnave izjem aktivnosti

(Pridobivanje podatkov o zapadlih

terjatvah)odpoved aktivnosti

iztek skrajnega roka<skrajniRok>

kršitev omejitev<omejitev>



postopka (aktivnost Izločitev določenih terjatev). Postopek izterjave nato sledi v treh

fazah, kjer velja: če v prvi fazi izterjava ni uspešna, postopek napreduje v drugo fazo.

Če izterjava ni uspešna niti v drugi fazi, postopek napreduje v tretjo fazo.

Faze so naslednje:

1. faza: Dogovarjanje z dolžnikom (podproces Dogovarjanje z dolžnikom).

2. faza: Izvršba (podproces Izvršba).

3. faza: Odpis terjatev oz. tožba (podproces Odpis oziroma tožba).

Slika 11: Poslovni proces Izterjava.

Pri pridobivanju podatkov o zapadlih terjatvah sta možni dve različni alternativni

možnosti uporabe vzorcev obravnave izjem. Prva strategija se uporabi v primeru, da

imamo zapadle terjatve (pogoje je: $steviloTerjatev > 0). V tem primeru se

prekine izvajanje aktivnosti, premaknemo se do naslednje aktivnosti in sprožimo njen

začetek. Z drugimi besedami, aktivnost Pridobivanje podatkov o zapadlih terjatvah se

preskoči in nadzor se vrne procesu na začetek naslednje aktivnosti. Predstavitev

vzorca obravnave izjeme z uporabo preprostih gradnikov predstavlja Slika 12.

Slika 12: Predstavitev vzorca obravnave izjeme z uporabo preprostih gradnikov – a.

Pri preverjanju podatkov o zapadlih terjatvah se lahko prav tako zgodi, da le teh

nimamo (pogoje je: $steviloTerjatev = 0). V tem primeru gre za drugi primer

uporabe vzorcev obravnave izjem. Skrbnik zapadlih obveznosti se je predhodno

Kreiranje zahtevka po

dolžniku

Pridobivanje podrobnosti o

dolžniku

Pridobivanje podatkov o

zapadlih terjatvah

Preverjanje ustreznosti

dolžnika

Izločitev določenih

izterjav

Dogovarjanje z dolžnikom

IzvršbaOdpis oziroma

tožba

$steviloTerjatev > 0



zmotil in pričel z izterjavo za dolžnika, ki nima zapadlih terjatev. Izterjava se mora

zaključiti, saj gre za napako skrbnika. V tem primeru se prekine izvajanje aktivnosti,

premaknemo se do naslednje aktivnosti in sprožimo njen začetek. Predstavitev

vzorca obravnave izjeme z uporabo preprostih gradnikov predstavlja Slika 13.

Slika 13: Predstavitev vzorca obravnave izjeme z uporabo preprostih gradnikov – b.

Naslednji primer prikazuje strategijo obravnave nedosegljivosti virov. Strategijo

uporabimo na aktivnosti Preverjanje ustreznosti dolžnika, kjer predstavimo dve

različni alternativi obravnave izjem. V prvem primeru, pri preverjanju ustreznosti

dolžnika, uporabimo podatkovni vir, ki je v danem primeru nedosegljiv. Zaustaviti

moramo trenutno aktivnost, iti nazaj na začetek aktivnosti in jo ponovno začeti.

Predstavitev vzorca obravnave izjeme z uporabo preprostih gradnikov prikazuje Slika

14.

Slika 14: Predstavitev vzorca obravnave izjeme z uporabo preprostih gradnikov – c.

V drugem primeru pri preverjanju ustreznosti dolžnika kot vir uporabimo

uporabniško opravilo, s katerim upravlja uporabnik oziroma skrbnik dolžnika. V

trenutku preverjanja ustreznosti dolžnika je skrbnik uporabniškega opravila

nedosegljiv. V tem primeru moramo zaustaviti trenutno aktivnost, prerazporediti

opravilo na drugo osebo in začeti postopek znova. Predstavitev vzorca obravnave

izjeme z uporabo preprostih gradnikov prikazuje Slika 15.

$steviloTerjatev = 0



Slika 15: Predstavitev vzorca obravnave izjeme z uporabo preprostih gradnikov – d.



Predstavitev rešitve 4

4.1 Podrobna predstavitev problema

Specifikacija BPEL zagotavlja zelo osnoven in omejen mehanizem za obravnavo izjem

in ne vsebuje zmogljivih in prilagodljivih mehanizmov obravnave izjem [35, 153].

Obravnavo izjem znotraj poslovnih procesov BPEL omogočajo aktivnosti

<faultHandlers>, <catch> in <catchAll>. V naslednjem poglavju

predstavimo tri ključne pomanjkljivosti, s katerimi se pri obravnavi izjem srečujejo

načrtovalci procesa.

4.1.1 Napaka pri klicu storitev

Pri izvajanju poslovnega procesa lahko pride do različnih tehničnih izjem. Ena izmed

njih je tudi izjema klica storitve, do katere lahko pride zaradi nedostopnosti spletnih

storitev ali težav znotraj omrežja. Ko nastane izjema klica storitve, storitev ni več na

voljo in posledično proces ni zmožen poklicati storitve. Zaradi nedelovanja storitve se

sprožijo upravljavci izjem. To povzroči, da se primerek poslovnega procesa

nenormalno izvede. V imenovanem primeru nenormalna izvedba primerka

poslovnega procesa ne bi bila potrebna, če bi storitev bila ponovno na voljo v kratkem

časovnem intervalu ter bi proces lahko z njo komuniciral.

Za rešitev omenjenega problema mora BPEL imeti možnost ponovnega klica spletne

storitve. Trenutno se ta pomankljivost rešuje z uporabo zank, ki jih lahko definiramo

z aktivnostma <repeatUntil> ali <while>. Ker omenjena konstrukta nista

namenjena obravnavi izjem, omenjena rešitev ne predstavlja dobre prakse. Še več,

vpeljava zanke, ki je namenjena samo obravnavi izjem, dodatno oteži načrtovanje in

izvajanje kontrolnega toka v poslovnem procesu.

Slika 16 prikazuje primer uporabe aktivnosti <repeatUntil> pri upravljanju izjem.

Da omogočimo ponoven klic spletne storitve, kadar je pri prvem klicu spletna storitev

nedosegljiva, smo v proces dodali aktivnost <repeatUntil> in s tem ustvarili

zanko. Zanko definirajo naslednje aktivnosti: <assign>, <invoke> in

<faultHandlers>. Najprej je potrebno znotraj aktivnosti <assign> nastaviti



vrednost spremeljivke oz. zastavice klicUspel na pozitivno vrednost (true). To je

pomemben korak, saj v primeru uspešne izvedbe aktivnosti <invoke> izstopimo iz

zanke in nadaljujemo z normalnim izvajanjem poslovnega procesa. Aktivnost

<invoke> (Klic storitve) je definirana s konstruktom <faultHandlers>, ki je

sprožen v primeru, da pride do izjeme pri izvajanju storitve Klic storitve. Upravljavec

izjem je definiran z aktivnostima <humanTask> in <choice>. Uporabniško opravilo

omogoči interakcijo uporabnika s procesom. Na voljo imamo dve možnosti: ponoven

poskus ali prezri. Ko je vrednost izbrana, se podatki posredujejo aktivnosti

<choice>, kjer se spremenljivka, glede na prejšnjo izbiro nastavi na pozitivno ali

negativno vrednost (true ali false). V primeru vrednosti false se izvajanje

zanke ponovi. V nasprotnem primeru istopimo iz zanke in nadaljujemo z normalnim

izvajanjem poslovnega procesa. Kot lahko vidimo, je uporaba zanke precej povečala

kompleksnost kontrolnega toka poslovnega procesa.

Slika 16: Rešitev BPEL za napake pri klicu storitev.



4.1.2 Podvojenost kode

Trenutna specifikacija BPEL zahteva, da načrtovalci procesov za vsak poslovni proces

definirajo svoje upravljavce izjem. V primeru, da imamo znotraj sistema več

poslovnih procesov, moramo za vsak proces posebej definirati upravljavce izjem.

Zaradi tega lahko pride do primera, ko moramo isti ali podoben upravljavec izjem

definirati večkrat. Rezultat tega je podvojenost programske kode upravljavcev izjem.

S problemom podvojenosti programske kode so se ukvarjali že številni avtorji in

predhodne empirične raziskave kažejo, da informacijski sistemi v povprečju

vsebujejo med 8% in 23% podvojene programske kode [154, 155]. Podvojenost

programske kode je velik problem in lahko povzroči številne težave [12, 156]:

Poveča se obseg programske kode.

Podaljša čas prevajanja programske kode.

Oteženo je spreminjanje programske kode.

Prisotne so dodatne težave pri vzdrževanju in združevanju programske kode.

Poveča se obseg dela pri prilagoditvah programske kode.

Zaradi omenjenih razlogov je zelo pomembno, da se identificira in zmanjša obseg

podvojenosti programske kode. Če je le možno, je najboljše, da se jo popolnoma

odstrani.

4.1.3 Prepletanje logike poslovnega toka z logiko obravnave izjem

Načrtovanje procesov BPEL zahteva opredelitev konstruktov, ki so namenjeni

implementaciji obravnave izjem (npr. upravljavci izjem) na razmeroma nizkem

nivoju. Zaradi tega pride do prepletanja normalne poslovne logike procesov z logiko

procesa, ki služi obravnavi izjem (npr. upravljavec izjem je definiran neposredno na

nivoju aktivnosti <invoke>). Posledično so razvoj, vzdrževanje in nadgradnja obeh

vrst procesnih logik oteženi [11]. Omenjeno pomanjkljivost so v svojem

raziskovalnem delu izpostavili tudi Liu et al. [28], ki trdijo, da je zaradi tega

implementacija logike obravnave izjem zamudno delo in precej dovzetno za napake. Z

ločitvijo logike normalnega toka poslovnega procesa in logike za obravnavo izjem, kot



predlagamo v naši disertaciji, omogočimo lažje vzdrževanje ter enostavnejše

načrtovanje.

4.2 Formalni model

Da bi lahko predlagali jasen in učinkovit formalni model obravnave izjem znotraj SOA,

moramo najprej opredeliti taksonomijo izjem, ki se pojavljajo pri izvajanju poslovnih

procesov. Izjeme lahko klasificiramo v tri glavne skupine [29] (tehnične, poslovne in

izjeme virov), ki jih tvorijo posamezne izjeme z določeno skupno lastnostjo. Skladno s

tem imamo tri vrste izjem, ki se pojavijo pri izvajanju poslovnih procesov. Dodatno

lahko glede na tip izjeme delimo na pričakovane in nepričakovane. Delitev izjem na

tip je bila uporabljena, ker imajo pričakovane in nepričakovane izjeme značilnosti,

zaradi katerih jih uvrščamo v posebno skupino iste vrste (v našem primeru poslovne,

tehnične in izjeme virov). Formalno lahko nabor izjem predstavimo na naslednji

način:

{ } (4.1)

Kjer je:

– Nabor vseh izjem, ki se zgodijo pri izvajanju poslovnega procesa.

– Posamezna izjema poslovnega procesa.

Kot smo omenili v prejšnjem odstavku, za vsako izjemo velja, da jo lahko klasificiramo

glede na vrsto (v) in tip (t) izjeme. Pri klasifikaciji na vrsto izjeme upoštevamo tri

skupine: tehnične, poslovne in izjeme virov (v jeziku BPEL so opredeljene kot

standardne izjeme). Pri tipu izjeme pa pričakovane in nepričakovane izjeme.

Formalno lahko to predstavimo na naslednji način:

( ) { } { } (4.2)

Kjer je:

– Vrsta izjeme.

– Tip izjeme.

– Tehnične izjeme, ki izhajajo iz napak sistema, strojne in programske

opreme ter okvar v okviru komunikacijske infrastrukture. Napake strojne

opreme nastanejo zaradi nepravilnega delovanja strežnikov, pomnilniških



naprav itd. Napake programske opreme izhajajo iz izvajanja operacijskih

sistemov, podatkovnih baz in vmesne programske opreme.

– Poslovne izjeme (Tabela 2), ki predstavljajo specifične izjeme aplikacij in

nastanejo pri nepravilnem izvajanju partnerskih storitev ali poslovne logike

procesa. Do napak pri izvajanju partnerskih storitev pride takrat, ko storitev

ne zadovolji zahtev poslovnega protokola (npr. izjema rezervacije sobe, do

katere pride, ko so v hotelu vse sobe že zasedene). Izjeme, do katerih pride pri

izvajanju poslovnega procesa, so vzrok neuspešne izvedbe poslovne logike

procesa oz. so posledica kršitev omejitev.

– Izjeme virov, ki nastanejo zaradi nedosegljivosti podatkovnih virov ali

storitev pri izvajanju poslovnih procesov. Izjeme virov lahko delimo na:

nedostopnost storitev, izjeme vsebine storitev, neusklajenost vmesnikov

storitev, izjeme QoS in SLA. Izjeme QoS in SLA nastanejo takrat, ko partnerska

storitev zaključi izvajanje, vendar rezultati izvedbe niso skladni s

pričakovanimi rezultati.

– Pričakovane izjeme, ki so načrtovalcu procesa znane v naprej. Na podlagi

tega lahko načrtovalec procesa vpelje učinkovit mehanizem obravnave izjem.

– Nepričakovane izjeme. Velikokrat za uspešno odpravo zahtevajo

človeško posredovanje.

4.2.1 Uporaba politik obravnave izjem

Kot del formalnega modela definiramo pristop uporabe politik obravnave izjem pri

načrtovanju procesov. Z omenjenim pristopom želimo ločiti logiko normalnega toka

poslovnega procesa in logiko za obravnavo izjem ter tako poenostaviti razvoj

procesov. Številni avtorji [29, 30, 157, 158] zagovarjajo pristop uporabe politik

obravnave izjem, ki temelji na zunanjih upravljavcih izjem. Pristop je dober, a nihče

med njimi še ni predlagal načina, kjer bi politike imele definirane upravljavce izjem.

Opredelitev upravljavcev izjem znotraj politik je smiselna, ker s tem izboljšamo

strukturo procesnih modelov in povečamo njihovo berljivost skozi ponovno

uporabljivost definicij upravljavcev izjem. Formalno lahko nabor politik obravnave

izjem označimo kot:



{ } (4.3)

Kjer je:

P – Nabor vseh politik, ki se uporabijo pri implementaciji poslovnega procesa.

– Posamezna politika.

V raziskovalnem svetu so že velikokrat uporabili pristop uporabe politik, s katerim so

dosegli določene prednosti. Politiko so kot nabor pravil, s katerimi se nadzoruje

izvajanje sistema, že široko uporabili na področju varnosti, upravljanja omrežja in

distribucijskih sistemov [157]. Vpeljava uporabe politik pri obravnavi izjem omogoča

formalno opredelitev deviacijskih situacij in z njimi povezanih upravljavcev izjem.

Politika obravnave izjem prestreže izjemo, ki nastane pri izvajanju sestavljenih

storitev poslovnega procesa, in transparentno zagotavlja strategije obravnave izjem:

( ) (4.4)

Kjer je:

– Enolični identifikator politike obravnave izjem, ki omogoča njeno enolično

naslavljanje pri obravnavi izjem v poslovnem procesu.

– Številka politike obravnave izjem, ki enolično opredeljuje razvoj in

izdajo politike. Številka verzije se določi v naraščajočem vrstnem redu.

– Nabor upravljavcev izjem, ki ob izrednih situacijah izvajanja primerka

poslovnega procesa prevzamejo delo in poskušajo vrniti aktivnosti v ustrezno

stanje, da se lahko izvajanje primerka nadaljuje.

– Nabor strategij obravnave izjem, ki so razvijalcu procesa na voljo pri

vpeljavi učinkovitega mehanizma obravnave izjem. Strategije se lahko

uporabijo posamično ali v medsebojni kombinaciji. Strategije obravnave izjem,

ki so nam na voljo, podrobneje predstavimo v poglavju 4.2.3.

Problem prepletanja logike poslovnega toka z logiko obravnave izjem, ki je opisan v

[28], predstavlja zamudno delo pri načrtovanju poslovnih procesov in povečano

gostoto deviacijskih situacij pri izvajanju primerkov načrtovanih poslovnih procesov.

Razvoj, vzdrževanje in nadgradnja obeh vrst logike je tako precej oteženo, kar je v

svojem raziskovalnem delu izpostavil tudi Hagen [11]. Problem prepletanja logike

poslovnega toka z logiko obravnave izjem je v kontekstu problema obravnave izjem,



ki smo ga zastavili v tej disertaciji, mogoče preoblikovati v ločevanje omenjenih logik

in vpeljati politike obravnave izjem po vzoru [29, 30, 157]. Na ta način naš formalni

model odpravi omenjene težave in vzpostavi učinkovit mehanizem obravnave izjem.

4.2.2 Upravljavci izjem

Če aktivnost, ki je v izvajanju, ne more preiti iz enega stanja v drugo, pomeni, da je

prišlo do izjeme, in stanje aktivnosti se spremeni v pojav izjeme. V primeru, da

aktivnost uspešno zaključi vsa svoja stanja, skozi katera med izvajanjem prehaja, se

izvajanje aktivnosti zaključi normalno. Poslovna definicija aktivnosti je v tem primeru

logično pravilna. Aktivnost se lahko zaključi uspešno tudi v primeru, da vzpostavimo

učinkovit mehanizem obravnave izjem, ki na primeren način obravnava izjeme. Iz

tega sledi, da mora poslovni proces, znotraj katerega obstaja verjetnost nepravilnega

delovanja, za uspešno izvedbo svojega primerka vsebovati zmogljive upravljavce

izjem, ki morajo na formalni način definirati zaznavanje izjem in uporabo strategije za

njihovo obravnavo. Formalno lahko nabor upravljavcev izjem označimo kot:

{ } (4.5)

Kjer je:

– Nabor vseh upravljavcev izjem, ki se uporabijo pri obravnavi izrednih

situacij pri izvajanju primerka poslovnega procesa.

– Posamezen upravljavec izjem.

Konstrukt upravljavec izjem ( ) omogoča izvršljivim procesnim jezikom učinkovito

zaznavanje in obravnavanje izrednih situacij, kjer so lahko te situacije nastale bodisi v

okviru nepravilnega tehničnega (nastanek tehničnih izjem) ali poslovnega (nastanek

poslovnih izjem) izvajanja primerka procesa. Na primer, če želimo iz bančnega

avtomata dvigniti vsoto, ki je višja od dnevnega limita dviga, to povzroči nastanek

poslovne izjeme. Do poslovne izjeme lahko pride tudi v primeru, da bančni avtomat

nima dovolj denarnih zalog. Obe izjemi je potrebno ustrezno obravnavati.

Upravljavec izjem, ki ga opredelimo, omogoča obravnavo izjem na enem mestu brez

nepotrebnega podvajanja. Konstrukt omogoča obravnavo vseh stanj znotraj

aktivnosti procesa in posledično podpira vse vzorce obravnave izjem, predlagane s

strani iniciative WPI. Pri vpeljavi upravljavca izjem smo upoštevali metodo pravila



ECA. Metoda ECA predstavlja vrsto modela za ravnanje z izjemami znotraj poslovnih

procesov, kjer [33]:

dogodek opisuje možne izjeme, ki se lahko pojavijo,

pogoj preveri, če izjeme izpolnjujejo določene pogoje in

akcija se nanaša na ukrepe, ki so načrtovalcu procesa na voljo.

Učinkovitost in smiselnost vzpostavitve pravil ECA pri obravnavi izjem izvršljivih

procesnih modelov je bilo že obravnavano [28, 31, 33, 34]. V našem formalnem

modelu pri upravljavcu izjem vpeljemo razširjeno pravilo ECA (razširili smo z

atributom ) in ga okarakterizirali s takojšnjo obravnavo izjeme. Formalno

lahko upravljavca izjem definiramo kot:

( ) (4.6)

Kjer je:

– Opredeljuje izjemo, ki jo upravljavec izjem obravnava. Znotraj

pravila ECA predstavlja konstrukt dogodka. Konstrukt dogodka opredeljuje

simptome izjem, ki sprožijo pravilo. Upravitelj sistema mora upoštevati dani

dogodek.

– Opredeljuje logični predikat, ki preveri, če kriteriji izjeme

ustrezajo določenim pogojem. Pogoj lahko ima vrednost true ali false. Če je

pogoj ovrednoten kot true, se akcija izvede, v nasprotnem primeru se akcija

preskoči in se ne zgodi nič. Znotraj pravila ECA predstavlja konstrukt pogoj.

– Referenca na enolični identifikator strategije obravnave

izjem, ki jo želimo uporabiti v primeru obravnave izjeme. Znotraj pravila ECA

predstavlja konstrukt akcije. Konstrukt akcija opredeljuje procedure in

postopke, ki morajo biti sproženi v odgovor na pojav izjeme.

– Opredeljuje, ali se ob pojavu izjeme izvajanje primerka

poslovnega procesa prekine ali ne. V primeru, da gre za prekinjajočo

izjemo (angl. interrupting) se izvajanje primerka poslovnega procesa začasno

prekine in izjema se obravnava znotraj upravljavcev izjem. Začasna prekinitev

traja tako dolgo, dokler upravljavec izjem ponovno ne omogoči prehajanje

aktivnosti iz enega stanja v drugega. Drugi tip izjeme, ki se lahko pojavi, je

neprekinjajoča (angl. non-interrupting) izjema. V primeru



neprekinjajoče izjeme ne pride do začasne prekinitve izvajanja primerka

poslovnega procesa, ampak se izvajanje kljub pojavu izjeme nadaljuje. To je

koristno v primeru, ko želimo nadaljevati z izvajanjem in izjemo npr. le

zabeležiti oz. o njej obvestiti administratorja procesa.


Na podlagi zahtev aplikacij SOA (poglavje 3.4) znotraj modela izpostavimo osem

skupnih strategij obravnave izjem, ki jih predstavimo kot aktivnosti obnovitve. Če

obstaja celovit nabor strategij obravnave izjem, s katerimi lahko obravnavamo vse

izjeme, do katerih pride pri izvajanju poslovnega procesa, se lahko primerek

poslovnega procesa zaključi uspešno [32]. Strategije obravnave izjem predstavljajo

nabor strategij, ki definirajo način obravnave izjem, in s tem omogočijo učinkovito

obravnavo izjem. Pri vpeljavi strategij obravnave izjem smo si pomagali z vzorci za

obravnavo izjem znotraj poslovnih procesov, ki smo jih opisali v poglavju 3.5 ter

upoštevali smernice, napotke in predloge avtorjev, ki so v predhodnih raziskovalnih

delih predlagali učinkovite koncepte obravnave izjem poslovnih procesov [29, 30,

157]:

( ) (4.7)

Kjer je:

Ignore – Strategija ne izvede posebnih ukrepov pri obravnavi izjem. Strategija

preprosto ignorira izjemo in omogoči nadaljnje izvajanje poslovnega procesa.

V nekaterih primerih uspešna izvedba poslovnega procesa ne zahteva izvedbe

vseh opravil znotraj procesa. Strategija je tako primerna za obravnavo izjem,

ki nimajo vpliva na končni rezultat.

Notify – Ob pojavu izjeme strategija zabeleži v dnevnik izjem podatke o izjemi

in nadaljuje z izvajanjem procesa.

Skip – Strategija onemogoča izvajanje procesnega toka, ki poteka naprej od

klica storitve, pri kateri je prišlo do izjeme. Strategija je primerna predvsem za

obravnavo izjem SLA.

Retry – Strategija ponavlja izvajanje storitve, dokler se ta uspešno ne izvede

oz. dokler ni izpolnjen pripadajoči pogoj. Pogoj predstavlja dovoljeno število



ponovitev. Nekatere izjeme so začasne (npr. zaradi težav v omrežju končna

točka storitve ni dosegljiva) in obstaja verjetnost, da se v doglednem času ne

bodo več pojavljale.

Alternate – Če pride do napake pri izvajanju storitve, strategija izbere drugo

enakovredno storitev ali funkcijo ter izvede opravilo. Temelj te strategije

predstavljajo storitve, ki izpostavljajo iste oz. podobne funkcionalnosti. Najbolj

splošna oblika strategije predstavlja ponovitev nabora storitev, dokler se ena

ne zaključi uspešno.

Replicate – Strategija istočasno proži več storitev, ki sproducirajo

enakovredne rezultate. V primeru, da ena replicirana storitev uspešno opravi

opravilo, se izvajanje primerka poslovnega procesa nadaljuje.

Wait – Strategija z zamudo pokliče določeno storitev. V nekaterih primerih

imajo poslovne storitve najboljši QoS oz. so na voljo samo v določenem času.

Zato je pomembno, da v določenih trenutkih poslovni proces zadrži izvajanje

nekaterih storitev in s tem zmanjša verjetnost napak.

Repeat – Strategija omogoči ponovitev izvajanja določenega nabora aktivnosti.

Nabor aktivnosti lahko vključuje zaporedne, vzporedne ali hierarhično

gnezdene aktivnosti.

Formalni model je definiran na način, ki dopušča razširljivost množice strategij

obravnave izjem z vpeljavo dodatnih strategij v primeru, da načrtovalci procesa pri

vpeljevanju modela predlagajo nove načine obravnave izjem.



Preslikava predlaganega modela v 5jezik BPEL

Formalni model preslikamo v izvršljiv procesni jezik BPEL z namenom preverjanja

njegove izvedljivosti in učinkovitosti. Pri preslikavi si pomagamo s podporo

specifikacije razširitvenih mehanizmov BPEL. Z omenjeno preslikavo modela tako

preverimo oz. pripravimo osnovo za preverjanje ustreznosti obeh v poglavju 1.2.1

zastavljenih hipotez.

V poglavju 4.1 smo predstavili probleme pri obravnavi izjem procesov BPEL, s

katerimi se srečujejo razvijalci poslovnih procesov. Ugotovili smo, da BPEL ne

zagotavlja učinkovitega mehanizma za samodejno obravnavo izjem. V svojih

raziskovalnih delih sta Liu [35] in Behl [153] že predstavila, da specifikacija BPEL

zagotavlja zelo osnoven in omejen mehanizem za obravnavo izjem in da ne vsebuje

zmogljivih in prilagodljivih mehanizmov obravnave izjem. Z razširitvami BPEL preko

standardnega WS-BPEL 2.0 razširitvenega mehanizma, ki implementirajo v tej

disertaciji predlagan model, se omenjene pomanjkljivosti jezika BPEL odpravijo. Z

vpeljanim ogrodjem obravnave izjem znotraj BPEL lahko celovito in učinkovito

obravnavamo vse vrste izjem, ki nastanejo pri izvajanju primerka poslovnega

procesa. To dosežemo skozi standardiziran način obravnave izjem, t.j. skozi vpeljavo

novih razširitev obstoječih konstruktov BPEL. Kot nov pristop predlagamo uporabo

politik obravnave izjem, ki smo jih formalno opredelili in opisali v poglavju 4.2.1.

Politike obravnave izjem imajo strukturo dokumenta XML (faultPolicy.xml) in

vsebujejo definicijo logike obravnave izjem. Podrobni opis strukture politike

obravnave izjem je predstavljen v poglavju 5.2.1. S predlaganim pristopom izluščimo

logiko obravnave izjem iz logike delovanja poslovnega procesa v ločen, ponovno

uporabljiv dokument in posledično povečamo berljivost kode BPEL. Vpeljemo tudi

nove strategije obravnave izjem. Slika 17 prikazuje visokonivojski pregled

predlaganih konceptov razširitve jezika BPEL.



Slika 17: Visokonivojski pregled predlaganih konceptov razširitve jezika BPEL.

Strategije alternate, replicate, wait in skip jezik BPEL že podpira.

Posledično jih pri preslikavi formalnega modela v jezik BPEL ni bilo potrebno

vključiti. To je tudi razlog, da jih Slika 17 ne prikazuje. Strategije obravnave izjem, ki

smo jih vključili pri preslikavi modela so: retry, logger, notification,

repeat, propagate.

5.1 Deklaracija razširljivosti jezika BPEL

Jezik BPEL v verziji 2.0 [70] je načrtovan in grajen na način, ki omogoča razširljivost

obstoječih konstruktov s pomočjo uporabe razpoložljivega mehanizma razširljivosti.

Možne razširitve vključujejo:

Dodajanje novih atributov (nahajati se morajo v ustreznem imenskem

prostoru (angl. namespace)) k obstoječim elementom BPEL.

Dodajanje novih elementov iz drugih imenskih prostorov.

Razširjanje prireditvenih operacij in aktivnosti.

Omogočanje omejevanja in razširjanja obnašanja poslovnega procesa med

časom izvajanja.

proces BPEL

<scope>

<invoke>

politika obravnave izjem

upravljavci izjem

strategije obravnave izjem

Retry Logger Notification Repeat Propagate

izjema

izjemasamodejnaobravnava

izjem



Z vključitvijo elementa <extension> na nivoju procesa deklariramo unikatni

imenski prostor, ki vsebuje razširjene elemente ali atribute.

Izsek 7: Uporaba standardnega mehanizma razširljivosti BPEL.

Posamezne razširitve so lahko opredeljene kot opcijske ali pa obvezne. To

omogočimo z uporabo atributa mustUnderstand, kjer določimo, ali mora procesni

strežnik BPEL nujno razumeti naše razširitve ali ne. Če je vrednost atributa »yes«,

mora procesni strežnik BPEL razširitve razumeti. V primeru, da razširitve niso

podprte s strani implementacije BPEL, mora procesni strežnik BPEL poskrbeti, da se

definicija procesa zavrne. Če je vrednost atributa mustUnderstand="no", so

razširitve opcijske, procesni strežnik pa izvaja definicijo procesa, kot da ne vsebuje

razširitev.

Dodatno BPEL omogoča dva eksplicitna razširitvena konstrukta:

<extensionAssignOperation> in <extensionActivity>. Element

<extensionActivity> se uporabi za uvajanje nove vrste aktivnosti znotraj BPEL.

Vsebina elementa <extensionActivity> mora biti enonivojski element, ki ima na

voljo standardne atribute in elemente BPEL.

Izsek 8: Sintaksa razširljive aktivnosti <extensionActivity>.

V splošnem ločimo dve različni metodi implementacije razširitev jezika BPEL [41]:

Razširitev procesnega strežnika BPEL z namenom vzpostavitve podpore

dodatnih funkcionalnosti. Predstavlja celovito in dosledno integracijo

razširitev z orodji za modeliranje procesov in procesnimi strežniki. Omenjen

pristop zahteva velik napor razvoja.

<process ...>

...

<extensions>?

<extension namespace="anyURI" mustUnderstand="yes|no" />+

</extensions>

...

</process>

<extensionActivity>

<anyElementQName standard-attributes>

standard-elements

</anyElementQName >

</extensionActivity>



Razvoj dodanih orodij transformacije, ki prevajajo razširitvene konstrukte

v standardne konstrukte jezika BPEL. Metoda zagotavlja visoko stopnjo

ponovne uporabljivosti programske kode, združljivost in skladno s tem

prenosljivost kode BPEL na različne procesne strežnike BPEL (pri prenosu

kode BPEL je potrebno upoštevati tudi zahteve posameznih ponudnikov

procesnih strežnikov). Prvotni konstrukti BPEL se nadomestijo z novimi

konstrukti (npr. definicije spremenljivk ali aktivnosti) in posledično prvotni

konstrukti ne predstavljajo funkcionalnosti, za katere so dejansko bili

namenjeni. Zamenjava konstruktov vpliva tudi na mehanizme spremljanja in

razhroščevanja poslovnih procesov, kar predstavlja bistveno pomanjkljivost

omenjene metode.

5.2 Realizacija politik obravnave izjem

5.2.1 Struktura politike obravnave izjem

Politika obravnave izjem definira upravljavce izjem in ustrezne obnovitvene akcije za

obravnavo izjem, ki se uporabijo v procesu BPEL. Izsek 9 prikazuje strukturo politike

obravnave izjem. Za zapis vsake politike uporabimo razširljiv označevalni jezik XML

[13], ki predstavlja enostaven format za opisovanje strukturiranih

podatkov, arhitekturo za prenos podatkov in njihovo izmenjavo med več omrežji.

Tabela 5 predstavlja preslikavo posameznih gradnikov politike iz formalnega modela

(predstavljen v poglavju 4.2) v izvršljiv jezik BPEL.

Tabela 5: Preslikava strukture politike iz formalnega jezika v jezik BPEL.

Formalni model BPEL 2.0

p <bpelx:faultPolicy>

id atribut bpelx:idFaultPolicy

verzija atribut bpelx:version

u <faultHandlers>

<bpelx:actions>



Vsaka politika obravnave izjem je opredeljena z uporabo korenskega elementa

<bpelx:faultPolicy>. Element <bpelx:faultPolicy> mora poleg

standardnih atributov (name in suppressJoinFailure) vsebovati naslednja dva

atributa: bpelx:version in bpelx:idFaultPolicy. Atribut bpelx:version

predstavlja verzijo politike obravnave izjem, kar pride v poštev predvsem pri

arhiviranju. Atribut bpelx:idFaultPolicy enolično identificira posamezno

politiko obravnave izjem in s tem omogoča njeno enolično naslavljanje v poslovnem

procesu. Upravljavci izjem, katerih naloga je zaznava, prestrezanje in obravnava

izjem, so predstavljeni z obstoječim konstruktom BPEL (<faultHandlers>).

Konstrukt <faultHandlers> predstavlja standardni konstrukt za obravnavo izjem

znotraj procesov BPEL. Znotraj konstrukta <faultHandlers> lahko uporabimo vse

standardne aktivnosti BPEL. Da lahko obravnavamo celotno množico izjem

(pričakovanih in nepričakovanih) znotraj konstrukta <faultHandlers>

uporabimo obstoječi aktivnosti <catch> in <catchAll>. Aktivnost <catch>

uporabimo za obravnavo pričakovanih izjem, medtem ko aktivnost <catchAll>

uporabimo pri obravnavi nepričakovanih izjem. Obstoječi aktivnosti <catch> in

<catchAll> razširimo z uporabo novega atributa bpelx:faultType. Vpeljava

atributa bpelx:faultType nam omogoči opredelitev, če je upravljavec izjem

prekinjajoč ali neprekinjajoč. Če gre za prekinjajoč upravljavec izjem, ima atribut

bpelx:faultType vrednost interrupting. V nasprotnem primeru ima atribut

bpelx:faultType vrednost non-interrupting. Pristop razširitve upravljavca

izjem na prekinjajoč in neprekinjajoč je koristen predvsem v primeru, ko želimo ob

pojavu izjeme, ki je ne rešimo uspešno, nadaljevati z izvajanjem poslovnega procesa.

Če izjema ni uspešno rešena, prekinjajoč upravljavec izjem zaključi izvajanje obsega

oz. procesa, medtem, ko neprekinjajoč upravljavec izjem nadaljuje z izvajanje obsega

oz. procesa.



Izsek 9: Struktura politike obravnave izjem.

<?xml version="1.0" encoding="utf-8"?>

<bpelx:faultPolicy xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns="http://feri.uni-mb.si/bpel2.0/faultPolicy"

bpelx:version="version"

bpelx:idFaultPolicy="fault-policy-identifier">

<faultHandlers>

<catch faultName="QName" faultVariable="BPELVariableName"?

( faultMessageType="QName" |faultElement="QName"

bpelx:faultType="interrupting|non-interrupting" )? >*

activity

</catch>

<catchAll bpelx:faultType="interrupting|non-interrupting" >?

activity

</catchAll>

</faultHandlers>

<bpelx:actions>

<bpelx:action bpelx:idAction="retry-action-identifier">

<bpelx:retry>

<bpelx:interval />

<bpelx:count />

<bpelx:exponentialIncreaseFactor />

</bpelx:retry>

</bpelx:action>

<bpelx:action bpelx:idAction="logger-action-identifier">

<bpelx:logger type="QName">

logger-name

</bpelx:logger>

</bpelx:action>

<bpelx:action bpelx:idAction="notification-action-identifier">

<bpelx:notification>

<bpelx:mail>?

<bpelx:mailFrom />

<bpelx:mailTo />

<bpelx:mailCC />

<bpelx:mailSubject />

<bpelx:mailBody />

<bpelx:Date />

</bpelx:mail>

<bpelx:sms>?

<bpelx:smsFrom />

<bpelx:smsTo />

<bpelx:smsBody />

</bpelx:sms>

</bpelx:notification>

</bpelx:action>

<bpelx:action bpelx:idAction="propagate-action-identifier">

<bpelx:repeat />

</bpelx:action>


<bpelx:propagate />

</bpelx:action>

</bpelx:actions>

</bpelx:faultPolicy>

5.2.2 Vključitev politike obravnave izjem znotraj procesa BPEL

Da se omogoči uporaba politik znotraj procesa BPEL, je potrebno vzpostaviti

medsebojno povezavo. To dosežemo z uporabo aktivnosti <import>. Izsek 10

prikazuje primer visokonivojskega pogleda na proces BPEL, ki s predlaganimi

razširitvami omogoči uporabo politik pri obravnavi izjem. Specifikacija BPEL

opredeljuje, da lahko razvijalci procesa uporabijo poljubno število aktivnosti

<import> znotraj aktivnosti <process> [70]. Skladno s tem lahko uporabijo več

kot eno politiko znotraj posameznega procesa BPEL in s tem podpremo domensko

uporabo politik (npr. politike obravnave izjem lahko razčlenimo na manjše segmente,

ki so razdeljeni glede na področje uporabe). Aktivnost <import> vsebuje en obvezen

(importType) in dva opcijska atributa (namespace in location). Atribut

namespace opredeljuje enotni označevalnik vira (angl. Uniform Resource

Identifier, krat. URI), ki identificira vključene definicije. Atribut location vsebuje

URI, ki določa lokacijo dokumenta z ustreznimi definicijami [70]. V atributu

importType moramo navesti imensko področje razširitev.

Izsek 10: Vključitev politik obravnave izjem v jezik BPEL.

V primeru, da so politike obravnave izjem definirane in vključene znotraj procesa,

razširjeni mehanizem obravnave izjem prestreže izjeme, še preden se sproži

standardni mehanizem obravnave izjem BPEL. To pomeni, da razširjeni mehanizem

obravnave izjem prestreže izjeme in omogoči, da pripadajoča logika obravnave izjem

<process name="purchaseOrderProcess" targetNamespace="http://example.com/ws-bp/purchase"

xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"

xmlns:lns="http://manufacturing.org/wsdl/purchase"

xmlns:bpelx="http://feri.uni-mb.si/bpel2.0/faultExtension">

<import namespace="http://soa.si/ext/bpel/faultHandling/"

location="faultPolicy.xml"

importType="http://feri.uni-mb.si/bpel2.0/faultPolicy" />

<partnerLinks>...</partnerLinks>

<messageExchanges>...</messageExchanges>

<variables>...</variables>

<correlationSets>...</correlationSets>

<faultHandlers>...</faultHandlers>

<eventHandlers>...</eventHandlers>



</process>



na ustrezen način obravnava in odstrani izjeme iz izvajanja primerka poslovnega

procesa. Izjema se lahko obravnava znotraj razširjenega mehanizma le v primeru, da

so upravljavci izjem, ki so namenjeni zaznavi in obravnavi omenjene izjeme,

opredeljeni znotraj politik. V primeru, da politika obravnave izjem ne definira

upravljavcev izjem za specifično izjemo, se sproži standardni mehanizem obravnave

izjem BPEL, ki poskrbi za pravilno obravnavo izjeme. Pristop vključitve politike

obravnave izjem znotraj procesa BPEL, ki ga predlagamo, omogoča uporabo

posamezne politike znotraj celotnega procesa in ne samo znotraj posameznih

aktivnosti (npr. <invoke>, <reply>).

Ker predlagamo opredelitev upravljavcev izjem znotraj politike, s čimer odpravimo

pomanjkljivost podvajanja programske kode obravnave izjem, je potrebno

specificirati tudi politike za tiste upravljavce izjem, ki se uporabljajo znotraj obsega

(aktivnost <scope>). Znotraj BPEL obseg predstavlja glavni mehanizem za

razdelitev procesnega toka na manjše hierarhične enote. Obseg je razdeljen na

naslednje štiri dele: telo (angl. main body), upravljavci dogodkov (angl. event

handlers), upravljavci kompenzacije (angl. compensation handlers) in upravljavci

izjem [139]. V primeru, da imamo definirano politiko, ki vsebuje upravljavce izjem, ki

se uporabljajo znotraj obsega, moramo dodatno vzpostaviti povezavo med politiko in

obsegom. To dosežemo z razširitvijo aktivnosti <scope>, s katero vpeljemo nov

atribut bpelx:refFaultPolicy, katerega vrednost je referenca na vključeno

politiko. S sklicevanjem obsega na politiko obravnave izjem smo omogočili uporabo

posamezne politike za vse aktivnosti znotraj specifičnega obsega. Izsek 11 prikazuje

primer visokonivojskega pogleda na proces BPEL, znotraj katerega z razširitvijo

omogočimo uporabo politik obravnave izjem znotraj obsega. Vsak obseg se lahko

sklicuje samo na eno politiko. Vendar uporaba večjega števila obsegov znotraj

procesa omogoča tudi vpeljavo večjega števila politik. Predlagamo, da vsaka politika

obravnave izjem zajema svojo domensko področje. S tem omogočimo vzpostavitev

standardnih politik obravnave izjem in njihovo uporabo znotraj različnih poslovnih

procesov.



Izsek 11: Uporaba politik obravnave izjem znotraj obsega.

5.2.3 Nevsiljiva uporaba politik obravnave izjem znotraj procesa

BPEL

Dodatna prednost predlagane rešitve je naslednja: Vključitev razširjenega

mehanizma obravnave izjem znotraj BPEL ne vpliva na uporabo standardnega

pristopa obravnave izjem BPEL. Skladno s tem je načrtovanje poslovnih procesov

BPEL z uporabo aktivnosti <catch> in <catchAll> znotraj aktivnosti

<process>, <scope> ali <invoke> še vedno omogočeno. Glede na zahteve lahko

določimo, kateri mehanizem obravnave izjem (razširjeni ali standardni BPEL) se bo

uporabljal. To lahko določimo z uporabo predlagane strategije obravnave izjem

<bpelx:propagate>, ki je definirana znotraj politike. Če je strategija

<bpelx:propagate> uporabljena, se izjema pošlje naprej do standardnega

mehanizma obravnave izjem BPEL, ki obravnava izjemo. V nasprotnem primeru se bo

izjema obravnavala znotraj razširjenega mehanizma obravnave izjem. Če politike

znotraj procesa BPEL niso vključene, bo izjema prav tako obravnavna s strani

standardnega mehanizma obravnave izjem BPEL.

<process name="purchaseOrderProcess" targetNamespace="http://example.com/ws-bp/

purchase"

xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"

xmlns:lns="http://manufacturing.org/wsdl/purchase"

xmlns:bpelx="http://feri.uni-mb.si/bpel2.0/faultExtension">

<import namespace="http://soa.si/ext/bpel/faultHandling/"

location="faultPolicy.xml"

importType="http://feri.uni-mb.si/bpel2.0/faultPolicy" />

<partnerLinks>...</partnerLinks>

<messageExchanges>...</messageExchanges>

<variables>...</variables>

<correlationSets>...</correlationSets>

<faultHandlers>...</faultHandlers>

<eventHandlers>...</eventHandlers>

<scope isolated="yes|no"? exitOnStandardFault="yes|no"?

standard-attributes

bpelx:refFaultPolicy="http://feri.uni-mb.si/bpel2.0/faultPolicy">


</scope>


</process>



5.2.4 Obravnava izjem z uporabo upravljavca izjem znotraj politik

obravnave izjem

V nadaljevanju opišemo, na kakšen način se izjeme obravnavajo. V primeru, da v času

izvajanja primerka poslovnega procesa pride do izjeme, razširjeni mehanizem

obravnave izjem prestreže izjemo in izvede ustrezno logiko obravnave, ki je

opredeljena znotraj politik. Razširjeni mehanizem obravnave izjem ima možnost

zaznave izjem znotraj enega ali več upravljavec izjem, opredeljenih znotraj politik. Za

uspešno zaznavo izjem uporabimo obstoječe upravljavce BPEL

(<faultHandlers>), ki so opredeljeni z aktivnostma <catch> in <catchAll>.

Obstoječi aktivnosti <catch> in <catchAll> razširimo z dodajanjem novega

atributa bpelx:faultType. Izsek 12 prikazuje primer sintakse predlagane

razširitve. Atribut bpelx:faultType določa, če je upravljavec izjem prekinjajoč ali

neprekinjajoč. Če je vrednost atributa bpelx:faultType interrupting, pomeni,

da gre za prekinjajoč upravljavec izjem. V takem primeru se izvajanje primerka

poslovnega procesa začasno prekine, izjema pa se obravnava znotraj upravljavcev

izjem. Začasna prekinitev traja tako dolgo, dokler upravljavec izjem ne omogoči

ponovnega prehajanja aktivnosti iz enega stanja v drugega. V primeru, da je vrednost

atributa bpelx:faultType non-interrupting se izvajanje primerka

poslovnega procesa začasno ne prekine, ampak se izvajanje kljub pojavu izjeme

nadaljuje.



Izsek 12: Razširjen upravljavec izjem.

Dodatno imajo načrtovalci procesa pri obravnavi izjem možnost uporabe strategij

obravnave izjem, ki so podrobneje opisane v poglavju 5.3.1. Uporaba strategij

obravnave izjem je omogočena z vpeljavo nove aktivnosti <bpelx:action> znotraj

aktivnosti <catch> ali <catchAll> (Izsek 12). Aktivnost <bpelx:action>

vsebuje atribut ref, ki ima za vrednost referenco na strategijo obravnave izjem (npr.

<bpelx:action ref="retry-action-identifier">). Potrebno je opozoriti,

da lahko upravljavec izjem izvede poizvedbo samo na spremenljivki, ki je dosegljiva

znotraj izjeme.

5.3 Realizacija strategij obravnave izjem


Obnovitvene akcije za obravnavo izjem ponujajo dodatne funkcionalnosti, ki jih za

izboljšano obravnavo izjem uporabijo načrtovalci procesa. Kot lahko vidimo v

poglavju 4.2.3, predlagan formalni model predstavlja različne strategije obravnave

izjem. Nekatere (alternate, replicate, wait in skip) od njih jezik BPEL že

podpira. Strategiji alternate in replicate lahko vpeljemo z uporabo aktivnosti

<faultHandlers>

<catch faultName="QName" faultVariable="BPELVariableName"?

( faultMessageType="QName" |faultElement="QName" )?

bpelx:faultType="interrupting|non-interrupting" >*

...

<bpelx:action ref="retry-action-identifier">

...

</catch>

<catchAll bpelx:faultType="interrupting|non-interrupting" >?

activity

</catchAll>

</faultHandlers>

<bpelx:actions>


...

</bpelx:action>

<bpelx:action bpelx:idAction="logger-action-identifier2">

...

</bpelx:action>

...

</bpelx:actions>

<invoke> znotraj upravljavca izjem, strategijo skip pa z uporabo konstruktov

link. Za uporabo strategije wait jezik BPEL predvideva aktivnost <wait>.

Za vpeljavo ostalih strategij obravnave izjem razširimo jezik BPEL z vpeljavo

vsebnika <bpelx:actions>. Vsebnik <bpelx:actions> določa pet različnih

vrst strategij obravnave izjem, ki so vključene v politiko obravnave izjem in so

dodatno na voljo načrtovalcu procesov kot prikazuje Izsek 13. Za razrešitev izjem

znotraj delujočega procesa mora vsebnik <bpelx:actions> vsebovati niz različnih

aktivnosti imenovanih <bpelx:action>. Aktivnost <bpelx:action> je na novo

dodana aktivnost v jezik BPEL z namenom modeliranja strategij obravnave izjem

znotraj poslovnih procesov BPEL.

Izsek 13: Vpeljane strategije obravnave izjem v jezik BPEL.

Posamezna strategija obravnave izjem mora vsebovati enolični identifikator

(omogoča identifikacijo strategije obravnave izjem) ter specifikacijo strategije

obravnave izjem, ki določa, na kakšen način se bo izjema obravnavala. S tem

namenom smo v aktivnost <bpelx:action> vključili atribut bpelx:idAction, ki

enolično določa vsako strategijo. Dodatno se atribut uporablja za referenco med

<bpelx:actions>

<bpelx:action bpelx:idAction="retry-action-identifier">*

<bpelx:retry>



</bpelx:retry>

</bpelx:action>

<bpelx:action bpelx:idAction="logger-action-identifier">*

<bpelx:logger>



</bpelx:logger>

</bpelx:action>

<bpelx:action bpelx:idAction="notification-action-identifier">*





</bpelx:action>

<bpelx:action bpelx:idAction="repeat-action-identifier">*

<bpelx:repeat />

</bpelx:action>

<bpelx:action bpelx:idAction="propagate-action-identifier">*

<bpelx:propagate />

</bpelx:action>

</bpelx:actions>



upravljavci izjem in strategijami obravnave izjem. Različni upravljavci izjem se lahko

sklicujejo na iste strategije obravnave izjem. Dodano vpeljemo naslednje specifikacije

strategije obravnave izjem: <bpelx:retry>, <bpelx:notification>,

<bpelx:logger>, <bpelx:repeat> in <bpelx:propagate> [124]. Znotraj

politik je uporaba posamezne strategije opcijska. Posamezna strategija obravnave

izjem se lahko definira večkrat, vendar moramo biti pozorni, da ima posamezna

strategija svoj enolični identifikator. Tabela 6 predstavlja preslikavo posameznih

strategij obravnave izjem iz formalnega modela (predstavljene v poglavju 4.2.3) v

jezik BPEL. Preslikali smo štiri strategije (ponovno proženje aktivnosti, beleženje

izjem, ponovitev obsega in obveščanje administratorja) in dodali eno novo (pošiljanje

izjem naprej do standardnega mehanizma obravnave izjem BPEL –

<bpelx:propagate>). Strategija <bpelx:propagate> znotraj formalnega

modela ni definirana, saj njena uporaba dejansko pomeni obravnavo izjem brez

formalnega modela.

Tabela 6: Preslikava strategij obravnave izjem iz formalnega modela v jezik BPEL.

Formalni model BPEL 2.0

Retry, Wait <bpelx:retry>

Ignore <bpelx:logger>

Notify <bpelx:notification>

Repeat <bpelx:repeat>

Strategija ni definirana znotraj

formalnega modela.

<bpelx:propagate>

5.3.2 Ponovno proženje aktivnosti

Aktivnost <bpelx:retry> omogoča ponovno proženje aktivnosti oz. obsega.

Izkušnje in študije so pokazale, da so sistemi s kompleksnimi interaktivnimi

aktivnostmi zaradi svoje izjemne kompleksnosti in dolgotrajnih procesov zelo

izpostavljeni napakam [4]. Pomembno je, da se primerki poslovnih procesov ob

pojavu izjeme ne prekinejo ali nepravilno zaključijo. Ena izmed strategij, ki to

preprečuje, je ponovitev aktivnosti ali obsega, ki je povzročil izjemo. Da to dosežemo,

preslikamo strategijo retry iz formalnega modela v element <bpelx:retry>, ki



omogoča ponovno izvedbo aktivnosti. Aktivnost <bpelx:retry> ima naslednje

elemente: <bpelx:interval>, <bpelx:count> in

<bpelx:exponentialIncreaseFactor>. Kjer:

<bpelx:interval> - Definira zakasnitveni čas med ponovitvami (v

milisekundah).

<bpelx:count> - Določa največje število ponovitev.

<bpelx:exponentialIncreaseFactor> - Definira faktor, ki

eksponentno povečuje zakasnitveni čas ponovitve.

V primeru, da imamo vrednost intervala 3000 milisekund in faktor eksponentnega

povečanja, ki ima vrednost 2, je naslednja ponovitev predvidena v 6000

milisekundah, naslednja v 12000 milisekundah in tako naprej, dokler ne dosežemo

vrednosti števila ponovitev ali uspešno izvedbo spletne storitve. Če vrednost faktorja

eksponentnega povečanja ni določena, se uporabi privzeta vrednost 1. Izsek 14

prikazuje primer sintakse na novo vpeljane strategije obravnave izjem (Ponovno

proženje aktivnosti).

Izsek 14: Primer sintakse strategije obravnave izjem - Ponovno proženje aktivnosti.

5.3.3 Beleženje izjem

Beleženje omogoča zapis izvajanja poslovnih procesov v dnevnik izjem. Beleženje

lahko uporabimo v naslednjih dveh primerih: (1) aktivnost je uspešno zaključila z

izvajanjem ali (2) na aktivnosti pride do izjeme. Izsek 15 prikazuje primer sintakse na

novo vpeljane strategije obravnave izjem (Beleženje izjem). Ob pojavu izjeme se

običajno izvajanje primerka poslovnega procesa zaključi. V določenih primerih (npr.

kadar do izjeme pride na nepomembni aktivnosti znotraj kontrolnega toka procesa)

si tega ne želimo in je zato zelo koristno, če sistem izjemo le zabeleži v dnevnik izjem,

medtem ko primerek procesa nadaljuje z izvajanjem. Administratorji procesa imajo


<bpelx:retry>

<bpelx:interval />

<bpelx:count />

<bpelx:exponentialIncreaseFactor />

</bpelx:retry>

</bpelx:action>



kasneje možnost pogleda v dnevnik izjem in, če je potrebno, tudi ustrezno ukrepati.

Znotraj BPEL smo beleženje izjem dosegli s preslikavo strategije notify iz

formalnega modela v aktivnost <bpelx:logger>. Vrednost aktivnosti

<bpelx:logger> predstavlja referenco na dnevnik izjem, ki ga predhodno

konfiguriramo na procesnem strežniku kot vir, ki je na razpolago poslovnim

procesom.

Izsek 15: Primer sintakse strategije obravnave izjem – Beleženje izjem.

5.3.4 Obveščanje administratorjev procesa

Z uporabo aktivnosti <bpelx:notification> omogočimo obveščanje

administratorjev procesa o izjemah, nastalih pri izvajanju primerka poslovnega

procesa. Obveščanje je možno po dveh različnih komunikacijskih kanalih: (1)

elektronska pošta in (2) sporočila SMS (Short Message Service). Če želimo uporabiti

obveščanje preko elektronske pošte, moramo definirati konstrukt <bpelx:mail>,

ki je sestavljen iz naslednjih označb XML: <bpelx:mailFrom> (elektronski naslov

pošiljatelja), <bpelx:mailTo> (elektronski naslov prejemnika),

<bpelx:mailCC> (elektronski naslov prejemnikov kopije sporočila),

<bpelx:mailSubject> (zadeva elektronske pošte), <bpelx:mailBody>

(vsebina elektronske pošte) in <bpelx:Date> (datum in čas pošiljanja elektronske

pošte, ki se določi preko XPath). Za vsebino in zadevo elektronske pošte se lahko

uporabi golo (angl. plain) ali dinamično besedilo. Poizvedbe XPath se lahko vršijo

samo nad spremenljivkami izjem, ki so na voljo znotraj same izjeme. V primeru

pošiljanja sporočil SMS moramo specificirati element <bpelx:SMS>. Element

<bpelx:SMS> vsebuje naslednje označbe XML: <bpelx:smsFrom> (številka SMS

pošiljatelja), <bpelx:smsTo> (številka SMS prejemnika) in <bpelx:smsBody>

(vsebina sporočila SMS). Vsebina sporočila SMS je lahko prav tako golo ali dinamično

besedilo. Izsek 16 prikazuje primer sintakse na novo vpeljane strategije obravnave

izjem (Obveščanje administratorja procesa).

<bpelx:action bpelx:idAction="logger-action-identifier">

<bpelx:logger type="QName">

logger-name

</bpelx:logger>

</bpelx:action>



Izsek 16: Primer sintakse strategije obravnave izjem – Obveščanje administratorja procesa.

5.3.5 Ponovitev obsega BPEL

Uporaba aktivnosti <bpelx:repeat> omogoči ponovitev obsega BPEL, v katerem je

prišlo do izjeme. Izsek 17 prikazuje primer sintakse na novo vpeljane strategije

obravnave izjem (Ponovitev obsega BPEL). V primeru, da imamo hierarhično gnezden

obseg, ki ima poljubno globino, moramo biti previdni, kateri obseg želimo ponovno

izvesti. Če želimo ponoviti le obseg, v katerem je prišlo do izjeme, lahko preprosto

uporabimo predlagano aktivnost <bpelx:repeat>. V nasprotnem primeru

moramo isto izjemo ponovno prožiti (znotraj upravljavca izjem uporabimo aktivnost

<rethrow>), ujeti izjeme v zgornjem obsegu in postopek ponavljati dokler ne

dosežemo ciljnega obsega. V ciljnem obsegu nato uporabimo aktivnost

<bpelx:repat> in ponovimo izvajanje celotnega obsega.

Izsek 17: Primer sintakse strategije obravnave izjem – Ponovitev obsega BPEL.

5.3.6 Pošiljanje izjem naprej do standardnega mehanizma

obravnave izjem BPEL

Razširjeni mehanizem obravnave izjem ima možnost pošiljanja izjem naprej do

standardnega mehanizma obravnave izjem BPEL. Izsek 18 prikazuje primer sintakse

<bpelx:action bpelx:idAction="notification-action-identifier">


<bpelx:mail>?

<bpelx:mailFrom />

<bpelx:mailTo />

<bpelx:mailCC />

<bpelx:mailSubject />

<bpelx:mailBody />

<bpelx:Date />

</bpelx:mail>

<bpelx:sms>?

<bpelx:smsFrom />

<bpelx:smsTo />

<bpelx:smsBody />

</bpelx:sms>


</bpelx:action>


<bpelx:repeat />

</bpelx:action>



na novo vpeljane strategije obravnave izjem (Pošiljanje izjem naprej do standardnega

mehanizma obravnave izjem BPEL). Kot primer lahko predstavimo upravljavec izjem,

ki je opredeljen znotraj politike in vsebuje v zaporednem vrstnem redu naslednje

strategije obravnave izjem: ponovno proženje aktivnosti (aktivnost

<bpelx:retry>), beleženje (aktivnost <bpelx:logger>), obveščanje (aktivnost

<bpelx:notification>) in pošiljanje izjem naprej do standardnega mehanizma

obravnave izjem BPEL (aktivnost <bpelx:propagate>). Ko pride do izjeme,

najprej želimo ponoviti obseg ali aktivnost BPEL. V primeru, da ponovitev ne uspe,

zabeležimo izjemo, o njej obvestimo administratorja procesa in na koncu

posredujemo izjemo naprej do standardnega mehanizma obravnave izjem BPEL.

Izsek 18: Primer sintakse strategije obravnave izjem – Pošiljanje izjem naprej.


<bpelx:propagate />

</bpelx:action>



Ovrednotenje učinkovitosti 6predlagane rešitve in analiza rezultatov

Potrebno je preveriti, če formalna rešitev, ki smo jo predlagali, predstavlja učinkovito

rešitev obravnave izjem znotraj storitveno usmerjene arhitekture. V ta namen smo

predlagano rešitev ovrednotili z uporabo različnih procesnih metrik. Procesne

metrike so podrobneje predstavljene v poglavju 6.3.2. Postopek ovrednotenja

učinkovitosti rešitve je potekal v petih fazah (Slika 18):

1. Zbiranje procesnih modelov za ovrednotenje učinkovitosti predlagane rešitve.

Zberemo nerazširjene procesne modele BPEL, ki jih vključimo in uporabimo

pri meritvah.

2. Priprava nabora in razširitev procesnih modelov.

Nerazširjene procesne modele razširimo na podlagi formalnega modela, ki

smo ga definirali v tej disertaciji.

Preverimo, če so procesni modeli pripravljeni na izvedbo meritev. Procesni

modeli so pripravljeni na meritev takrat, ko obstaja izvršljivost procesnih

modelov.

V primeru, da procesni modeli so pripravljeni na izvedbo meritev,

nadaljujemo s postopkom ovrednotenja. V nasprotnem primeru se vrnemo na

začetek postopka.

3. Identifikacija in izbira metrik za merjenje kompleksnosti procesnih modelov.

Izmed identificiranih procesnih metrik izberemo najustreznejše za

preverjanje učinkovitosti našega formalnega modela.

4. Izvajanje meritev kompleksnosti procesnih modelov.

Izvedemo meritve kompleksnosti razširjenih in nerazširjenih procesnih

modelov.

5. Analiza pridobljenih rezultatov.

Grafična in tabelarična predstavitev rezultatov analize.



Slika 18: Postopek ovrednotenja učinkovitosti rešitve.

Zbiranje procesnih modelov za ovrednotenje učinkovitosti

predlagane rešitve

Priprava in razširitev nabora procesnih modelov

Procesni modeli pripravljeni za

izvedbo meritev?

Identifikacija in izbira metrik za merjenje kompleksnosti

procesnih modelov

Izvajanje meritev kompleksnosti procesnih

modelov

Analiza pridobljenih rezultatov

Nerazširjeni procesni modeli

Razširjeni procesni modeli

Procesni modeli niso pripravljeni za izvedbo meritev

Procesni modeli so pripravljeni za izvedbo meritev

Procesne metrike



6.1 Zbiranje procesnih modelov za ovrednotenje

učinkovitosti predlagane rešitve

Da bi pokazali uporabnost in učinkovitost predlagane rešitve, smo razširili obstoječe

poslovne procese BPEL. Kot del tega postopka smo morali najprej identificirati in

izbrati poslovne procese, nad katerimi smo kasneje izvedli meritve kompleksnosti

poslovnih procesov. Pri postopku ovrednotenja smo uporabili 37 poslovnih procesov

s področja telekomunikacij in 54 poslovnih procesov s področja distribucije

električne energije. Da so rezultati čim bolj verodostojni, smo uporabili realne

procese, ki smo jih v preteklosti znotraj našega raziskovalnega laboratorija

implementirali pri aplikativnih projektih. Zaradi posebnih poslovnih zahtev je bila

večina izbranih poslovnih procesov dolgotrajnih (ang. long running).

6.2 Priprava nabora in razširitev procesnih modelov

Opravili smo podroben pregled vsakega poslovnega procesa. Posledično smo uspeli

identificirati in locirati vse upravljavce izjem (eksplicitne in implicitne). Skladno s

tem so za obravnavo izjem bile uporabljene aktivnosti <faultHandlers>,

<catch> in <catchAll>.

Pri analizi načina obravnave izjem znotraj izbranih poslovnih procesov smo ugotovili,

da se mnogi pojavljajo večkrat. Kot smo že podrobneje obravnavali v poglavju 4.1.2,

lahko podvojenost programske kode predstavlja velike težave pri vzdrževanju

poslovnih sistemov, kar se odseva v obliki slabe implementacije poslovnih procesov.

Za boljšo preglednost vsebine poslovnih procesov, razumevanja mehanizma

obravnave izjem in vsebinske kategorizacije poslovnih procesov ter njihovih načinov

obravnave izjem smo celoten nabor poslovnih procesov najprej razdelili na

naslednjih pet področij:

Tržno področje. Vključuje poslovne procese, ki podpirajo prodajo in

marketinške aktivnosti. Znotraj tega področja smo imeli 25 procesov.



Področje upravljanja produktov. Vključuje poslovne procese, ki podpirajo

razvoj in upravljanje produktov. Znotraj tega področja smo imeli 16 procesov

BPEL.

Področje upravljanja strank. Vključuje poslovne procese, ki so potrebni za

ohranjanje in izboljšanje odnosov s strankami. Znotraj tega področja smo imeli

17 procesov BPEL.

Področje upravljanja dobaviteljev. Vključuje poslovne procese, ki so

povezani z dobavitelji. Znotraj tega področja smo imeli 9 procesov BPEL.

Področje upravljanja podjetja. Vključuje poslovne procese, ki podpirajo

upravljanje financ in sredstev. Znotraj tega področja smo imeli 24 procesov

BPEL.

V nadaljevanju smo za vsako področje uvedli ustrezne politike obravnave izjem, kar

pomeni, da smo upravljavce izjem, ki so bili vključeni v poslovne procese BPEL,

preslikali v politike. Vsaka politika je vsebovala lastni tip obnovitvenih aktivnosti

obravnave izjem in logiko obravnave izjem BPEL. Ko je bilo potrebno, smo vsako

področje dalje razdelili na podpodročja in dodatno za vsako podpodročje definirali in

implementirali novo politiko obravnave izjem.

Dodatno smo ugotovili, da se je z uvedbo politik obravnave izjem zmanjšalo tudi

število upravljavcev izjem, saj smo lahko nekatere uporabili večkrat. Dosegli smo

ponovno uporabo definicij delov poslovnih procesov, kar predstavlja tudi enega

izmed glavnih ciljev storitveno usmerjene arhitekture, ki so opisani v poglavju 3.4.1.

6.3 Identifikacija in izbira metrik za merjenje

kompleksnosti procesnih modelov

Upravljanje poslovnih procesov je postal sprejemljiv koncept za izvajanje in

integracijo obsežnih informacijskih sistemov. Zaradi tega je potrebno vedno več

pozornosti nameniti naslednjim vprašanjem: Na kakšen način se lahko odpravijo

napake? Kako lahko olajšamo vzdrževanje? Kako lahko izboljšamo kakovost

poslovnih procesov? Skladno s tem obstajajo raziskave, ki razlagajo, da kompleksnost



procesov povečuje verjetnost pojava izjem pri izvajanju primerka poslovnega procesa

[145].

Če na poslovne procese gledamo podobno kot na kompleksne sisteme, nas predvsem

zanima njihova kompleksnost. Identificiramo lahko tri tipe procesnih tokov

(zaporedne, strukturirane in naključne), ki imajo različno kompleksnost glede na

njihovo strukturo. Zaporedni poslovni procesi predstavljajo preprosto izvajanje,

medtem, ko so naključni poslovni procesi precej kompleksni. Strukturirani poslovni

procesi spadajo po kompleksnosti nekje med zaporedne in naključne. Slika 19

prikazuje, da lahko kompleksnost poslovnega procesa povežemo s splošno idejo o

odnosu med aktivnostmi in zaporedju njihovega izvajanja. Poslovni procesi se zaradi

potreb končnih uporabnikov neprestano spreminjajo in dopolnjujejo. Zaradi njihove

dinamične narave se posledično spreminjata tudi njihova struktura in kompleksnost.

Skozi razvoj se tako lahko zaporedni poslovni procesi preoblikujejo v strukturirane in

na koncu tudi v naključne. S tem se poveča tudi njihova kompleksnost.

Slika 19: Kompleksnosti toka poslovnega procesa.

6.3.1 Perspektive kompleksnosti poslovnih procesov

Poslovne procese je možno razumeti iz več različnih perspektiv. Van der Aalst [88]

obravnava tri glavne perspektive: perspektiva kontrolnega toka, perspektiva

podatkov in perspektiva virov. Cardoso je kasneje razširil kategorizacijo perspektiv s

perspektivo aktivnosti [160]. Za vsak pogled se lahko izpelje ena ali več metrik

kompleksnosti. Skladno s tem je možno prepoznati štiri glavne poglede

kompleksnosti: (1) kompleksnost aktivnosti, (2) kompleksnost kontrolnega toka, (3)

Zaporedni proces Strukturirani proces Naključni proces



kompleksnost podatkovnega toka in (4) kompleksnost virov. V nadaljevanju opišemo

posamezen pogled kompleksnosti poslovnih procesov:

Kompleksnost aktivnosti. Pri tem pogledu se znotraj procesa izračuna

število aktivnosti. Te metrike kompleksnosti so precej enostavne za uporabo

in je zelo pomembno, da dopolnjuje druge kompleksnosti. Kompleksnost

kontrolnega toka je lahko zelo nizka, medtem, ko je lahko kompleksnost

aktivnosti za isti kontrolni tok zelo visoka. Na primer, pri procesu, ki ima

zaporedni kontrolni tok in več aktivnosti, je kompleksnost kontrolnega toka 0,

medtem ko je lahko njegova kompleksnost aktivnosti 100. Metrike

kompleksnosti aktivnosti so bile izpeljane iz metrike števila vrstic kode (angl.

Line of Code, krat. LOC), ki ima visoko stopnjo uspešnosti pri razvoju

programske opreme [161].

Kompleksnost kontrolnega toka. Opisuje aktivnosti in njihovo zaporedje

izvajanja preko različnih kontrolnih konstruktov (npr. zaporedje, izbire,

paralelizem, vejitve, združitve, zanke, začetne in končne točke izvajanja).

Skladno s tem morajo metrike kompleksnosti kontrolnega toka upoštevati

obstoj konstruktov XOR, OR, AND in zank znotraj procesnega modela.

Kompleksnost podatkovnega toka. Pogled kompleksnosti podatkovnega

toka temelji na pogledu kompleksnosti kontrolnega toka. Pri tej kompleksnosti

se obravnavajo dokumenti in drugi podatkovni objekti, ki se prenašajo med

posameznimi aktivnostmi. Kompleksnost podatkovnega toka se povečuje s

kompleksnostjo podatkovnih struktur, števila formalnih parametrov

aktivnosti in s preslikavami med podatkovnimi aktivnostmi [162]. Metrike

kompleksnosti podatkovnega toka so lahko sestavljene iz več podskupin

metrik, ki vključujejo: podatkovno kompleksnost, kompleksnost vmesnika in

kompleksnost integracije vmesnika [163]. Podatkovna kompleksnost in

kompleksnost vmesnika sta povezana s statičnimi podatki. Kompleksnost

integracije vmesnika je bolj dinamična in se osredotoča na podatkovne

odvisnosti med različnimi aktivnostmi poslovnega procesa.

Kompleksnost virov. Obravnava organizacijsko strukturo delovnih tokov v

obliki vpliva človeških in drugih virov na izvajanje aktivnosti. Aktivnosti, ki so



v izvajanju, večkrat potrebujejo dostop do virov. Vir predstavljajo entitete, kot

so zunanji dokumenti, podatkovne baze, zunanje aplikacije in naprave [164].

6.3.2 Metrike kompleksnosti poslovnih procesov

Metrike poslovnih procesov temeljijo na uporabi relativno enostavnih orodij za

merjenje kompleksnosti, ki načrtovalcem in analitikom poslovnih procesov pomagajo

pri sprejemanju odločitev. Ker so poslovni procesi sestavljeni iz velikega števila

različnih elementov (paralelizem, vejitve, združitve, zanke, itd.), ne more obstajati

samo ena meritev procesne kompleksnosti. Nagappan et al. so poudarili, da pri

razvoju programske opreme ne obstaja samo en sklop metrik, ki bi lahko univerzalno

napovedale napake programske opreme [165]. Zaradi tega je potrebno za analizo

poslovnih procesov uporabiti več različnih metrik. Kot smo omenili v predhodnem

poglavju 6.3.1, je Cardoso zaradi omenjenega razloga predstavil štiri glavne tipe

kompleksnosti: (1) kompleksnost aktivnosti, (2) kompleksnost kontrolnega toka, (3)

kompleksnost podatkovnega toka in (4) kompleksnost virov [166].

Ena izmed prvih in osnovnih meritev, ki se uporablja pri analizi programske kode,

temelji na osnovnem štetju števila vrstic kode (LOC). Čeprav je LOC prejela številne

kritike pri uporabi merjenje kompleksnosti, je ta zaradi svoje preprostosti še vedno

precej priljubljena [167]. LOC predvideva, da dolžina programske kode lahko napove

prisotnost napak, zanesljivost programske kode in enostavnost vzdrževanja. Cardoso

je predpostavil, da je aktivnost procesa enaka izjavi v programski kodi in tako izpeljal,

da se znotraj procesa lahko šteje aktivnosti [168]. Skladno s tem je predstavil metriko

število aktivnosti (angl. Number of Activites, krat. NOA). Metrika NOA se uporablja za

merjenje velikosti procesa in ne upošteva funkcionalnosti ter kompleksnosti. Metrika

NOA je neodvisna od jezika za upravljanje poslovnih procesov in je enostavna ter

razumljiva za uporabo.

(6.1)

Potrebno je upoštevati, da struktura poslovnih procesov poleg aktivnosti vsebuje tudi

druge konstrukte (npr. vejitve in združitve). Na podlagi tega dejstva, je Cardoso

izpostavil dve dodatni metriki, ki izhajata iz NOA ter temeljita na strukturi procesa

[168]. Prva metrika predvideva, da meritve izvajamo na dobro strukturiranih



procesih [97]. V primeru dobro strukturiranega procesa se kontrolne strukture

vejitve lahko enostavno štejejo, saj je nedvoumno, da je vsaka vejitev ustrezno zaprta.

Skladno s tem je bila za dobro strukturirane procese predstavljena metrika, ki meri

število aktivnosti in kontrolnih elementov procesa (angl. Number of Activities and

Control-flow Elements, krat. NOAC).

(6.2)

Druga metrika, ki izhaja iz NOA in upošteva kontrolne elemente, se uporablja za slabo

strukturirane procese. Nekateri jeziki za upravljanje poslovnih procesov (npr. EPC in

Petrijeve mreže) namreč ne zahtevajo, da ima vsaka vejitev pripadajočo združitev (se

pravi, da ni nujno, da je vejitev ustrezno zaprta). Skladno s tem je bila za slabo

strukturirane procese predstavljena metrika, ki šteje število aktivnosti, vejitev in

združitev (angl. Number of Activities, Joines and Splits, krat. NOAJS).

(6.3)

McCabe [169] je za merjenje kompleksnosti uporabil število kontrolnih poti znotraj

programskega modula. Merjenje kompleksnosti je izpeljal iz teorije grafov z uporabo

ciklomatičnega števila, ki ustreza številu linearnih neodvisnih poti v programu in je

neodvisna od jezika in jezikovnih oblik [170]. McCabe-ova ciklomatična

kompleksnost (angl. McCabe's Cyclomatic Complexity, krat. MCC) je ena izmed najbolj

široko sprejetih metrik, saj je dober pokazatelj kompleksnosti kontrolnega toka

[171]. MMC je definiran kot e – n + 2, kjer je e število robov (prenos kontrole

med vozlišči) in n število vozlišč (opravila) v kontrolnem toku grafa. Kontrolni tok

grafa opisuje logično strukturo programskih modulov.

(6.4)

Cardoso [166] je iz MCC izpeljal metriko za merjenje kompleksnosti kontrolnega toka

(angl. Control Flow Complexity, krat. CFC). Obstajata dva samostojna pristopa za

razvoj metrike CFC za analizo poslovnih procesov. Prvi pristop temelji na osnovi

merjenja kompleksnosti posamezne aktivnosti [166]. Kompleksnost kontrolnega toka

procesa BPEL je tako preprosto kompleksnost njegove aktivnosti:

( )

( ) (6.5)



Kjer je:

P – proces BPEL.

a – aktivnost, ki predstavlja najvišji nivo procesa BPEL.

Proces BPEL podpira dve kategoriji aktivnosti: osnovne in strukturirane aktivnosti

[70]. Osnovne aktivnosti predstavljajo primitivne konstrukte in se uporabljajo za

splošna opravila. Osnovne aktivnosti so: <invoke>, <receive>, <reply>,

<wait>, <terminate>, <assign>, <throw>, <compensate> in <empty>.

Strukturirane aktivnosti omogočajo strukturiranje procesa BPEL. Strukturirane

aktivnosti (<switch>, <sequence>, <while>, <flow> in <pick>) so bolj

zapletene od osnovnih in zagotavljajo enostaven programski nadzor nad koraki, ki se

izvedejo pri izvajanju poslovnega procesa. Strukturirane aktivnosti lahko vsebujejo še

številne druge aktivnosti, ki so lahko bodisi enostavne bodisi strukturirane. Za vsako

strukturirano aktivnost moramo posebej izračunati kompleksnosti po naslednjih

pravilih [166]:

( ) ∑

( )

(6.6)

( ) ∑

( )

(6.7)

( ) (

( ) ) ( ) (6.8)

( ) ( ) ∑

( )

(6.9)

( ) ( ) ∑ ( )

(6.10)

Drugi pristop uporabe metrike CFC temelji na analizi kontrolni konstruktov (XOR, OR

in AND vejitve) [172]. Glavna ideja CFC je oceniti število mentalnih stanj, ki jih je



treba upoštevati pri načrtovanju poslovnega procesa. Vejitve (XOR, OR in AND)

predstavljajo mentalna stanja v procesu. Metrika CFC izračuna kompleksnost

kontrolnega toka tako, da prešteje število vejitev z uporabo naslednje formule:

( ) ∑

( ) ∑

( ) ∑

( ) (6.11)

Kjer je:

P – proces BPEL.

– Kompleksnost izključujočih vejitev ALI. Za izračun posamezne

kompleksnosti vejitve upoštevamo število njenih izhodov:

( ) ( ) (6.12)

– Kompleksnost vejitev ALI. Za izračun posamezne kompleksnosti

vejitve upoštevamo število stanj, ki sledijo vejitvi:

( ) ( ) (6.13)

– Kompleksnost vejitev IN. Za izračun posamezne kompleksnosti

vejitve upoštevamo, da ima kompleksnost 1.

( ) (6.14)

Večja je vrednost posamezne vejitve , in , bolj kompleksen je

procesni model, saj mora načrtovalec procesov obvladovati vsa stanja med konstrukti

kontrolnega toka in z njimi povezane odhodne transakcije in aktivnosti. Prednost

metrike CFC je ta, da jo je možno uporabiti pri vzdrževanju in da podaja relativno

kompleksnost procesnih modelov. Prav tako je enostavna za uporabo. Slabost

metrike CFC pa je, da je ne moremo uporabiti pri merjenju podatkovne

kompleksnosti.

Havey je prav tako iz McCabe-ove ciklomatične kompleksnosti izpeljal metriko za

merjenje kompleksnosti poslovnega toka. Njegova metrika se imenuje MCC za

procese BPEL ( ) in je prilagojena za jezik BPEL, saj McCabe-ova ciklomatična

kompleksnost ne zadostuje procesom BPEL [173]. McCabe-ova ciklomatična

kompleksnost namreč pri izračunu kompleksnosti ne upošteva, če imajo procesi



preveliko število vejitev in ugnezdene vejitve. V ta namen upošteva različne

vrednosti kompleksnosti posameznih aktivnosti (npr. aktivnosti <pick>, <while>,

<faultHandlers>), ki rezultatu dodajo kompleksnost:

( ) (6.15)

Kjer je:

P – proces BPEL.

e – število robov (prenos kontrole med vozlišči).

n – število vozlišč (računski izrazi) v kontrolnem toku grafa.

Vrednosti dodanih kompleksnosti posameznih aktivnosti so:

Aktivnosti <pick>, <flow> in <switch>. Dodana kompleksnost je .

Aktivnost <while>. Dodana kompleksnost je .

Aktivnost <faultHandlers>. Dodana kompleksnost je nepredvidena.

Posamezen obseg z enim upravljavcem izjem in osnovnih aktivnosti doda

toliko, kolikor je kompleksnosti .

Za merjenje napora, ki je potreben za razumevanje programske opreme, se lahko

uporabi metrika CW (Cognitive Weight), ki jo je predstavil Shao [174]. Vsaka

kontrolna struktura ima določeno utež glede na to, kakšen učinek ima na težavnost

razumevanja rešitve. Vrednost metrike dobimo tako, da seštejemo uteži vseh

procesnih elementov. Kasneje sta Grugh in Laue [175] metriko CW prilagodila za

merjenje kompleksnosti procesnih modelov. Za jezik BPEL pa je metriko CW

prilagodil Mao [176]:

( ) ∑ ( )

(6.16)

Pri tem je potrebno upoštevati, da imajo različne aktivnosti različno utež

kompleksnosti. Tabela 7 prikazuje uteži kompleksnosti aktivnosti procesa BPEL, ki se

uporabljajo za merjenje kompleksnosti poslovnih procesov z uporabo metrike

.



Tabela 7: Uteži kompleksnosti aktivnosti procesa BPEL.

Aktivnost Vrednost uteži

flow 4

while, forEach, eventHandlers,

repatUntil, pick, faultHandlers

3

invoke, reply, if 2

katerakoli druga aktivnost 1

Halstead [177] je predstavil metriko za določanje kvantitativnih meritev

kompleksnosti, ki temeljijo na razumevanju programa v odvisnosti od programskih

operandov (spremenljivke in konstante) in operatorjev (aritmetični operatorji in

ključne besede, ki spreminjajo kontrolni tok). Metrika je sestavljena iz niza preprostih

meritev ( , , in ), ki so izpeljane iz izvorne kode:

– število enoličnih operatorjev.

– število enoličnih operandov.

– skupno število operatorjev.

– skupno število operandov.

Cardoso [168] je predstavil metriko HPC (Halstead-Based Process Complexity), ki je

izpeljana iz metrike Halstead [177]. Metrike HPC se uporabljajo za ocenjevanje

dolžine (angl. process length), volumna (angl. process volume) in težavnosti procesa

(angl. process difficulty).

Dolžina procesa (ang. Halstead-based Process Length Metric)

( ) ( ) (6.17)

Volumen procesa (ang. Halstead-based Process Volume Metric)

( ) ( ) (6.18)

Težavnost procesa (ang. Halstead-based Process Difficulty Metric)

( ) ( ) (6.19)



Kjer preproste meritve (n1, n2, N1 in N2) predstavljajo:

– število enoličnih aktivnosti, vejitev, združitev in kontrolnih elementov

(npr. sequence, if, else, while, itn.) poslovnega procesa.

– število enoličnih podatkovnih spremenljivk, ki jih obdelujejo aktivnosti

procesa.

– skupno število aktivnosti, vejitev, združitev in kontrolnih elementov.

– skupno število podatkovnih spremenljivk.

Uporaba metrik HPC ima številne prednosti, kot so poglobljena analiza strukture

procesa ni potrebna, metrike lahko predvidevajo stopnjo napora vzdrževanja procesa

in prisotnost napak, preprosta uporaba, enostavno izračunavanje ter uporabnost za

večino procesnih jezikov (npr. BPEL) [168].

Naslednja metrika, ki je bila prav tako predstavljena s strani Cardosa, je metrika IC

[168] (Interface Complexity). Metrika IC izhaja iz metrike PC (Complexity of

Procedure), ki sta jo predlagala Henry in Kafura [178] za merjenje kompleksnosti

postopkov (angl. procedure). Za izračun kompleksnosti procesa z uporabo metrike IC

je potrebno predhodno izračunati dolžino procesa, število vhodov in število izhodov.

Za izračun dolžine procesa, moramo najprej ugotoviti ali aktivnosti poslovnega

procesa predstavljajo črne ali bele škatle. Aktivnost predstavlja črno škatlo takrat, ko

poznamo samo vmesnik aktivnosti. V tem primeru ni možno izračunati dolžine

delovanja in posledično predpostavimo, da je dolžina enaka ena. Če aktivnost

predstavlja belo škatlo, se dolžina aktivnosti izračuna na podlagi izvorne kode

aktivnosti. Za izračun dolžine aktivnosti se lahko uporabijo običajne metrike

poslovnih procesov, ki smo jih predhodno že predstavili (npr. LOC in MCC).

( ) (6.20)

Prednost metrike IC predstavlja možnost uporabe pri podatkovno usmerjenih

procesih. Njena prednost je tudi, da se jo lahko uporabi že v fazi načrtovanja

poslovnega procesa. Skladno s tem se lahko metrične vrednosti izračunajo že pred

implementacijo procesa. V primeru, da aktivnost nima zunanjih interakcij (npr.

končna aktivnost procesa), je lahko vrednost kompleksnosti enaka nič, kar



predstavlja slabost omenjene metrike. Posledično imajo procesi EPC z velikim

odstotkom končnih aktivnosti nizko vrednost kompleksnosti.

6.4 Izvajanje meritev kompleksnosti procesnih

modelov

Za eksperimentalno evalvacijo učinkov uporabe predlaganega modela smo izvedli

meritve kompleksnosti in velikosti realnih procesov BPEL. Metrike se v splošnem

obravnavajo kot pomemben faktor, ki kaže obnašanje sistemov poslovnih procesov,

vključno s kompleksnostjo, razširljivostjo, velikostjo procesov, uporabnostjo, itd.

[168, 179]. Nagappan [165] je v svojem raziskovalnem delu izpostavil, da ne obstaja

enoten sklop metrik kompleksnosti, ki bi lahko univerzalno pokazale napake in

težave. Skladno s tem je potrebno pri merjenju kompleksnosti poslovnih procesov

uporabiti več različnih metrik. Pri naši evalvaciji smo izbrali in uporabili naslednje

metrike: NOA, NOAC, , , in HPC – V. Metrike HPC-* se

pri izračunu kompleksnosti osredotočajo na konstrukte kontrolnega toka (npr.

vejitve, če/drugače, dokler) in na podatkovne tipe. Naša rešitev na število

podatkovnih tipov (število enoličnih podatkovnih spremenljivk - in skupno število

podatkovnih spremenljivk - ) in konstruktov namenjenih kontroliranju poslovnega

toka (število enoličnih kontrolnih elementov - ) ni imela vpliva. Spremembe so bile

vidne le pri skupnem številu kontrolnih elementov - . Skladno s tem v evalvacijo

nismo vključili metrik HPC – N in HPC – D. Ugotovili smo, da naša rešitev ne vpliva na

podatkovno kompleksnost, ampak samo na kompleksnost kontrolnega toka

poslovnega procesa.

Pri merjenju smo kompleksnost poslovnih procesov z uporabo posameznih metrik

izračunali na naslednji način:

NOA. Prešteli smo vse aktivnosti, ki spadajo v množico osnovnih aktivnosti

procesov BPEL.

NOAC. Upoštevali smo vse elemente kontrolnega toka in zraven osnovnih

aktivnosti procesov BPEL prešteli tudi vse strukturirane aktivnosti.

. Upoštevali smo število robov in število vozlišč procesa BPEL [173].



. Uporabili smo pristop, ki ga je predstavil Cardoso [166] in temelji

na osnovi merjenja kompleksnosti posamezne aktivnosti. Za vsako posamezno

aktivnost smo izračunali njeno kompleksnost.

. Uporabili smo metriko, ki jo je predlagal Mao [176] in pri tem

upoštevali, da imajo različne aktivnosti različne uteži kompleksnosti.

. Uporabili smo razširjeno Halstead-ovo metriko, ki jo je predstavil

Cardoso [178]. Upoštevali smo spremembo skupnega števila kontrolnih

elementov in izračunali volumen poslovnih procesov.

6.4.1 Primer izvedbe meritev kompleksnosti poslovnega procesa

Za vsako različico poslovnega procesa (razširjeni in nerazširjeni) smo izračunali

vrednost vsake izmed izbranih metrik. Tabela 8 prikazuje rezultate meritev

kompleksnosti na poslovnem procesu Izterjava, ki smo ga že predhodno uporabili kot

vzorčni primer (glej poglavje 3.5.6).

Tabela 8: Rezultati meritev kompleksnosti na poslovnem procesu Izterjava.

Metrika BPEL brez razširitev BPEL z razširitvami

NOA 51 39

NOAC 79 65

72 55

88 85

77 60

98 92

Izračunali smo procentualno razliko v kompleksnosti. V ta namen smo uporabili

standardno aritmetično formulo za izračun procentualne razlike [180]:

( ) ( ( ) ( )

( )) (6.21)

Kjer je:

– proces BPEL.

– uporabljena metrika.



– Procentualna razlika kompleksnosti med razširjenim

in nerazširjenim poslovnim procesom pri uporabi metrike .

( ) – izračunana vrednost metrike za razširjeni poslovni proces .

( ) – izračunana vrednost metrike za nerazširjeni poslovni proces

p.

Procentualne razlike kompleksnosti med razširjenim in neraširjenim poslovnim

procesom prikazuje Tabela 9. Pri tem je potrebno omeniti, da negativna vrednost

predstavlja znižanje kompleksnosti, medtem ko pozitivna vrednost predstavlja

povečanje kompleksnosti.

Tabela 9: Razlike kompleksnosti med razširjenim in neraširjenim poslovnim procesom

Izterjava.

Metrika BPEL brez razširitev BPEL z razširitvami Razlika (%)4

NOA 51 39 -24

NOAC 79 65 -18

72 55 -23

88 85 -3

77 60 -22

98 92 -6

6.4.2 Rezultati meritev kompleksnosti

Tabela 10 prikazuje rezultate meritev kompleksnosti za vseh pet področij nabora

realnih poslovnih procesov, ki smo jih obravnavali v našem raziskovalnem delu, in

sicer procentualne razlike v kompleksnosti med razširjenimi in nerazširjenimi

procesi BPEL glede na metriko, ki je bila uporabljena.

4 Razlika je zaokroženo celo število in je prikazana v odstotkih (%).



Tabela 10: Razlike v kompleksnosti med nerazširjenimi in razširjenimi procesi BPEL.5

Procesno področje Metrika

NOA NOAC

Tr n p dr čje -16,3 -14,3 -18,4 -3,8 -23,7 -1,2

dr čje uprav janja

produktov

-13,3 -12,5 -13,7 -4,9 -15,8

-2,9

dr čje uprav janja strank -19,5 -17,3 -19,8 -8,6 -19,4 -4,7

dr čje uprav janja

dobaviteljev

-22,4 -19,1 -24,4 -7,4 -16,9 -0,9

dr čje upravljanja

podjetja

-26,2 -16,5 -14,5 -5,2 -13,1 -3,2

6.5 Analiza pridobljenih rezultatov

Na podlagi analize rezultatov, ki smo jih pridobili z merjenjem kompleksnosti

razširjenih in nerazširjenih procesnih modelov smo ugotovili, da se je kompleksnost

pri vseh analiziranih poslovnih procesih zmanjšala. Tabela 11 prikazuje izračunane

statistične podatke za posamezno procesno orientirano metriko, ki smo jo uporabili pri

merjenju posameznih poslovnih procesov. Statistični podatki, ki so prikazani znotraj

tabele, predstavljajo minimalno (krat. min), maksimalno (krat. maks) in povprečno

vrednost (krat. pov) ter mediano (krat. med).

Tabela 11: Izračunani statistični podatki za posamezno procesno orientirano metriko.6

Statistični podatki Metrika

NOA NOAC vprečje7

min -13,3 -8,7 -14,1 -2,4 -10,7 0 -8,2

maks -28,2 -20,4 -24,6 -10,6 -26,5 -4,8 -19,2

pov -20,3 -15,9 -18,2 -5,5 -17,8 -2,6 -13,4

med -19,5 -14,7 -16,7 -5,2 -16,4 -1,8 -12,4

5 Rezultati so zaokrožene vrednosti in so podani v odstotkih (%).

6 Rezultati so zaokrožene vrednosti in so podani v odstotkih (%).

7 Rezultati so zaokrožene vrednosti vseh metrik v vseh projektih in so podani v odstotkih (%).



Mediano smo vključili zaradi njene prednosti pred aritmetično sredino,

da osamelci (t.j. podatki, ki ekstremno odstopajo od ostalih podatkov) manj vplivajo

na njeno vrednost [181].

Slika 20 prikazuje kvantilni diagram (angl. box-plot diagram), ki omogoča boljše

razumevanje izračunanih vrednosti kompleksnosti.

Slika 20: Porazdelitev izračunanih znižanj kompleksnosti procesov BPEL.

Z analizo izračunanih in predstavljenih rezultatov lahko ugotovimo, da z uporabo

predlagane rešitve dosežemo naslednje rezultate:

Metrika NOA. Število aktivnosti se je v procesnih modelih zmanjšalo v

povprečju za 20,3 %. Do zmanjšanja števila aktivnosti je prišlo v vseh

analiziranih procesih in podprocesih. Število aktivnosti se je zmanjšalo

predvsem zaradi odprave podvojenih upravljavcev izjem.

Metrika NOAC. Število aktivnosti in kontrolnih elementov se je v procesnih

modelih zmanjšalo v povprečju za 15,9 % in veljajo podobni rezultati analize,

kot pri merjenju z metriko NOA. Vendar smo v tem primeru še dodatno

upoštevali konstrukte za definiranje kontrolnega toka.

Metrika . Kompleksnost se je v procesnih modelih zmanjšala v

povprečju za 18,2 %. Zaradi uporabe strategije ponovno proženje aktivnosti

http://sl.wikipedia.org/wiki/Aritmeti%C4%8Dna_sredina

http://sl.wikipedia.org/w/index.php?title=Osamelec_(statistika)&action=edit&redlink=1



smo iz procesnih modelov odstranili večje število zank, ki niso imele kontrolne

naloge (namenjene so bile samo obravnavi izjem). Ker ta metrika dodatno

upošteva kompleksnost zank kontrolnih tokov, lahko posledično opazimo

zmanjšanje kompleksnosti procesnih modelov. Število kontrolnih poti je zelo

pomemben podatek pri vpeljavi testnih primerov (angl. unit cases), ki so

potrebni pri testiranju enot (angl. unit testing). Manjše je število kontrolnih

poti, manj testnih primerov je potrebno opredeliti in obratno [182].

Metrika . Pri izračunu metrike

smo uporabili metriko, ki je

prilagojena za BPEL. Za izračun kompleksnosti smo upoštevali vse aktivnosti

in ne samo konstruktov, ki so namenjeni spreminjanju kontrolnega toka.

Kompleksnost se je v procesnih modelih zmanjšala v povprečju za 5,5 %. Po

uporabi predlagane rešitve je za razumevanje vseh stanj, v katerih se proces

lahko znajde, potrebno vložiti le 94,5 % predhodnega napora.

Metrika . Kompleksnost se je v procesnih modelih zmanjšala v

povprečju za 17,8 %. Vzrok je v tem, da smo pri vpeljavi formalnega modela

zmanjšali število upravljavcev izjem (odstranili podvojenost) in ker imajo po

definiciji te metrike upravljavci izjem precej veliko vrednost uteži, se je

kompleksnost precej zmanjšala in posledično izboljšalo razumevanje

procesnih modelov.

Metrika HPC – V. Volumen procesa se je zmanjšal v povprečju za 2,6 %.

Zmanjšalo se je predvsem skupno število kontrolnih elementov če/drugače,

ki so bili prisotni znotraj nekaterih podvojenih upravljavec izjem. Število

drugih kontrolnih elementov (npr. dokler, vejitve, itd.) se ni zmanjšalo, saj so

se znotraj upravljavcev izjem pojavljali zelo redko. Volumen procesa

opredeljuje kakšen delež informacij, ki so potrebne za razumevanje procesnih

modelov, mora absorbirati načrtovalec poslovnih procesov. Rezultati analize

kažejo, da je v našem primeru potrebno absorbirati zgolj 97 % informacij.

Predstavljeni rezultati kažejo, da je uporaba predlaganega formalnega modela

izboljšala strukturo procesnih modelov BPEL, kar zagotavlja učinkovitejšo ponovno

uporabo in zmanjšanje podvojenosti kode, hkrati pa ponuja možnost obravnave izjem

na enem mestu. Skupni cilj analize kompleksnosti procesnih modelov je izboljšanje



razumljivost poslovnih procesov [160]. Skladno s tem sklepamo, da smo z

zmanjšanjem kompleksnosti izboljšali berljivost procesnih modelov. O vplivu

kompleksnosti na berljivost procesnih modelov so poročali že v [25, 74]. Dosežena je

bila tudi zanesljivost izvajanja primerkov poslovnih procesov.



Razprava o hipotezah 7V okviru disertacije smo vzpostavili celovit model obravnave izjem na nivoju

storitveno usmerjene arhitekture. Izvedli smo pregled znanstvene in strokovne

literature na področju obravnave izjem znotraj sistemov za izvajanje poslovnih

procesov, ki temelji na vpeljavi politik. Smer raziskovanja smo zožili in se osredotočili

na področje SOA ter način obravnave izjem znotraj te arhitekture.

Da bi vpeljali celovito obravnavo izjem znotraj SOA, smo razvili formalni model, ki

ponuja mehanizem za učinkovito obravnavo vseh izrednih situacij pri izvajanju

poslovnega procesa.

Predlagan formalni model smo skladno z uporabo specifikacije razširitvenih

mehanizmov jezika BPEL preslikali v standardni jezik za izvajanje poslovnih

procesov, ki se uporablja znotraj SOA. Ovrednotili smo učinkovitost predlagane

rešitve in izmerili kompleksnost razširjenih in nerazširjenih procesnih modelov BPEL

z uporabo procesno orientiranih metrik. Pridobljene podatke smo nato analizirali in

rezultate predstavili v obliki tabel in grafikonov.

V nadaljevanju podajamo analizo obeh v disertaciji zastavljenih hipotez.

Hipoteza 1

– Mogoče je definirati in razviti model obravnave izjem, ki celovito obravnava izjeme

in odpravlja identificirane pomanjkljivosti, ter ga vpeljati v SOA.

Namen doktorske disertacije je bila vzpostavitev celovitega modela obravnave izjem

znotraj storitveno usmerjene arhitekture. Na osnovi tega smo s pomočjo procesnih

vzorcev obravnave izjem opravili analizo obravnave izrednih situacij izvršljivih

procesnih modelov in skladno z analizo definirali formalni model, ki vzpostavlja

mehanizem za učinkovito obravnavo vseh izrednih situacij pri izvajanju poslovnega

procesa. Formalni model smo predstavili s pomočjo matematičnega zapisa.

Izvedljivost formalnega modela smo preverili tako, da smo model ob podpori

specifikacije razširitvenih mehanizmov v celoti uspešno preslikali v izvršljiv procesni

jezik BPEL in odpravili identificirane pomanjkljivosti. Na podlagi predstavljenih

dejstev lahko povzamemo, da smo potrdili hipotezo .



Hipoteza 2

– Z uporabo predlaganega modela je mogoče zmanjšati kompleksnost modelov

poslovnih procesov iz domen, ki zahtevajo obravnavanje izjem.

Eden izmed glavnih ciljev doktorske disertacije je bil poiskati odgovor na vprašanje,

ali predlagan formalni model vpliva na zmanjšanje kompleksnosti modelov poslovnih

procesov. V ta namen smo opravili celovito ovrednotenje predlagane rešitve na

podlagi merjenja kompleksnosti modelov poslovnih procesov BPEL z uporabo

primernih procesno orientiranih metrik. Uporabljenih je bilo šest procesnih metrik, s

katerimi smo izvedli meritve kompleksnosti poslovnih procesov. Meritve smo izvedli

na skupno 91 realnih procesnih modelih iz dveh industrijskih področij oz. petih

domen. Za vsak poslovni proces smo pripravili razširjene procesne modele in

izračunali razliko v kompleksnosti med poslovnimi procesi, ki uporabljajo našo

predlagano rešitev in tistimi, ki je ne. Analiza rezultatov meritev je pokazala, da smo z

uporabo predlaganih izboljšav opazno znižali stopnjo kompleksnosti analiziranih

procesnih modelov in sicer za približno 13 %. Pri tem smo upoštevali modele

poslovnih procesov iz domen, ki temeljijo na poslovnih procesih znotraj organizacij

na vseh nivojih dekompozicije (predstavljeno v poglavju 6.1). S tem smo potrdili

hipotezo .



Zaključek 8V doktorski disertaciji smo se osredotočili na vpeljavo celovitega modela obravnave

izjem v storitveno usmerjeno arhitekturo. Z opravljenim pregledom in analizo

trenutnega stanja raziskav smo ugotovili, da sodobni procesno usmerjeni izvršljivi

jeziki ne zagotavljajo zadostne in učinkovite podpore obravnavi tehničnih in

poslovnih izjem, do katerih pride pri izvajanju primerkov poslovnih procesov. Za

zagotavljanje tovrstne podpore je potrebno uporabiti obstoječe konstrukte in

aktivnosti, ki v osnovi niso namenjeni obravnavi izjem, zato povečajo kompleksnost

poslovnega procesa. Posledično takšne rešitve ne predstavljajo dobre prakse

načrtovanja in razvoja poslovnih procesov.

Pomembnost naslovljene problematike smo pokazali z analizo podpore obravnave

izjem znotraj storitveno usmerjene arhitekture ter študijo sorodne znanstveno-

raziskovalne literature. Navedeno analizo smo opravili tako, da smo preverili

aktualne procesno usmerjene izvršljive jezike in nad najbolj razširjenim jezikom (t.j.

BPEL) dodatno izvedli analizo podpornih mehanizmov obravnave izjem. Identificirali

in preverili smo tudi podporo vzorcev obravnave izjem, ki jih definira iniciativa

Workflow Patterns, znotraj procesno usmerjenih izvršljivih jezikov (XPDL, BPMN in

BPEL). Ugotovili smo, da obravnavani jeziki nudijo pomanjkljivo podporo vzorcem, ki

obravnavajo problematiko obravnave izjem in napak. Na podlagi študije znanstveno-

raziskovalne literature smo ugotovili, da so tudi drugi avtorji izpostavili

pomanjkljivosti in slabosti mehanizmov obravnave izjem procesno usmerjenih

izvršljivih jezikov. Po preučitvi identificiranih sorodnih del smo ugotovili, da noben

izmed avtorjev ne predlaga rešitve, ki bi bila neposredno primerljiva z našo

predlagano rešitvijo.

Predlagali smo formalni model za specifikacijo obravnave izjem na osnovi politik in

strategij v modelih poslovnih procesov z namenom vzpostaviti in omogočiti večjo

prilagodljivost procesov pri obravnavi izjem. Formalni model smo podali s pomočjo

matematičnega zapisa in v njem naslovili izpostavljene pomanjkljivosti obravnave

izjem procesno usmerjenih izvršljivih jezikov v SOA. Formalni model je zasnovan

tako, da je neodvisen od procesnega jezika in ga je možno preslikati v katerikoli jezik.

Mi smo model preslikali v jezik BPEL, ki predstavlja de-facto standard za orkestracijo



storitev znotraj SOA. Pri realizaciji preslikave smo uporabili standardni razširitvenih

mehanizem BPEL. Na ta način smo potrdili hipotezo , ki pravi, da je mogoče

definirati in razviti model obravnave izjem, ki celovito obravnava izjeme in odpravlja

identificirane pomanjkljivosti ter ga vpeljati v SOA.

Ovrednotenje predlagane rešitve smo izpeljali z uporabo procesno usmerjenih

metrik. Meritve smo izvedli na 91 realnih procesnih modelih z uporabo šestih metrik.

Merili smo kompleksnost izvirnih in razširjenih modelov poslovnih procesov. Analiza

rezultatov je pokazala, da smo uspeli znižati kompleksnost vseh procesnih modelov,

ki smo jih uporabili pri analizi, s čimer smo izboljšali berljivost procesnih modelov.

Hipoteza , ki se glasi, da je z uporabo predlaganega modela mogoče zmanjšati

kompleksnost modelov poslovnih procesov iz domen, ki zahtevajo obravnavanje

izjem, je bila tako potrjena.



Literatura 9[1] S. Burbeck, The Evolution of Web Applications into Service-Oriented

Components with Web Services, IBM, 2000.

[2] D. Krafzig, K. Banke, D. Slama, Enterprise SOA: Service-Oriented Architecture

Best Practices (The Coad Series), Prentice Hall PTR, 2004.

[3] P. Greenfield, A. Fekete, J. Jang, D. Kuo, Compensation is Not Enough, 7th IEEE

International Enterprise Distributed Object Computing Conference, September

2003.

[4] J. Tang, B. Zhou, Z.-jun. He, Policy Driven and Multi-Agent Based Fault

Tolerance for Web services, Journal of Zhejiang University Science, 6A(7), str.

676-682, doi:10.1631/jzus.2005.A0676, 2005.

[5] E. Sindrilaru, A. Costan, V. Cristea, Fault Tolerance and Recovery in Grid

Workflow Management Systems, Proceedings of the 2010 International

Conference on Complex, Intelligent and Software Intensive Systems, 2010.

[6] J. Lawson, D. Shaffer, Orchestrating into End-to-End Processes, Mastering SOA,

Oracle, http://www.oracle.com/technetwork/topics/soa/part3-092188.html,

2007.

[7] C. Peltz, Web Services Orchestration; A Review of Emerging Technologies,

Tools, and Standards, Hewlett Packard, 2003.

[8] J. Hagel III, J. S. Brown, The Enterprise Value of Social Software, HBR Blog

Network, http://blogs.hbr.org/2010/09/social-software/, 2010.

[9] P. Abrahams, Vitria: Exception Management and Resolution in SOA-enabled

Business Processes, A White Paper by Bloor Research, 2007.

[10] A. Avizienis, J. Laprie, B. Randell, and C. Landwehr, Basic Concepts and

Taxonomy of Dependable and Secure Computing, IEEE Trans. Dependable and

Secure Computing, vol. 1, št.. 1, str. 11- 33, Jan.-Mar. 2004.

[11] C. Hagen, I. C. Society, G. Alonso, Exception Handling in Workflow Management

Systems, IEEE Ttransactions on Software Engineering, vol. 26, št. 10, okt. 2000

26(10), str. 943–958, 2000.



[12] S. Ducasse, M. Rieger, S. Demeyer, A Language Independent Approach for

Detecting Duplicated Code, Software Maintenance, Proceedings. IEEE

International Conference, doi: 10.1109/ICSM.1999.792593, 1999.

[13] W3C, Extensible Markup Language, http://www.w3.org/XML/.

[14] F. Zaid, R. Berbner, R. Steinmetz, B. Event, Leveraging the BPEL Event Model to

Support QoS-aware Process Execution, Kommunikation in Verteilten Systemen

(KiVS), 16. Fachtagung Kommunikation in Verteilten Systemen, 2009.

[15] D. Leu, F. Bastani, E. Leiss, The Effect of Statically and Dynamically Replicated

Components on System Reliability, IEEE Transactions on Reliability, str. 209–

216, 1990.

[16] H. Mourao, P. Antunes, Exception Handling Through a Workflow, On the move

to meaningful internet systems 2004, str. 37–54. Springer Verlag, Heidelberg,

2004.

[17] H. Wang, J. Z. Huang, Y. Qu, J. Xie, Web Services: Problems and Future

Directions, Web Semantics: Science, Services and Agents on the World Wide

Web, 1(3), str. 309-320. doi:10.1016/j.websem.2004.02.001, 2004.

[18] F. Casati, S. Ceri, S. Paraboschi, G. Pozzi, P. Milano, Specification and

Implementation of Exceptions in Workflow Management Systems, Database,

24(3), str. 405-451, 2000.

[19] F. Montesi, C. Guidi, I. Lanese, G. Zavattaro, Dynamic Fault Handling

Mechanisms for Service-Oriented Applications, IEEE Sixth European

Conference on Web Services, str. 225-234. doi:10.1109/ECOWS.2008.20, 2008.

[20] V. Dialani, S. Miles, L. Moreau, D. De Roure, M. Luck, Transparent Fault

Tolerance for Web Services Based Architectures, EuroPar 2002 Parallel

Processing, 2400, str. 889-898. Springer-Verlag, 2002.

[21] B. A. Kitchenham, Guidelines for preforming systematic literature reviwes in

software engineering, EBSE Technical Report, 2007.

[22] B. Benatallah, M. Dumas, C. Fauvet, Overview of Some Patterns for Architecting

and Managing Composite Web Services , ACM SIGecom Exchanges, 3(3), str. 9-

16, 2000.

[23] G. Alonso, C. Hagen, Enhancing the Fault Tolerance of Workflow. IEEE

Concurrency, 2000.



[24] S. Hwang, C. Kesselman, M. Rey, Grid Workflow : A Flexible Failure Handling

Framework for the Grid. Condor, The. High Performance Distributed

Computing 2003 Proceedings 12th IEEE International Symposium, IEEE

Comput. Soc., str. 126-137, 2003.

[25] K. Fang, J. Li, H. Sun, Y. Zhao, H. Zeng, Strategy-Based Two-Level Fault Handling

Mechanism for Composite Service, 2011 IEEE 2nd International Conference on

Software Engineering and Service Science, str. 494-499.

doi:10.1109/ICSESS.2011.5982361, 2011.

[26] B. Benatallah, M. Dumas, C. Fauvet, Overview of Some Patterns For

Architecting and Managing Composite Web Services, ACM SIGecom Exchanges,

(3):9-16, 2003.

[27] N. Salatge, JC. Fabre, Fault Tolerance Connectors for Unreliable Web Services,

IEEE/IFIP International Conference on Dependable Systems and Networks-TOC,

str. 51–60, doi:10.1109/DSN.2007.4, 2007.

[28] A. Liu, Q. Li, S. Member, L. Huang, M. Xiao, FACTS : A Framework for Fault-

Tolerant Composition of Transactional Web Services, Framework, 3(1), 46–59,

2010.

[29] Q. Wang, S. Ying, J. Wen, G. Lv, Policy-Based Exception Handling for BPEL

Processes, IEEE International Conference on Information Science and

Technology, str. 326–331. doi:10.1109/ICIST.2012.6221661, 2012.

[30] B. Benatallah, Policy-Driven Exception-Management for Composite Web

Services, Seventh IEEE International Conference on E-Commerce Technology

(CEC’05), str. 355–363. doi:10.1109/ICECT.2005.66, 2005.

[31] J. J. Alferes, A First Prototype on Evolution and Behaviour at the XML-Level,

Technical report, REWERSE, http://rewerse.net/deliverables/m30/i5- d5.pdf,

2006.

[32] Q. Lu, W. Zhang, B. Su, An Exception Handling Framework for Service-oriented

Computing, Specifications, str. 315–322. doi:10.1109/NPC.2008.34, 2008.

[33] W. Yukuo, J. Yanpin, W. Yuehui, R. Changquan, Workflow Exception Handling

Method Based on ECA Rules and Advanced Transaction Characteristics, 2010

International Forum on Information Technology and Applications, str. 224–226.

doi:10.1109/IFITA.2010.152, 2010.



[34] D. K. W. Chiu, I. Qing, K. Karlapalem, A Meta Modeling Approach to Workflow

Management Systems Supporting Exception Handling, Information Systems,

vol. 24, št. 2, str. 159-184, ISSN 0306-4379, http://dx.doi.org/10.1016/S0306-

4379(99)00010-1, 1999.

[35] A. Liu, Q. Li, L. Huang, M. Xiao, A Declarative Approach to Enhancing the

Reliability of BPEL Processes, IEEE International Conference on Web Services,

2007.

[36] J. J. Alfarez, F. Banti, A. Brogi, An Event-Condition-Action Logic Programming

Language, Proceedings of the 10th European conference on logics and artificial

intelligence, str. 29–42, 2006.

[37] D. McCarthy, The Architecture of an Active Database Management System,

Proceedings of the ACM SIGMOD International Conference on Management of

Data, str. 215–24, 1989.

[38] A. Bonifati, S. Ceri, S. Paraboschi, Active Rules for XML: a New Paradigm for E-

Services, The International Journal on Very Large Databases,10:39–47, 2011.

[39] M. Krizevnik, M. B. Juric, Data-Bound Variables for WS-BPEL Executable

Processes, Computer Languages, Systems & Structures, 38(4), 279–299.

doi:10.1016/j.cl.2012.06.001, 2012.

[40] S. Modafferi, E. Conforti, Methods for Enabling Recovery Actions in Ws-BPEL,

On the Move to Meaningful Internet Systems, str. 219–236, 2006.

[41] O. Kopp, K. Görlach, D. Karastoyanova, F. Leymann, M. Reiter, D. Schumm, A

Classification of BPEL Extensions, Journal of Systems Integration, 4:3–28, 2011.

[42] M. Kloppmann, WS-BPEL Extension for Sub-Processes – BPEL-SPE, A Joint

White Paper by IBM and SAP, Sep. 2005, http://

download.boulder.ibm.com/ibmdl/pub/software/dw/webservices/ws-

bpelsubproc/ws-bpelsubproc.pdf, 2005.

[43] A. Agrawal, WS-BPEL Extension for People, Version 1.0, IBM,

http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-

bpel4people/BPEL4People_v1.pdf, 2007.

[44] A. Agrawal, Web Services Human Task, Version 1.0, IBM,

http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-

bpel4people/WS-HumanTask_v1.pdf.



[45] A. Charfi, M. Mezini, Aspect-Oriented Web Service Composition With

AO4BPEL, ECOWS, LNCS, vol. 3250, Springer, str. 168–182, 2004.

[46] D. Karastoyanova, F. Leymann, BPEL'n'Aspects: Adapting Service

Orchestration Logic, Proceedings of 7th IEEE International Conference on Web

Services (ICWS), 2009.

[47] A. Erradi, P. Maheshwari, AdaptiveBPEL: a Policy-Driven Middleware for

Flexible Web Services Compositions, Proceedings of Middleware for Web

Services (MWS), 2005.

[48] C. Ghedira, H. Mezni, Through Personalized Web Service Composition

Specification: from BPEL to C-BPEL, Electronic Notes in Theoretical Computer

Science, str. 117–132, 2006.

[49] G. Decker, O. Kopp, F. Leymann, M. Weske, BPEL4Chor: Extending BPEL for

Modeling Choreographies, IEEE International Conference on Web Services, str.

296–303, 2007.

[50] M. B. Juric, A. Sasa, I. Rozman, WS-BPEL Extensions for Versioning. Information

and Software Technology, 51(8), 1261–1274. doi:10.1016/j.infsof.2009.03.003,

2009.

[51] M. Blow, Y. Goland, M. Kloppmann, F. Leymann, G. Pfau, D. Roller, M. Rowley,

BPELJ: BPEL for Java, White Paper, BEA, 2004.

[52] D. Habich, S. Richly, S. Preissler, M. Grasselt, W. Lehner, A. Maier, BPEL-DT-

Data-Aware Extension of BPEL to Support Data-Intensive Service Applications,

WEWST, volume 313 of CEUR Workshop Proceedings, 2007.

[53] H. Eberle, O. Kopp, T. Unger, F. Leymann, Retry Scopes to Enable Robust

Workflow Execution in Pervasive Environments, 2nd Workshop on Monitoring,

Adaptation and Beyond (MONA+), 2009.

[54] S. Modafferi, E. Mussi, B. Pernici, SH-BPEL: A Self-Healing Plug-in for Ws- BPEL

Engines, Proceedings of the 1st Workshop on Middleware for Service Oriented

Computing, MW4SOC, ACM New York, ISBN:1-59593-425-1, 2006.

[55] A. Charfi, B. Schmeling, M. Mezini, Reliable Messaging for BPEL Processes. IEEE

International Conference on Web Services (ICWS), str. 59-66, 2006.

[56] M. Hammer, J. Champy, Reengineering the Corporation: A Manifesto for

Business Revolution, Harper Business, New York, NY, USA, 1993.



[57] T.H. Davenport, Process Innovation: Reengineering Work Through

Information Technology, Harvard Business School Press, Boston, MA, USA,

1993.

[58] H.J. Harrington, Business Process Improvement: The Break- through Strategy

for Total Quality, Productivity and Competitiveness. McGraw-Hill, New York,

NY, USA, 1991.

[59] N. C. Rusell, Foundations of Process-Aware Information Systems, Queensland

University of Technology, 2007.

[60] W.M.P. van der Aalst, A.H.M. ter Hofstede, M. Weske, Business Process

Management: A survey, Proceedings of the Business Process Management 2003,

vol. 2678 of Lecture Notes in Computer Science, str. 1–12, Eindhoven, The

Netherlands, Springer-Verlag, 2003.

[61] W. M. P. van der Aalst, Process-Aware Information Systems : Design,

Enactment and Analysis, Wiley Encyclopedia of Computer Science and

Engineering, str. 1–31, 2009.

[62] W. M. P. van der Aals, Process-Aware Information Systems : Lessons to be

Learned from Process Mining, Transactions on Petri Nets and Other Models of

Concurrency II, Springer Berlin Heidelberg, str. 1-26, 2009.

[63] M. Dumas, W.M.P. van der Aalst, A.H.M. ter Hofstede, Process-Aware

Information Systems: Bridging People and Software through Process

Technology, Wiley & Sons, 2005.

[64] C. A. Ellis, G. J. Nutt, Office Information Systems and Computer Science, ACM

Computing Surveys, vol. 12, št. 1, str. 27-60, 1980.

[65] M. zur Muehlen, Workflow-Based Process Controlling - Or: What You Can

Measure You Can Control, Future Strategies Workflow Handbook, str. 61–77,

2001.

[66] S. Alter, Information Systems: Foundation of E-Business, Prentice Hall PTR,

2002.

[67] W.M.P. van der Aalst, A.H.M. ter Hofstede, M. Weske, Business Process

Management: a Ssurvey, Proceedings of the International Conference on

Business Process Management, BPM 2003, Eindhoven, The Netherlands, str. 26-

27, 2003.



[68] L. Fischer, Workflow Handbook, Future Strategies Inc., 2003.

[69] WFMC, Workflow Management Coalition, http://www.wfmc.org.

[70] D. Jordan, A. Alves, Web Services Business Process Execution Language

Version 2 . 0, Language, str. 1–264, 2007.

[71] W3C. Web Services Choreography Description Language, Version 1.0,

http://www.w3.org/TR/2004/WD-ws-cdl-10-20041217, 2007.

[72] D. Hollingsworth, The Workflow Reference Model: 10 Years, Technical

Committee, WfMC, 2005.

[73] M. B. Juric, P. Kapil, Business Process Driven SOA Using BPMN and BPEL: From

Business Process Modeling to Orchestration and Service Oriented

Architecture, Packt Publishing, 2008.

[74] J. Cardoso, Process Control-Flow Complexity Metric: An Empirical Validation,

Services Computin, SCC '06. IEEE International Conference on , vol., no., pp.167-

173, 18-22, doi: 10.1109/SCC.2006.82M, 2006.

[75] M. Weske, Business Process Management: Concepts, Languages, Architectures,

Springer- Verlag, 2007.

[76] T. H. Davenport, Process Innovation: Reengineering Work through

Information Technology, Boston: Harvard Business School Press, 1st edition,

1993.

[77] A. M. Hammer, J. Champy, Reengineering the Corporation: Manifesto for

Business Revolution, Harper Business, 2009.

[78] H. J. Johansson, Business Process Reengineering: BreakPoint Strategies for

Market Dominance, John Wiley & Sons, 1993.

[79] M. Weske, Business Process Management: Concepts, Languages, Architectures,

Springer- Verlag, 2007.

[80] J. Mendling, Business Process Management, Lecture Notes in Business

Information Processing, 2008.

[81] E. Newcomer, G. Lomow, Understanding SOA With Web Services (independent

technology guides), Addison-Wesley Professional, 2004.

[82] M. B. Juric, K. Pant, Business Process Driven SOA using BPMN and BPEL: From

Business Process Modeling to Orchestration and Service Oriented

Architecture, Birmingham: Packt Publishing, 2008.



[83] D. Hollingsworth, The Workflow Handbook 2004, po. TheWorkflow Reference

Model: 10 Years On, str. 295–312. Workflow Management Coalition, 2004.

[84] N. Russell, A.H.M. ter Hofstede, D. Edmond, W. M.P. van der Aalst, Workflow

Data Patterns: Identification, Representation and Tool Support, Proc. of the

24th International Conference on Conceptual Modeling (ER 2005), LNCS, 2005.

[85] W. M. P. van der Aalst, A. H. M. ter Hofstede, B. Kiepuszewski, A. P. Barros,

Workflow Patterns, Distributed and Parallel Databases, 14(1):5–51, 2003.

[86] J. Mendling, K. B. Lassen, U. Zdun, Transformation Strategies between Block-

Oriented and Graph-Oriented Process Modelling Languages, Multikonferenz

Wirtschaftsinformatik, 2006.

[87] J. Mendling, M. Nuttgens, EPC Markup Language - An XML Based Interchange

Format for Event-Driven Process Chains (EPC), Technical Report, JM-2005-03-

10, WUWien, Austria, 2005.

[88] W. M. P. van der Aalst, A. H. M. ter Hofstede, YAWL: Yet AnotherWork-Flow

Language, Information Systems, 30(4):245–275, 2005.

[89] S. Thatte, XLANG Specification, Microsoft Corp., 2001.

[90] A. Arkin, Business Process Modeling Language, Specification, http://bpmi.org,

2002.

[91] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D.

Roller, D. Smith, S. Thatte, I. Trickovic, S. Weerawarana, Business Process

Execution Language for Web Services, Version 1.1, Specification, BEA Systems,

IBM Corp., Microsoft Corp., SAP AG, Siebel Systems, 2003.

[92] S. Hinz, K. Schmidt, C. Stahl, Transforming BPEL to Petri Nets, Proceedings of

BPM 2005, LNCS 3649, str. 220–235, 2005.

[93] J. Mendling, J. Ziemann, EPK-Visualisierung von BPEL4WS Prozessdefinitio-

nen, Proceedings of Workshop on Software Reengineering, Germany, 2005.

[94] J. Recker, J. Mendling, On the Translation between BPMN and BPEL :

Conceptual Mismatch between Process Modeling, The 18th International

Conference on Advanced Information Systems Engineerin, Proceedings of

Workshops and Doctoral Consortium, Namur University Press, str. 521-532,

2006.



[95] C. A. Petri. Kommunikation mit automaten, Darmstadt University of

Technology, 1962.

[96] T. Murata, Petri Nets: Properties, Analysis and Applications, Proceedings of the

IEEE 77.4: 541-580, 1989.

[97] W. M. P. van der Aalst, The Application of Petri Nets To Workflow

Management, Journal of Circuits, Systems and Computers, 08(01), 21–66.

doi:10.1142/S0218126698000043, 1998.

[98] M. T. Wynn, C. Ouyang, M. Adams, YAWL4Industry : Reflections on using YAWL

for Industry Projects, Proceedings of the 1st YAWL Symposium, CEUR

Workshop Proceedings, Sankt Augustin, Germany, str. 26-32, 2013.

[99] G. Keller, M. Nüttgens, A.-W. Scheer, Semantische Prozessmodellierung auf der

Grundlage Ereignisgesteuerter Prozessketten (EPK), Veröffentlichungen des

Instituts fürWirtschaftsinformatik (IWi), Heft 89, Universität des Saarlandes,

1992.

[100] W. M. P. van der Aalst , L. Aldred , M. Dumas , A. H. M. ter Hofstede, Design and

implementation of the YAWL system, Proceedings of Caise, 2004.

[101] W. Tscheschner, Transformation from EPC to BPMN, Oryx Research, Potsdam

Germany, 2010.

[102] K. van Hee, O. Oanea, N. Sidorova, Colored Petri Nets to Verify Extended Event-

Driven Process Chains, On the Move to Meaningful Internet Systems 2005:

CoopIS, DOA, and ODBASE, Lecture Notes in Computer Science, vol. 3760, str.

183-201, 2005.

[103] A. W. Scheer, ARIS : Business Process Modeling, Springer-Verlag, Berlin, 2nd

edition, 1998.

[104] Z. Zhang, Y. Fan, Implementation of WPDL conforming workflow model,

Tsinghua Science and Technology, vol.8, št.2, str.139,144, 2003.

[105] WfMC, XML Process Definition Language, http://www.xpdl.org/.

[106] M. Muehlen,Workflow-Based Process Controlling: Foundation, Design, and

Application of Workflow Driven Process Information Systems, Advances in

information systems and management science, Logos, 2004.



[107] M.B. Juric, S. Chandrasekaran, A. Frece, M. Hertis, G. Srdic, WS-BPEL 2.0 for

SOA Composite Applications with IBM WebSphere 7, Packt Publishing, str. 644,

2010.

[108] W. M. P. van der Aalst, M. Dumas, A. H. M. Hofstede, P. Wohed, Pattern Based

Analysis of BPML (and WSCI), External Report, QUT Technical Report FIT-TR,

No. 2002-05. Brisbane, Australia: Queensland University of Technology, 2002.

[109] W. M. P. van der Aalst, M. Dumas, A. H. M. Hofstede, Web Service Composition

Languages: Old Wine in New Bottles?, Proceedings of the 20th IEEE

Instrumentation Technology Conference (Cat No 03CH37412) EURMIC-03, 298–

305. doi:10.1109/EURMIC.2003.1231605, 2003.

[110] W3C, Web Services Conversation Language (WSCL) 1.0,

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

[111] OMG, Business Process Management Initiative, BPMN Implementers Listing,

http://www.bpmn.org/.

[112] H. Volzer, An Overview of BPMN 2.0 and Its Potential Use, Business Process

Modeling, Notation Lecture Notes in Business Information Processing, vol. 67,

str. 14-15, 2011.

[113] W3C, Web Services Choreography Description Language Version 1.0,

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

[114] A. Alves, Web Services Business Process Execution Language Version 2.0,

Technical Report, OASIS, 2007.

[115] A. Estero-Botaro, F. Palomo-Lozano, I. Medina-Bulo, Mutation Operators for

WS-BPEL 2.0, Proceedings of I International Conference on Software & Systems

Engineering and their Applications. Paris (Francia), 2008.

[116] T. Erl, Service-Oriented Architecture, vol. 8. New York: Prentice Hall, 2005.

[117] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D.

Roller, D. Smith, S. Thatte, I. Trickovic, S. Weerawarana, Business Process

Execution Language for Web Services, Version 1.1, Specification, BEA Systems,

IBM Corp., Microsoft Corp., SAP AG, Siebel Systems, 2003.

[118] M.B. Juric, R. Loganathan, P. Sarang, F. Jennings, SOA Approach to Integration,

Packt Publishing, str. 382, 2007.



[119] R. S. Kenett, A. Harel, F. Ruggeri, Controlling the Usability of Web Services,

International Journal of Software Engineering and Knowledge Engineering,

19(05), 627–651. doi:10.1142/S0218194009004362.

[120] J. Bean, SOA and Web Services Interface Design, The MK/OMG Press, Morgan

Kaufmann, Boston, 2010.

[121] OASIS, Web Services Business Process Execution Language Version 2.0,

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

[122] K. Kawamoto, D. Lobach, Proposal for Fulfilling Strategic Objectives of the U.S.

Roadmap for National Action on Decision Support through a Service-Oriented

Architecture Leveraging HL7 Services, J. Am. Med. Inform. Assoc.,14:146-155,

2007.

[123] E. Newcomer, G. Lomow, Understanding SOA with Web Services Eric,

Independent Technology Guides, 2005.

[124] A. Kocbek, M. B. Juric, Towards a Reasuble Fault Handling in WS-BPEL,

International Journal of Software Engineering and Knowledge Engineering,

2014.

[125] S. Weerawarana, F. Curbera, F. Leymann, T. Storey, D.F. Ferguson, Web

Services Platform Architecture, Prentice Hall, 2005.

[126] Angus, F.M. Huang, Ci-W. Lan, Stephen, J.H. Yang, An Optimal QoS-Based Web

Service Selection Scheme, Information Sciences, vol. 179, št. 19, 9 sept. 2009,

str. 3309-3322, ISSN 0020-0255, 10.1016/j.ins.2009.05.018, 2009.

[127] N. Shah, R. Iqbal, K. Iqbal, A.E. James, A QoS Perspective on Exception

Diagnosis in Service-Oriented Computing, Journal of Universal Computer

Science, št. 9: 1871-1885, 2009.

[128] D.A. Chappell, Enterprise Service Bus, O'Reilly, 2009.

[129] J. Lee, S. Keng, H. Soongoo, Enterprise Integration with ERP and EAI,

Communications of the ACM, vol.46, št.2 46.2: 54-60, 2003.

[130] S. Craggs, E. A. I. Vice-Chairman, Best-of-Breed ESBs Identifying Best-of-Breed

Characteristics, Enterprise Services Buses (ESBs), EAI Consortium, 2003.

[131] M. Hapner, B. Rich, S. Rahul, J. Fialli, K. Stout, Java Message Service, Sun

Microsystems Inc., Santa Clara, 2002.



[132] R. Sharma, B. Stearns, T. Ng., J2EE (tm) Connector Architecture and Enterprise

Application Integration. Addison-Wesley Professional, 2001.

[133] S. Guido, P. Welkenbach, Service Oriented Architecture: Successfully

Implement Your Own Enterprise Integration Architecture Using the Trivadis

Integration Architecture Blueprint-An Integration Blueprint, Packt Publishing,

2010.

[134] OASIS, eXtensible Access Control Markup Language, https://www.oasis-

open.org/committees/tc_home.php?wg_abbrev=xacml.

[135] W3C, XML Schema Specification, http://www.w3.org/XML/Schema.

[136] M. Mazzara, Towards Abstractions for Web Services Composition, Doctoral

dissertation, PhD thesis, Department of Computer Science, University of

Bologna, 2006.

[137] M. Butler, C. Ferreira, M.N. Yong, Precise Modelling of Compensating Business

Transactions and its Application to BPEL, Journal of Universal Computer

Science, vol. 11, št. 5, str. 712-743, 2005.

[138] C. Ouyang, E. Verbeek, W. M. P. van der Aalst, S. Breutel, M. Dumas, A. H. M. ter

Hofstede, Formal Semantics and Analysis of Control Flow in WS-BPEL, Science

of Computer Programming, 67(2-3), 162–198, 2007,

doi:10.1016/j.scico.2007.03002.

[139] D. Bradshaw , M. Kennedy, BPEL Process Manager Developer ’ s Guide teams,

Oracle, 2007.

[140] W3C, XML Path Language 2.0, http://www.w3.org/TR/xpath20.

[141] L. Ardissono, R. Furnari, A. Goy, G. Petrone, M. Segnan, Fault Tolerant Web

Service Orchestration by Means of Diagnosis, Lecture Notes in Computer

Science, vol. 4344/2006, 2-16, DOI: 10.1007/11966104_2, 2006.

[142] J. Eder, W. Liebhart, The Workflow Activity Model WAMO, Proceedings of the

International Conference on Cooperative Information Systems, 1995.

[143] F. Ceri, S. Paraboschi, S. Pozzi, Specification and Implementation of Exceptions

in Workflow Management Systems, Database, 24(3), 405–451, 2000.

[144] M. B. Juric, M. Benny, G. S. Poornachandra, Business Process Execution

Language for Web Services: An Architect and Developer's Guide to

Orchestrating Web Services Using BPEL4WS, Packt Publishing, 2006.



[145] N. Russell, W. M. P. Van der Aalst, A. H. M. Ter Hofstede, Exception Handling

Patterns, Process-Aware Information Systems. Technical report, BPM Center

Report BPM-06-04, 2006.

[146] N. A. Mulyar, Patterns for Process-Aware Information Systems: An Approach

Based on Colored Petri Nets, disertacija, Eindhoven: Technische Universiteit

Eindhoven, 2009.

[147] W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, A.P. Barros.

Workflow Patterns, Distributed and Parallel Databases, 14(1):5–51, 2003.

[148] N. Russell, W.M.P. van der Aalst, A.H.M. ter Hofstede, D. Edmond, Workflow

Data Patterns: Identification, Representation and Tool Support, Proceedings of

the 24th International Conference on Conceptual Modeling (ER’05), vol.

3716/2005, str. 353–368, 2005.

[149] N. Russell,W.M.P. van der Aalst, A.H.M. ter Hofstede, D. Edmond, Workflow

Resource Patterns: Identification, Representation and Tool Support,

Proceedings of the 17th Conference on Advanced Information Systems En-

gineering (CAiSE’05), vol. 3520 of Lecture Notes in Computer Science, str. 216–

232, Porto, Portugal, Springer-Verlag, 2005.

[150] N. Russell, W.M.P van der Aalst, and A.H.M. ter Hofstede, Workflow Exception

Patterns, Proceedings of the 18th International Conference on Advanced

Information Systems Engineering (CAiSE’06), vol. 4001 of Lecture Notes in

Computer Science, str 288–302, Luxembourg, Luxembourg, Springer-Verlag,

2006.

[151] J. Widom, S. Ceri, Active Database Systems, Morgan Kaufmann Publishers Inc.,

San Francisco, CA, 1996.

[152] M. T. Wynn, C. Ouyang, M. Adams, YAWL4Industry : Reflections on Using

YAWL for Industry Projects, str. 26–32, 2013.

[153] J. Behl, T. Distler, F. Heisig, R. Kapitza, M. Schunter, Providing Fault-Tolerant

Execution of Web-Service-Based Workflows Within Clouds, Proceedings of the

2nd International Workshop on Cloud Computing Platforms – CloudCP, ’12, 1–6.

doi:10.1145/2168697.2168704, 2012.



[154] B.S. Baker, On Finding Duplication and Near-Duplication in Large Software

Systems, Proceedings of the Second Working Conference on Reverse Engineering

(WCRE '95), IEEE Computer Society, Washington, DC, USA, 1995.

[155] C.K. Roy, J.R. Cordy, An Empirical Study of Function Clones in Open Source

Software, Reverse Engineering, 2008. WCRE '08. 15th Working Conference, str.

81-90, 15-18, doi: 10.1109/WCRE.2008.54, 2008.

[156] S. Demeyer, S. Ducasse, O. Nierstrasz, Chapter 8 - Detecting Duplicated Code,

Object-Oriented Reengineering Patterns, Morgan Kaufmann, San Francisco, str.

173-185, ISBN 9781558606395, 10.1016/B978-155860639-5/50013-4, 2003.

[157] A. Erradi, P. Maheshwari, V. Tosic, Recovery Policies for Enhancing Web

Services Reliability, 2006 IEEE International Conference on Web Services

(ICWS’06), 189–196. doi:10.1109/ICWS.2006.110, 2006.

[158] H. Sun, Strategy-Based Two-Level Fault Handling Mechanism for Composite

Service, 2011 IEEE 2nd International Conference on Software Engineering and

Service Science, str. 494–499. doi:10.1109/ICSESS.2011.5982361, 2011.

[159] M. B. Juric, WSDL and BPEL Extensions for Event Driven Architecture,

Information and Software Technology, 52(10), str. 1023–1043.

doi:10.1016/j.infsof.2010.04.005, 2010.

[160] J. Cardoso, Approaches to Compute Workflow Complexity, The Role of Business

Processes in Service Oriented Architectures,16–21, 2006.

[161] T. C. Jones, Programming Productivity, McGraw-Hill, New York, 1986.

[162] H. A. Reijers, I. T. P. Vanderfeesten, Cohesion and Coupling Metrics for

Workflow Process Design, Business Process Management, Springer Berlin

Heidelberg, LNCS 3080: 290-305, 2004.

[163] J. Cardoso, About the Data-Flow Complexity of Web Processes. 6th

International Workshop on Business Process Modeling, Development, and

Support: Business Processes and Support Systems: Design for Flexibility, 2005.

[164] W. Du, J. Davis, Enterprise Workflow Resource Management, International

Workshop on Research Issues in Data Engineering, Sydney, Australia, 1999.

[165] N. Nagappan, T. Ball, A. Zeller, Mining Metrics to Predict Component Failures,

Proceedings of the 28th International Conference on Software Engineering,

Shanghai, China, 2006.



[166] J. Cardoso, Complexity Analysis of BPEL Web Processes, Journal of Software

Process: Improvement and Practice, 12(1), str. 35-49, 2006.

[167] M. Azuma, D. Mole, Software Management Practice and Metrics in the

European Community and Japan: Some Results of a Survey, Journal of Systems

and Software, 26(1):5–18, 1994.

[168] J. Cardoso, J. Mendling, G. Neumann, H.A. Reijers, A discourse on Complexity of

Process Models, Business Process Management Workshops, Springer, Berlin-

Heidelberg, str. 117–128, 2006.

[169] T. J. McCabe, A Complexity Measure. IEEE Transactions on Software

Engineering, 2(4):308–320, 1976.

[170] T. J. McCabe, A. H.Watson, Software Complexity, Journal of Defence Software

Engineering, 7(12):5–9, 1994.

[171] W. Ward, Software Defect Prevention using Mccabe’s Complexity Metric,

Hewlett Packard Journal, 40(2):64–69, 1989.

[172] J. Cardoso, Control-Flow Complexity Measurement of Processes and Weyuker’s

Properties, 6th International Enformatika Conference, str. 213-218. 2005.

[173] M. Havey, Measuring SOA complexity, Packt Publishing,

http://www.packtpub.com/article/measuring-soa-complexity, 2010.

[174] J. Shao, Y. Wang, A New Measure of Software Complexity Based on Cognitive

Weights, Canadian Journal of Electrical and Computer Engineering, vol. 28, št. 2,

str. 69-74, 2003.

[175] V. Gruhn, R. Laue, Adopting the Cognitive Complexity Measure for Business

Process Models, 2006 5th IEEE International Conference on Cognitive

Informatics, str. 236-241, 2006.

[176] C. Mao, Control and Data Complexity Metrics for Web Service Compositions,

Proceedings of the 10th International Conference on Quality Software, str. 349-

352, 2010.

[177] M. H. Halstead, Elements of Software Science, Elsevier, Amsterdam, 1987.

[178] S. Henry, D. Kafura, Software Structure Metrics Based on Information-Flow,

IEEE Transactions On Software Engineering, 7(5):510–518, 1981.



[179] M. Reformat, W. Pedrycz, N. J. Pizzi, Software Quality Analysis With the Use of

Computational Intelligence, Information and Software Technology, 45(7), str.

405–417. doi:10.1016/S0950-5849(03)00012-0, 2003.

[180] V. Cho, MISMIS – A Comprehensive Decision Support System for Stock Market

Investment, Knowledge-Based Systems, 23(6), str. 626–633.

doi:10.1016/j.knosys.2010.04.009, 2010.

[181] J. S. Maritz, R. G. Jarrett, A Note on Estimating the Variance of the Sample

Median, Journal of the American Statistical Association, vol. 73, št. 361, str. 194-

196, 1978.

[182] A. Pareek, Unit Testing Business Processes in Oracle BPM Suite 11g, Oracle,

http://beatechnologies.wordpress.com/2013/05/05/unit-testing-business-

processes-in-oracle-bpm-suite-11g/, 2013.

http://beatechnologies.wordpress.com/2013/05/05/unit-testing-business-processes-in-oracle-bpm-suite-11g/

http://beatechnologies.wordpress.com/2013/05/05/unit-testing-business-processes-in-oracle-bpm-suite-11g/



Seznam uporabljenih kratic

Kratica Pomen

BAM Business Activity Monitoring

BPEL Business Process Execution Language

BPI Business Process Improvement

BPM Business Process Management

BPML Business Process Modeling Language

BPMN Business Process Model and Notation

BPR Business Process Re-engineering

CFC Control Flow Complexity

CW Cognitive Weight

ECA Event Condition Action

EPC Event-driven Process Chain

ESB Enterprise Service Bus

HPC-D Halstead-based Process Difficulty Metric

HPC-N Halstead-based Process Length Metric

HPC-V Halstead-based Process Volume Metric

HTTP Hypertext Transfer Protocol

IT Information Technology

LOC Line of Code

MCC McCabe's Cyclomatic Complexity

NOA Number of Activites

NOAC Number of Activities and Control-flow Elements

NOAJS Number of Activities, Joines and Splits

OASIS Organization for the Advancement of Structured Information

Standards

PAIS Process Aware Information Systems

QoS Quality of Services

SLA Service Level Agreement

SOA Service Oriented Architecture



SOAP Simple Object Access Protocol

WEC Workflow Enactment Service

WfMC Workflow Management Coalition

WFMS Workflow Management Systems

WPDL Workflow Process Definition Language

WPI Workflow Patterns Initiative

WS-CDL Web Services Choreography Description Language

WSCL Web Services Conversation Language

WSFL Web Services Flow Language

XML Extensible Markup Language

XPDL XML Process Definition Language

XSLT Extensible Stylesheet Language Transformations

YAWL Yet Another Workflow Language



Delovni življenjepis kandidata

Življenjepis

1984 Rojen v Mariboru

1999 Končana osnovna šola Tabor II, Maribor

2003 Opravljena matura na I. gimnaziji Maribor

2008 Zagovor diplomske naloge na univerzitetnem študiju z naslovom

»Upravljanje s sredstvi informacijske tehnologije« pod

mentorstvom red. prof. dr. Matjaža B. Juriča na Fakulteti za

elektrotehniko, računalništvo in informatiko Univerze v Mariboru

2008 Vpis na podiplomski študijski program Računalništvo in

informatika na Fakulteti za elektrotehniko, računalništvo in

informatiko Univerze v Mariboru

2010 Prehod na enovit doktorski študij Računalništvo in informatika na

Fakulteti za elektrotehniko, računalništvo in informatiko

Univerze v Mariboru

Strokovna biografija

2006 Praktikant japonske univerze The University of Tokyo

2009 – 2013 Mladi raziskovalec iz gospodarstva v podjetju Intera

d.o.o.

2009 – 2010 Mladi raziskovalec iz gospodarstva na Fakulteti za

elektrotehniko, računalništvo in informatiko Univerze

v Mariboru

2010 – 2013 Mladi raziskovalec iz gospodarstva na Fakulteti za

računalništvo in informatiko Univerze v Ljubljani

2013 – Raziskovalec na Fakulteti za računalništvo in

informatiko Univerze v Ljubljani

vpeljava celovitega modela obravnave izjem znotraj ... · into service-oriented architecture key...

Documents