Vurdering af BPMN - IT- og Telestyrelsen

Vurdering af BPMN 

I forhold til de parametre der kræves for optagelse i 

OIO-kataloget 

16. september 2005 

Connecting Business & Technology

© Devoteam Fischer & Lorenz A/S 2005 

Dette dokument er udarbejdet for IT og Telestyrelsen af Devoteam Fischer & Lorenz A/S. 

IT og Telestyrelsen har ret til at kopiere og distribuere dette dokument. 

Enhver anden kopiering og distribution må kun finde sted efter aftale parterne imellem. 

Enhver kopi skal være forsynet med rapportens titel, dato og denne notits.

Indholdsfortegnelse 

1. Indledning .................................................................................................... 2 

1.1. Baggrund ........................................................................................................ 2 

1.2. Formål med dokumentet................................................................................. 2 

1.3. Læsevejledning............................................................................................... 2 

2. Introduktion:................................................................................................ 3 

2.1. Standardens navn og akronymer. ................................................................... 3 

2.2. Standardens ejer og/eller ansvarligt standardiseringsorgan............................ 3 

2.3. Beskrivelse af standarden -............................................................................. 3 

2.3.1. Brugen af BPMN........................................................................................................ 7 

2.4. Beskrivelse af standardens kontekst............................................................... 8 

2.5. Beskrivelse af standardens tekniske aspekter................................................. 9 

2.6. Forgængere..................................................................................................... 9 

3. Nytteværdi: ................................................................................................ 10 

3.1. Udbredelse - Omfanget af standardens anvendelse og mængden af 

erfaringer. ..................................................................................................... 10 

3.2. Standardens modenhed................................................................................. 10 

3.3. Egnethed - Forhold der gør standarden mere eller mindre oplagt inden for 

forvaltning i Danmark. ................................................................................. 10 

3.4. Potentiale – ................................................................................................... 10 

3.5. Problemer eller potentielle problemer - Problemer eller eventuelle fremtidige 

problemer forbundet med standarden. Fx manglende interoperabilitet mellem 

versioner. ...................................................................................................... 11 

3.6. Alternative standarder - ................................................................................ 11 

4. Åbenhed: .................................................................................................... 12 

4.1. Anvendelsesvilkår -...................................................................................... 12 

4.2. Fremtidige anvendelsesvilkår –.................................................................... 12 

4.3. Dokumentation – .......................................................................................... 12 

5. Status: ......................................................................................................... 13 

5.1. Foreslået status - Anbefalet, godkendt, de facto, kommende, opretholdt eller 

forlad. ........................................................................................................... 13 

5.2. Redegørelse for status - Begrundelse for den foreslåede status. .................. 13

1. Indledning 

1.1. Baggrund 

I FESD-kontrakten mellem de offentlige parter og FESD-leverandørerne fremgår 

det, at der skal udarbejdes en standard for et workflow-modul. Modulet skal baseres 

på en standard til beskrivelse af arbejdsgange fra WFMC (Workflow Management 

Coalition) eller lignende. 

Standardiseringsarbejdet på området har imidlertid udviklet sig væsentligt siden 

kontraktens underskrift. Det er således nødvendigt at vurdere, om andre standarder 

kan komme i betragtning i stedet. 

IT og Telestyrelsen har derfor bedt Devoteam Fischer & Lorenz om en vurdering 

af standarderne 

WS-BPEL 2.0 

BPMN 1.0 

XPDL 1.0 

WS-Transaction specifikationens rammeværk WS-Coordination 1.0 samt 

de specifikke koordineringstyper WS-Business Activity 1.0 og WS- 

Atomic Transaction 1.0 

Standarderne vurderes i forhold til de parametre, der kræves for optagelse i OIOkataloget. 

1.2. Formål med dokumentet 

Dette dokument indeholder vurderingen af WS-BPEL 

1.3. Læsevejledning 

Det anbefales, at dokumenterne læses i følgende rækkefølge 

WS-BPEL 

BPMN 

XPDL 

WS-Transaction 

Standarderne er på forskelligt modenheds- og anvendelses-niveau, hvorfor der vil 

være forskel i, hvor deltaljeret de enkelte standarder er beskrevet.

2. Introduktion: 

2.1. Standardens navn og akronymer. 

Business Process Modeling Notation – BPMN 

2.2. Standardens ejer og/eller ansvarligt standardiseringsorgan. 

BPMN 1.0 specifikationen var frigivet i maj 2004 af The Business Process Management 

Initiative (BPMI.org). 

BPMN er en af tre specifikationer, som BPMI har udviklet. De andre to er Business 

Process Modelling Language (BPML) og Business Process Query Language 

(BPQL) 

The Business Process Management Initiative (BPMI.org) og the Object Management 

Group (OMG) annoncerede i juni 2005 at de vil fusionerer deres arbejde 

indenfor Business Process Management (BPM). Det indebærer blandt andet, 

at BPMN vil udgøre basis for forretningsmodellering ved at BPMN og UML 

Activity Diagram konsolideres. 

2.3. Beskrivelse af standarden - 

(Beskrivelse af standarden, dens funktion og anvendelse samt væsentlige karakteristika.) 

Formålet med BPMN er at specificere grafiske forretningsproces-modeller og - 

diagrammer for ethvert sprog til håndtering af forretningsprocesser (Business Process 

Management – BPM). 

Forretningsfolk er komfortable med at visualiserer forretningsprocesser i flowchart-format. 

Der er tusinder af forretningsanalytikere, der undersøger hvordan 

virksomheder arbejder og definerer forretningsprocesserne som simple flowcharts. 

Det giver et teknisk spænd mellem formatet for det initiale design af forretningsprocessen 

og formatet for sproget f.eks. WS-BPEL, som skal eksekvere 

disse forretningsprocesser. Formålet med BPMN er at bygge bro over dette spænd 

ved at levere en formel mekanisme, som forbinder en acceptabel visualisering af 

forretningsprocessen (en notation) til det tilhørende eksekveringsformat (f.eks. 

WS-BPEL) for denne forretningsproces. 

BPMN tilbyder et Business Process Diagram (BPD), som er et diagram designet 

til at blive brugt af personer, som håndterer forretningsprocesser. Fra forretningsanalytikeren 

der udarbejder det første udkast af processer, til de tekniske udviklere 

der er ansvarlig for implementeringen af teknologien, der vil udføre disse processer, 

samt efterfølgende for forretningsfolk der vil styre og overvåge disse processer. 

BPD er baseret på flowcharting-teknikker tilpasset til udarbejdelse af gra-

fiske modeller for forretningsproces-operationer. En forretningsproces-model er et 

netværk af grafiske objekter, som er aktiviteter og flow-kontroller, som definerer 

rækkefølgen af deres udførsel. 

BPMN tilbyder også en formel sammenkobling til et eksekveringssprog (f.eks. 

WS-BPEL), der er dog nogen usikkerhed om en forretningsproces beskrevet i 

WS-BPEL, altid vil kunne repræsenteres i BPMN. 

Samlet tilbyder BPMN en standardiseret visualiseringsmekanisme, for hvad der 

sker i forretningsprocesser defineret i forretningsproces-eksekveringssprog. 

Et BPD er opbygget af et antal grafiske elementer. Disse elementer muliggør udvikling 

af simple diagrammer, der virker bekendte for de fleste forretningsanalytikere 

(f.eks. et flowchart-diagram). Elementerne var valgt, for at de kan kendes fra 

hinanden og for at bruge former som var bekendte. 

Et af formålene med BPMN var både at gøre det muligt at tilbyde en simpel mekanisme 

for at bygge forretningsproces-modeller og på samme tid gøre det muligt 

at håndtere kompleksiteten indlejret i forretningsprocesser. Tilgangen til at håndtere 

disse to modsatrettede krav var at organisere det grafiske aspekt af notationen 

i specifikke kategorier. Det giver en mindre mængde af notationskategorier, så 

læseren af en BPD let kan genkende de basale typer af elementer og forstå diagrammet 

(Figur 1). Indenfor de basale kategorier af elementer kan yderligere variation 

og information tilføjes for at understøtte kravet om kompleksitet uden dramatisk 

at ændre det basale udtryk af diagrammet (Figur 2). De fire basale kategorier 

af elementer er: 

Flow objekter (Event, Activity og Gateway) 

Forbindelsesobjekter (Sequence Flow, Message flow og association) 

Svømmebaner (Pool, Lane) 

Artefakter (Data object, Group, Text Annotation)

Figur 1 Oversigt over de basale elementer (kilde BPMN specifikationen)

Figur 2 Eksempel på et basalt element der er udvidet (kilde BPMN specifikationen) 

2.3.1. Brugen af BPMN 

Indenfor BPMN er det to basale typer af modeller 

En ekstern (offentlig) samarbejdsproces 

En intern (privat) forretningsproces 

En samarbejdsproces beskriver interaktionen mellem to eller flere forretningsenheder. 

Diagrammerne for denne type er typisk set ud fra et overordnet synspunkt. 

Det vil sige, de repræsenterer ikke en specifik deltagers synspunkt, men 

viser interaktionen mellem deltagerne. Interaktionen er beskrevet som en sekvens 

af aktiviteter og beskedudvekslings-mønstrer mellem deltagerne. Aktiviteterne 

mellem de samarbejdende aktører kan blive betragtet som berøringspunkterne

mellem deltagerne. Dvs. at processen definerer interaktioner, der er synlige for 

omverdenen for hver deltager. 

En intern proces vil typisk fokusere på synspunktet fra en enkelt forretningsorganisation. 

Selv om interne processer ofte viser interaktioner med eksterne deltager, 

definerer de aktiviteter, som generelt ikke er synlige for offentligheden og er 

derfor private aktiviteter, der typisk er mere detaljerede end samarbejdsprocesser. 

Modellering af forretningsprocesser starter ofte med beskrivelsen af aktiviteter på 

et overordnet niveau for derefter at uddybe de lavere niveauer i separate diagrammer. 

BPMN sætter dog ikke krav om nogen specifik procesmodelleringsmetode 

2.4. Beskrivelse af standardens kontekst 

(Hvilke andre standarder berører standarden.) 

For at udrydde det tekniske spænd var et væsentligt område for BPMN, at danne 

bro mellem den forretningsorienterede procesmodellerings-notation til det itorienterede 

eksekveringssprog som vil implementere processen i et system. De 

grafiske objekter af BPMN er blevet sammenholdt med WS-BPEL så forretningsprocesser 

udtrykt i BPMN umiddelbart kan konverteres til WS-BPEL. 

BPMI har selv beskrevet positioneringen i forhold til andre standarder i Figur 3 

Figur 3 BPMIs Standard BPM stack (Kilde BPMI) 

Business Process Query Language (BPQL) er et management-interface til en 

BPM-infrastruktur. Det giver forretningsanalytikere mulighed for at forespørge 

tilstanden og kontrollen af eksekveringer af procesinstanserne. Interfacene beskri-

ves via standard WSDL BPQL vil udgøre fundamentet i fremtidige Business Activity 

Monitoring (BAM). 

Business Proces Semantic Model (BPSM) er en formel semantisk model for forretningsprocesser, 

defineret ved brug af OMG’s Meta-Object Facility (MOF) 

Business Proces eXtension Layer (BPXL) er en udvidelse af WS-BPEL 

2.5. Beskrivelse af standardens tekniske aspekter 

(Beskrivelse af de tekniske aspekter af standarden, som underliggende format og 

versionering.) 

BPMN er designet, så det tillader personer og modelleringsværktøjer noget fleksibilitet 

i at udvide den basale notation og tilbyder muligheden for yderligere indhold, 

der er relevant for et antal specifikke modelleringssituationer, såsom for et 

vertikalt marked (forsikring, banker, offentlig forvaltning, ESDH …). Et vilkårligt 

antal artefakter kan tilføjes diagrammet, som det er hensigtsmæssigt, i henhold til 

den sammenhæng hvor forretningsprocessen bliver modelleret. 

2.6. Forgængere 

(Eventuelle standarder som afløses eller udbygges af den aktuelle standard.) 

Den betragtes ikke som afløser for eller udbygning af en anden standard.

3. Nytteværdi: 

3.1. Udbredelse - Omfanget af standardens anvendelse 

og mængden af erfaringer. 

På http://bpmn.org/BPMN_Supporters.htm angives virksomheder og leverandører 

der har anvendt BPMN, listen er meget begrænset men er på den anden side næppe 

komplet. 

3.2. Standardens modenhed. 

I forbindelse med samarbejdet mellem OMG og BPMI vil der ske en yderligere 

modning af BPMN. På nuværende tidspunkt må det vurderes, at den er tilstrækkelig 

moden til at kunne bruges som grundlag for forretningsprocesbeskrivelser. 

3.3. Egnethed - Forhold der gør standarden mere eller 

mindre oplagt inden for forvaltning i Danmark. 

BPMN vil som grafisk notation til f.eks. WS-BPEL passe ind i den serviceorienterede 

arkitektur baseret på webservice-standarderne, som er valgt indenfor forvaltning 

i Danmark. 

3.4. Potentiale – 

(Standardens potentiale til at forbedre forvaltning i Danmark. Er den "Need to 

have" eller "Nice to have".) 

En veldefineret standard modelleringsnotation vil forøge interoperabiliteten mellem 

BPM-systemer og lette kommunikationen mellem såvel forretningsorienterede 

som it-orienterede personer. 

Historisk har forretningsproces-modeller udviklet af forretningsfolk været separeret 

fra den procesrepræsentation, som var påkrævet i systemer, der skulle implementere 

og eksekvere disse processer. Der var derfor et behov for manuel oversættelse 

af den originale procesmodel til en eksekveringsmodel. Sådanne oversættelser 

medfører risici for fejl og der er svært for procesejeren at forstå udviklingen 

og udførslen af processen, de er ansvarlig for. BPMN vil bygge bro mellem den 

forretningsorienterede procesmodelleringsnotation og det it-orienterede eksekveringsprog, 

der implementerer processen.

3.5. Problemer eller potentielle problemer - Problemer eller 

eventuelle fremtidige problemer forbundet med standarden. 

Fx manglende interoperabilitet mellem versioner. 

Det er usikkert hvor store ændringer fusionen af BPMIs og OMG aktiviteter medfører, 

spørgsmålet venter afklaring fra e-mail 

3.6. Alternative standarder - 

(Eventuelle standarder, der udfylder samme rolle (evt. med overlap til andre funktionaliteter 

- f.eks. ATOM ift. RSS)) 

IDEF (Står for Integrated Definition) er en gruppe af modelleringsmetoder som 

kan bruges til at beskriv opgaver i en virksomhed. IDEF var udarbejdet af United 

States Air Force og bliver nu udviklet af Knowledge Based Systems. Det var oprindeligt 

udviklet til produktionsmiljøer, men er blevet tilpasset til et bredere fokus 

og softwareudvikling generelt 

UML Activity Diagram bruges typisk indenfor modellering af forretningsprocesser 

til modellering af logikken i en enkelt use case og brugsscenarium eller til at 

modellerer den detaljerede logik i en forretningsregel. Med fusionen mellem 

BPMI og OMG forventes det, at der sker en konsolidering af BPMN og UML Activity 

Diagram.

4. Åbenhed: 

4.1. Anvendelsesvilkår - 

(Vilkår for anvendelse af standarden, som fx om der skal betales afgifter, royalties 

eller andet.) 

Der er ingen afgifter forbundet med brugen af standarder 

4.2. Fremtidige anvendelsesvilkår – 

(Mulighed for at anvendelsesvilkårene for standarden eller fremtidige versioner 

af standarden ændres.) 

Det forventes ikke at fremtidige anvendelsesvilkår ændres. 

4.3. Dokumentation – 

(I hvilket omfang er standarden dokumenteret og i hvilket omfang er dokumentationen 

tilgængelig.) 

Dokumentationen er frit tilgængelig

5. Status: 

5.1. Foreslået status - Anbefalet, godkendt, de facto, kommende, 

opretholdt eller forlad. 

Godkendt 

5.2. Redegørelse for status - Begrundelse for den foreslåede 

status. 

Efter fusionen med OMG er det den bedste kandidat til en fælles notation indenfor 

forretningsprocesmodellering. 

5.3. Referencelink 

http://www.bpmn.org/

Vurdering af WS- 

BPEL standarden 



16. september 2005 


Dette dokument er udarbejdet for IT- og Telestyrelsen af Devoteam Fischer & Lorenz A/S. 

IT- og Telestyrelsen har ret til at kopiere og distribuere dette dokument. 




1. Indledning .................................................................................................... 2 

1.1. Baggrund ........................................................................................................ 2 



2. Introduktion:................................................................................................ 3 






2.6. Forgængere..................................................................................................... 6 

3. Nytteværdi: .................................................................................................. 7 


erfaringer. ....................................................................................................... 7 

3.2. Standardens modenhed................................................................................... 7 


forvaltning i Danmark. ................................................................................... 8 

3.4. Potentiale – ..................................................................................................... 8 

3.5. Problemer eller potentielle problemer – ......................................................... 9 


3.6.1. WS-CDL................................................................................................................... 11 

3.6.2. ebXML’s BPSS ........................................................................................................ 11 

3.6.3. BPML....................................................................................................................... 11 

3.6.4. XPDL ....................................................................................................................... 11 

4. Åbenhed: .................................................................................................... 12 




5. Status: ......................................................................................................... 13 

5.1. Foreslået status - Anbefalet, godkendt, de facto, opretholdt eller forlad...... 13 


6. Indledning 

6.1. Baggrund 










WS-BPEL 2.0 


XPDL 1.0 









WS-BPEL 


XPDL 






WS-BPEL er videreudviklingen af specifikationen fra maj 2003 ”Business Proces 

Execution Language For Web Services” version 1.1 (kaldes også for BPEL4WS). 

Den var udviklet af Microsoft, IBM, BEA, Siebel Systems og SAP. 


BPEL4WS version 1.1 specifikationen var sendt til OASIS i april 2003 og WS- 

BPEL Technical Commitee (TC) var dannet. Siden da har TC’en koncentreret sig 

om at få specifikationen gennem OASIS TC-proces. Den seneste working draft af 

det, der nu kaldes WS-BPEL version 2.0, er fra 20. maj 2005 1 og det er forventningen 

at specifikationen frigives offentlig i den nærmeste fremtid. 

WS-BPEL er derfor endnu ikke en officiel OASIS-standard, men bliver generelt 

betragtet som sådan og denne analyse tager derfor som udgangspunkt, at det er en 

OASIS-standard. 



BPEL-modellen er logisk opbygget i to forskellige komponenter. Den første er et 

procesbeskrivelsessprog, den anden er et infrastrukturlag hvor protokoller for forretningsinteraktion 

beskrives. Da WSDL (Web Service Description Language) er 

det naturlige sprog for at beskrive webservices, har BPEL designerne valgt at lade 

infrastrukturlaget være en udvidelse af WSDL. 

Den underliggende filosofi bag BPEL-specifikationen er, at forretningsprocesser 

sammensættes af et antal interagerende webservices. Hver aktivitet i en BPELproces 

er derfor implementeret ved en webservice, der er defineret ved dets porttype, 

operation og message. Selve processen er også selv en webservice, som igen 

kan indgå i mere komplekse processer. 

BPEL bygger på et begreb kaldet ”orkestrering” en form for procesintegration 

hvor webservice-baserede processer interagerer i henhold til en veldefineret procesmodel, 

som er kontrolleret (orkestreret) af en enkelt agent eller forretningspart 

(dirigenten). Procesenheden kommunikerer med dets partnere ved udveksling af 

beskeder. Procesenheden og partnerne sender beskeder på tværs af en kommuni- 

1 http://www.oasis-open.org/committees/download.php/12791/wsbpel- 

specification-draft-May-20-2005.html

kationskanal kaldet en ”service link”. (F.eks. vil service link være en bilateral aftale 

mellem et rejsebureaus proces og et flyselskabs proces, der definerer de services, 

hver af dem tilbyder den anden.) 

BPEL bruges til at modellerer opførslen af både abstrakte og eksekverbare processer. 

Den abstrakte model beskriver, hvorledes information flyder mellem organisationer. 

og overlader de private aspekter til specifikke implementeringer af eksekverbare 

processer internt i organisationen, der beskriver den komplette informationsgang 

såvel inden for som gennem organisationens firewall. 

BPEL muliggør modellering af både kortlivede processer, hvor system ressourcer 

såsom databasetabeller kan blive låst (dvs. de kan eksekveres indenfor få sekunder), 

såvel som længerevarende processer hvor tiden kan måles i timer, dage og 

uger og hvor systemressourcer ikke kan låses (f.eks. afbestilling af en indkøbsordre 

flere dage efter den er afsendt) 

Procesbeskrivelsessproget specificerer de sædvanlige byggeblokke til processer: 

activities, flows, links, data containers, og assignment operationer. Disse er defineret 

i henhold til deres XML-struktur, men uden en grafisk model for at repræsentere 

dem. 

BPEL adresserer også tekniske konstruktioner, der er nødvendige for korrekt 

håndtering af forretningsprocesser. Det inkluderer korrelation (sammenhæng), 

fejlhåndtering og kompensation. 

Korrelation er teknikken brugt til at danne sammenhæng mellem procesinstanser 

ved at bruge datafelter som identifikation. For eksempel kan feltet ”ordrenummer” 

måske bruges til at forbinde en indkøbsordre med en indkøbsordre-bekræftelse. 

Fejlhåndtering og kompensation specificerer proceduren, der skal følges, når 

der sker en fejl i processen. For længerevarende processer, hvor man ikke bare 

kan stille alt tilbage, som det var ved starttidspunktet, er det et spørgsmål om, 

hvordan man omgør effekten af de aktiviteter, der allerede er blevet afsluttet, 

f.eks. afbestille en tidligere afsluttet flyreservation i en rejsereservationsproces, 

efter at betalingen er blevet autoriseret. Her må der være en kompenserende aktivitet 

for at annullere betalingen og gøre sædet tilgængeligt for andre. Designeren 

af processen definerer de kompenserende aktiviteter, der skal udføres, hvis der 

sker fejl i eksekveringen af den primære proces. 

Notationen omkring længerevarende processer er rent lokalt og sker kun indenfor 

en enkelt forretningsprocesinstans. Der er ikke nogen distribueret koordination og 

fælles aftalt resultat mellem multiple deltagende services. Opnåelse af distribuerede 

aftaler er udenfor BPELs afgræsninger og håndteres af protokollerne beskrevet 

i WS-transaction specifikationen.



WS-BPEL placeres på toppen af flere XML-specifikationer: WSDL 1.1, XML 

Schema 1.0 og XPATH1.0. WSDL messages og XML Schema type definitioner 

leverer data modellen brugt af WS-BPEL-processer. XPATH leverer understøttelse 

for data-manipulation. Alle eksterne ressourcer og partnere er repræsenteret 

som WSDL-services. WS-BPEL tilbyder udvidelsesmuligheder til at indeholde 

fremtidige versioner af disse standarder. 

IBM og Microsofts placering af WS-BPEL / BPEL4WS i i webservice-stakkken 

ses i Figur 4 

Figur 4 Placeringen af webservice-standarderne (kilde Microsoft og IBM) 




Specifikationen er ligesom andre webservice/specifikationer opbygget efter ”composability”-princippet, 

hver specifikation der udvikles, løser et specifikt behov og 

er værdifuld i sig selv. 

Specifikationen er baseret på XML



BPEL4WS var oprindeligt resultatet af en kombination af IBMs WSFL og Microsofts 

XLang sprog.




Der eksisterer et større antal implementeringer af BPEL4WS version 1.1 specifikationen 

i leverandørernes produkter. Det er forventeligt, at mange af disse implementeringer 

vil opgraderer til WS-BPEL specifikationen indenfor relativ kort 

tid. Eksempler på nuværende BPEL4WS version 1.1 implementeringer er fra 

IBM, Microsoft, BEA, Cape Clear, PolarLake, og Oracle. Der er mange open 

source BPEL4WS Version 1.1 initiativer, såsom fra Active Endpoints, Inc. og 

OpenBPEL.org. 


Håndtering af forretningsprocesser (Business Process Management – BPM) er en 

gammel disciplin, der muliggør modellering af den organisatoriske struktur, definere 

forretningsprocesser og vise interaktionen mellem dem. Over det sidste årti 

har virksomheder og offentlige forvaltninger givet mere og mere fokus på forretningsprocesser, 

beskrivelsen, automatisering og styring. Denne interesse skyldes 

behovet for at strømline forretningen, konsoliderer organisationer og reducere 

omkostninger og afspejler det faktum, at processen er den basale enhed af forretningsværdi 

i en organisation. 

Den øgede fokus på effektiv håndtering af forretningsprocesser har medført en 

øget brug af it-teknologi til at understøtte analyser og automatisering af forretningsprocesser 

og selv om flere virksomheder har opnået gode afkast på sådanne 

løsninger, er komponenterne til en komplet BPM-løsning stadigvæk under udvikling. 

Det betyder, at erfaringen med at udvikle it-løsninger til understøttelse af forretningsprocesser 

er begrænset. Det må derfor forventes, at efterhånden som WS- 

BPEL vinder indpas i faktiske implementeringer i stor skala, vil der være behov 

for ændringer og tilpasninger. F.eks. er et kritikpunkt af WS-BPEL den manglende 

mulighed for at modellere manuelle processer. Det må derfor forventes, at WS- 

BPEL vil komme i flere nye versioner. 

WS-BPEL kan derfor ikke betegnes som en moden velafprøvet standard, men er 

på den anden side bredt accepteret blandt alle væsentlige leverandører og vil sandsynligvis 

modnes til at være omdrejningspunktet for standardiseringer indenfor 

forretningsprocesser.



WS-BPEL bygger videre på de basale webservice standarder (XML, SOAP og 

WSDL) og passer derfor naturligt ind i den offentliges strategi om brug af SOA 

baseret på webservice-standarderne. 




Der har gennem historien været flere initiativer for at opbygge standarder til 

BPM. De fleste er fejlet på grund af manglende opbakning af leverandører og en 

mangel på interesse fra de ”rigtige” standardorganer. BPEL adresserer begge udfordringer: 

alle førende leverandører deltager i standardiseringen, har annonceret 

BPEL-produkter og har offentligt annonceret at BPEL er vigtig i deres 

strategi. 

Selve standardiseringen foregår hos OASIS, som er det rigtige standardorgan 

til at adressere WS-BPEL. 

Ved at opbygge standarder for BPM opnås 

Letter forståelse af BPM – Standarder fremmer brugen af standard terminologi 

og definitioner. Det accelerer forståelsen og adoptionen af nye 

teknologier såsom BPM ved at reducere forvirringen og gøre det lettere for 

kunder at sammenligne konkurrerende produkter 

Gør det lettere at udarbejde forretningsprocesser – På det tekniske niveau 

vil BPEL gøre det lettere at udarbejde forretningsprocesser, fordi teknikkerne 

kun skal kende et forretningsproces-modelleringssprog. Men da 

ønsket omkring BPM er, at forretningspersoner selv kan modellere forretningsprocesser 

i brugervenlige brugergrænseflader, kan de enkelte leverandører 

selv lave deres egne unikke grænseflader på toppen, så vidensgenbrug 

på det niveau vil være mere begrænset. Vidensgenbruget på det 

niveau kan dog øges, hvis der bygges notation-standarder på toppen af 

WS-BPEL (se BPMN-vurderingen) 

Understøtter interaktion mellem BPM-systemer fra forskellige leverandører 

– Virksomheder kan bruge forskellige BPM-systemer til forskellige 

typer af processer. I mange situationer er det vigtigt, at forretningsprocesser 

placeret i forskellige BPM-systemer skal kunne interagere 

med hinanden. En proces placeret i et system kan kalde en underproces 

placeret i et andet system. Hvis begge systemer bruger det samme under-

liggende sprog til at definere processer, vil det være lettere at understøtte 

disse interaktioner. F.eks. vil samarbejdet mellem forskellige organisationers 

ESDH-løsninger lettes, hvis alle processer beskrives ensartet. 

Lette migrering og overførsel af BPM-processer – Standarder letter arbejdet 

med at migrere processer fra et BPM-system til et andet. Kunderne 

er ikke mere bundet til en leverandør. Med BPEL er det kun procesbeskrivelsen 

der standardiseres. I en BPM–løsning er der mange andre aspekter 

såsom håndtering af data, brugerinterface, målinger osv. Det er udenfor 

BPELs afgrænsninger, så bare fordi at en BPM-løsning baseres på BPEL 

til at beskrive forretningsprocesserne, gør det ikke til en let proces at skifte 

leverandør af BPM-løsninger. Der er endnu ikke blevet demonstreret en 

overførsel af komplekse BPEL-løsninger fra en leverandørs løsning til en 

anden. 

Reducerer omkostningerne ved at forøge konkurrencen - Standarderne 

vil betyde, at leverandørernes løsninger kan bruges flere steder, hvorved 

udviklingsomkostningerne kan deles på et større antal virksomheder. 

Konkurrencen vil også øges, da leverandørens produkter kan bruges i flere 

segmenter, hvilket medfører faldende priser. 

8.5. Problemer eller potentielle problemer – 

(Problemer eller eventuelle fremtidige problemer forbundet med standarden. Fx 

manglende interoperabilitet mellem versioner.) 

De væsentligste kritikpunkter af BPEL kan opdeles i fire grupper 

Det er ikke en komplet BPM-standard: Som tidligere beskrevet er BPEL ikke 

komplet og det er heller ikke ambitionen, at BPEL skal være en komplet BPMstandard. 

Det er et gennemgående træk indenfor webservice-standardisering, at hver standard 

løser opgaven indenfor sit afgrænsede område og når der bliver identificeret 

behov for standardisering udenfor dette område, opbygges nye standarder, der 

bygger videre på de eksisterende. F.eks. udvider BPEL WSDL-standarden. BPEL 

vil derfor ikke udvikles til en komplet BPM-standard, men kommende BPMstandarder 

vil bygge videre på BPEL. Det betyder, at det eneste der standardiseres 

med BPEL, er sproget til repræsentation af orkestrerede forretningsprocesser samt 

interfacebeskrivelsen. 

Vil BPEL udvikle sig til en fælles standard. Forventningerne er under forudsætning 

af, at BPEL består prøvelserne, når de første større BPM-løsninger begynder 

at implementeres. Hvis den ikke er tilstrækkelig omfattende til at imødegå 

kundernes behov, vil leverandørerne begynde at lave egne udvidelser til den og 

fordelene ved standardiseringen vil forsvinde

BPELs troværdighed vil derved forsvinde og den vil ikke opnå status som global 

standard. 

Der er mangler i den nuværende BPEL standard Der er begrænset erfaring 

med praktisk anvendelse af BPEL, hvorfor standarden har mangler f.eks. indenfor: 

Beskrivelse af aktiviteter udført af en bruger 

BPEL kan kun beskrive multiparts samarbejde, der har en central kontrol. 

Det betyder at f.eks. koreograferet B2B samarbejde uden central kontrol, 

ikke kan repræsenteres i BPEL. 

BPEL er designet, så den faktiske partnerservice kan bestemmes dynamisk 

indeni processen, men der mangler fortsat erfaringer og standarder 

til denne form for dynamisk kald (standarder som UDDI og OWL-S bruges 

til dette). 

Indenfor B2B kan BPEL ikke tilstrækkeligt effektivt repræsentere koreografien. 

Koreografi er samarbejdet mellem uafhængige parter, hvor der ikke er en 

enkelt partner, der har kontrollen (er dirigenten), men hvor der er nedskrevet en 

overordnet beskrivelse af hvordan beskeder skal udveksles for at udføre en proces. 

Formålet med koreografi er at opnå interoperabilitet mellem et antal ligestillede 

services (WS-CDL standardiserer koregrafien). Orkestrering drejer sig om; 

hvordan opbygges en webservice ved sammensætning af andre webservices? Resultatet 

af en orkestrering er en eksekverbar webservices, resultatet af en koreografi 

er et dokument, der beskriver opførslen af de deltagende parter. 

I en dans ser man ikke nogen på scenen, der fortæller danserne, hvad de skal gøre. 

Danserne har en koreograferet beskrivelse, de lærer deres dans og de lærer de ”berøringspunkter”, 

hvor de skal interagere med andre. 

En koreograferet løsning vil typisk kalde flere orkestrerede processer i forløbet. 

Der er altså en risiko for, at BPELs forsøg på både at kunne beskrive konkrete og 

abstrakte modeller fejler. 


(Eventuelle standarder, der udfylder samme rolle) 

Generelt kan det siges, at industriens konsensus omkring webservice protokollerne 

har været væsentlig. Der eksisterer dog fortsat alternative forslag i forskellige 

områder, men opbygningen af tilhørende ”working groups” hos enten W3C eller 

OASIS har typisk efterfølgende medført en konsensus hos alle interesserede parter. 

Der er i øjeblikket et antal områder hvor der er forskellige forslag: Bl.a. Reliable 

Messaging og Transaktions-koordinering. Disse alternativer er typisk et

IBM/Microsoft ledet initiativ på den ene side og et SUN/Oracle ledet initiativ på 

den anden side. 

I begyndelsen af året afgjorde Microsoft og SUN et antal antitrust og andre udestående 

problemer og annoncerede et større samarbejde indenfor Web Services 

hvilket siden hen er sket indenfor f.eks. WS-adressing, WS-Eventing og WS- 

MetadataExchange. Det sandsynliggør et øget samarbejde indenfor f.eks. transaktionskoordinering 

og koreografi, hvilket vil lette standardiseringen af Web Service 

protokollerne. 

Der er også et overlap mellem webservice og ebXML-initiativet, men også her må 

der forventes en større ensrettethed. En del af arbejdet hos OASIS ebSOA TC er 

at udvikle ebXML-arkitekturen og håndtere overgangen til adoption af flere web 

service-protokoller. 

8.6.1. WS-CDL 

Standard til koreografi af forretningsprocesser, udarbejdes i W3C regi. 

8.6.2. ebXML’s BPSS 

ebXMLs specifikation for en koreografi-specifikation 

8.6.3. BPML 

Standard der opfylder tilsvarende formål som BPEL. Det er den generelle opfattelse 

i markedet, at BPEL er den vindende standard. 

8.6.4. XPDL 

XML Process Definition Language (XPDL) er et sprog foreslået af Workflow 

Management Coalition (WfMC) for at kunne udveksle proces-definitioner mellem 

forskellige workflow-produkter.

9. Åbenhed: 



eller andet.) 

Standarden er ikke forbundet med afgifter, royalties eller andet 




Der forventes ingen ændringer i anvendelsesvilkårene 




Dokumentationen er åben og tilgængelig

10. Status: 

10.1. Foreslået status - Anbefalet, godkendt, de facto, opretholdt 

eller forlad. 

Godkendt 


status. 

Standarden er endnu ikke bredt implementeret blandt virksomheder, men de førende 

leverandører har alle annonceret produkter med understøttelse af WS-BPEL 

og der er bred støtte bag initiativet. 

Har en organisation derfor behov for at opbygge forretningsprocesser i dag, bør 

eksekveringssproget baseres på WS-BPEL. 

Et BPM-system har ofte behov for at kalde processer, der er håndteret i andre 

BPM-systemer, det er derfor nødvendigt med en standardmetode til at kalde processer 

i andre BPM-systemer. Et webservice-interface er den bedste tilgang, da en 

forretningsproces essentielt er en sammensætning af flere services. 


http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel

Vurdering af XPDL 



6. september 2005







1. Indledning .................................................................................................... 2 

1.1. Baggrund ........................................................................................................ 2 



2. Introduktion:................................................................................................ 3 






2.6. Forgængere..................................................................................................... 6 

3. Nytteværdi: .................................................................................................. 7 


erfaringer. ....................................................................................................... 7 

3.2. Standardens modenhed................................................................................... 7 


forvaltning i Danmark. ................................................................................... 7 

3.4. Potentiale – ..................................................................................................... 7 

3.5. Problemer eller potentielle problemer - Problemer eller eventuelle fremtidige 

problemer forbundet med standarden. Fx manglende interoperabilitet mellem 

versioner. ........................................................................................................ 8 

3.6. Alternative standarder - .................................................................................. 8 

4. Åbenhed: .................................................................................................... 10 




5. Status: ......................................................................................................... 11 

5.1. Foreslået status - Anbefalet, godkendt, de facto, Kommende, opretholdt eller 

forlad. ........................................................................................................... 11 


11. Indledning 

11.1. Baggrund 










WS-BPEL 2.0 


XPDL 1.0 









WS-BPEL 


XPDL 






XML Process Definition Language (XPDL) version 2.0 


XML Process Definition Language (XPDL) er et sprog foreslået af Workflow 

Management Coalition (WfMC) for at kunne udveksle proces-definitioner mellem 

forskellige workflow-produkter. 

WfMC er en international organisation af workflow-leverandører, brugere, analytikere 

og universitets-/forsknings-grupper, der promoverer workflow interoperabilitets 

standarder. WfMCs mission er at promovere brug af workflow-produkter 

ved at etablere standarder for software terminologi, interoperabilitet og forbindelse 

mellem workflow-produkter. 

Figur 5 WfMCs workflow reference model 

WfMC har blandt andet udviklet Workflow Reference Model (Figur 5), som har 

været anvendt i workflowindustrien og blandt leverandører. 

Modellen opbygger et fælles vokabular til at beskrive forretningsprocesser 

og de understøttende teknologier, der skal sikre procesautomatisering. 

Den tilbyder arkitektoniske retningslinier til workflow-løsninger gennem 

en funktionel nedbrydning af de nødvendige softwarekomponenter i et 

workflow management system og beskriver, hvordan de interagerer.

Den understøtter standardiseret interoperabilitet mellem disse komponenter 

ved at definere interfaces mellem komponenterne og muliggør udveksling 

af information på tværs af produkter fra forskellige leverandører. 

Et workflow management system, der baseres på Workflow Reference Modellen 

(Figur 5), indeholder: 

En central workflow enhed (workflow enactment service) 

Denne service eksekverer procesdefinitioner (Interface 1) udviklet i et 

GUI værktøj. 

GUI-værktøjet er tilgået af brugere via workflow klient applikationer (interface 

2) 

Disse klient-applikationer kalder back-end applikationer efter behov 

Disse applikationer interagerer med andre workflow enactment service 

(interface 4) efter behov 

Servicene er overvåget gennem administrations- og overvågningsværktøjer 

(Interface 5) 

En oversigt over leverandører og deres overholdelse af Workflow Reference Modellen 

er placeret på WfMCs hjemmeside 

http://www.wfmc.org/standards/conformance.htm. Der er ved at blive opbygget et 

conformance test center, men pt. er udtalelserne om overholdelse baseret på leverandørernes 

egne udtalelser. 



XPDL-specifikationen er en del af dokumentationen relateret til Interface 1, den 

understøtter import og eksport. Interfacet inkluderer en fælles meta-model til beskrivelse 

af procesdefintioner og tilhørende XML-schema for udveksling af procesdefinitioner. 

Formålet med XPDL er, at det skal bruges som fil-format for BPMN. XPDL og 

BPMN specifikationerne adresserer de samme modelleringsproblemer fra forskellige 

perspektiver. XPDL leverer et XML-dokument, som kan bruges til at udveksle 

procesmodeller mellem værktøjer. BPMN tilbyder en grafisk notation af komplekse 

forretningsprocesser, som understøtter menneskelig kommunikation mellem 

forretningsbrugere og tekniske bruger. 

XPDL er altså et fælles udvekslingsformat af procesdefinitioner og det forventes 

ikke, at XPDL vil bruges som et produkts interne repræsentationssprog for forretningsprocesser, 

der eksisterer dog enkelte open source løsninger. 

XPDL bruger en XML-syntaks baseret på et XML-schema. XML bruges for udveksling 

af procesdefinitioner og gør det muligt for produkter fortsat at understøt-

te interne repræsentationer af procesdefinitioner og via en import/eksportfunktion 

at konvertere til/fra standarden ved produktets grænse. 

Principperne for procesdefinitions udveksling er illustreret i Figur 6 

Figur 6 Konceptet for udveksling af procesdefinitioner (Kilde WfMC) 

XPDL fokuserer på opgaver, der er relevant, når arbejde skal distribueres. 

Et af nøgleområderne indenfor XPDL er, at det kan udvides til at håndtere information 

brugt i et antal forskellige værktøjer. 

XPDL vil sandsynligvis aldrig være i stand til at understøtte alle informationskrav 

i alle værktøjer, så XPDL er en basal standard, hvorpå mere avancerede sprog kan 

opbygges. 



XPDL har primært berøring med andre standarder i workflow reference modellen. 

Nedenfor gennemgås kort de væsentligste 

Wf-XML er en webservice-protokol, som kan bruges af en proces-enhed til at 

modtage og sende procesdefinitioner. Proces-definitioner beskrevet af f.eks. 

XPDL og BPEL forventes at kunne installeres i en proces-enhed og derefter ekse-

kveres. Procesdefinitions-sprogene definerer ikke hvordan definitionerne installeres 

i enheden. Det er formålet med Wf-XML, den bruges som basis for konkrete 

implementeringer af funktionalitet til understøttelse af WfMCs Interface 4 (Interoperability 

abstact) defineret i Workflow Reference Model (Figur 5). 

Der har været nogen debat, om alle områder i potentiel ekstern runtime interaktion 

kan blive prædefineret i en koreografi. En skole forudsætter, at alle potentielle 

procesinteraktions områder kan indeholdes og derved kan standard WSDL/SOAPbaseret 

beskedudveksling være tilstrækkelig for web baseret interoperabilitet. 

En anden skole ser ikke denne tilgang som mulig, når det drejer sig om et stort 

antal af organisationer og individer, der dynamisk interagere via internettet. Derfor 

kræves en generisk procesinteroperabilitets-protokol såsom Wf-XML som 

fundament. På samme måde som at HTML er blevet en fundamental generisk protokol 

for at transportere hypertekst (se også Figur 7). 

Interface 2 i Workflow Reference Model (Figur 5) er specificeret i et antal workflow 

API (WAPI). Disse APIer understøtter klientapplikationers integration med 

forskellige workflowsystemer. Specielt til understøttelse af princippet om (klient) 

applikationsportabilitet og genbrug indenfor forskellige workflow management 

systemer. 

XPDL er designet til at være repræsentationen af BPMN diagrammet 




Standarderne er opbygget efter principper om udvidelsesbar, hvilket betyder, at 

virksomheder kan udvide og tilrette rammeværket til at imødegå ændrede forretningskrav. 

Det tillader, at værktøjerne kan udvikles i samklang med udviklingen i 

forretningskravene, hvorved længerevarende udviklingsomkostninger spares, efterhånden 

som ens behov ændres. 


Den afløser ikke andre standarder




På http://www.wfmc.org/standards/conformance.htm angives et antal leverandørers 

overholdelse af XPDL. Det er dog tvivlsomt om denne liste er opdateret, da 

oprettelse dato går helt tilbage til 1997 og der er kun få, der er oprettet indenfor 

2004 og 2005. Enkelte link til virksomheder fungerer da heller ikke mere. 

Der er planlagt oprettelse af et Conformance Test center som vil udfylde en lignende 

rolle, som WS-I har indenfor Web Service standarderne. 

Der er et par dusin produkter, der bruger XPDL i dag. 


Standarden må betragtes som værende moden, dog må det forventes at med den 

begrænsede praktiske anvendelse har den endnu ikke bevist sin eksistensberettigelse 

eller i hvor høj grad den opfylder anvendernes behov. 



XPDL er ikke baseret på webservice standarderne og vil derfor ikke naturligt være 

en del af den serviceorienterede arkitektur baseret på webservice-standarderne, 

som er valgt indenfor offentlig forvaltning i Danmark. 

Derimod vil den være velegnet som generelt udvekslingsformat mellem ikke webservice-baserede 

workflow løsninger. 




Hvor stort behov der er for at kunne importere og eksportere forretningsprocesbeskrivelser 

mellem BPM-produkter er stadig uvist og det er derfor usikkert, om en 

sådan standard vil forbedre forvaltningen i Danmark i væsentlig grad.

13.5. Problemer eller potentielle problemer - Problemer eller 

eventuelle fremtidige problemer forbundet med standarden. 

Fx manglende interoperabilitet mellem versioner. 

XPDL er ikke designet som en webservice standard men primært som en workflow 

standard. Det betyder, at den ikke vil passe så naturligt ind i webservice standarderne 

som f.eks. WS-BPEL. 




Både BPEL og XPDL er proceseksekverings-sprog og en væsentlig forskel er 

BPELs mulighed for at understøtte abstrakte processer, der inkluderer multiple 

BPEL processer, denne mulighed tilbyder XPDL ikke. BPEL er primært funderet 

omkring webservices, hvorimod fundamentet for XPDL er baseret omkring en 

fællesmængde af funktioner for procesdistributioner fundet i de fleste workflowprodukter. 

Positionering af BPEL og XPDL ses i (Figur 7) 

Figur 7 Standard stack (Kilde WfMC techinal committee) 

Det er vurderingen hos WfMC at BPEL og XPDL til slut vil eksisterer sammen, 

hvor XPDL vil være det format som får procesdiagrammer fra et procesdesignværktøj 

til et anden eller til en engine, mens BPEL vil forblive et eksekverbart 

format, der kan kører på mere end en engine og understøtter maskin til maskin-

kommunikation. Denne vurdering deles dog ikke af alle, f.eks. forventer Microsoft 

ikke at indbygge understøttelse for XPDL i deres produkter.

14. Åbenhed: 



eller andet.) 

Der skal ikke betales afgifter eller andet 




Der forventes ingen ændring i anvendelsesvilkårene 




XPDL er veldokumenteret og dokumentationen er tilgængelig

15. Status: 

15.1. Foreslået status - Anbefalet, godkendt, de facto, 

Kommende, opretholdt eller forlad. 

Kommende 


status. 

Til import/eksport mellem forretningsproces-systemer er den sandsynligvis velegnet, 

men der er fortsat begrænset erfaring med anvendelsen. 

Det virker dog mere oplagt, at hvis der er behov for at distribuere forretningsprocesbeskrivelser, 

så gøres det i BPMN. 


http://www.wfmc.org/standards/XPDL.htm

Vurdering af WS- 

Transaction rammeværket 



16. september 2005







1. Indledning .................................................................................................... 2 

1.1. Baggrund ........................................................................................................ 2 



2. Introduktion:................................................................................................ 3 




2.3.1. Formålet med WS-Transaction rammeværket ............................................................ 4 



2.5.1. WS-Coordination........................................................................................................ 7 

2.6. Forgængere................................................................................................... 11 

3. Nytteværdi: ................................................................................................ 12 


erfaringer. ..................................................................................................... 12 

3.2. Standardens modenhed................................................................................. 12 


forvaltning i Danmark. ................................................................................. 12 

3.4. Potentiale – ................................................................................................... 12 

3.5. Problemer eller potentielle problemer – ....................................................... 13 


4. Åbenhed: .................................................................................................... 14 




5. Status: ......................................................................................................... 15 

5.1. Foreslået status - Anbefalet, godkendt, de facto, kommende, opretholdt eller 

forlad. ........................................................................................................... 15 


16. Indledning 

16.1. Baggrund 










WS-BPEL 2.0 


XPDL 1.0 









WS-BPEL 


XPDL 






Web Service Transaction Framework (WSTF) og dets tre specifikationer: 

WS-Coordination 

WS-AtomicTransaction (WS-AT) 

WS-BusinessActivity (WS-BA) 


I øjeblikket udarbejdes specifikationen af IBM, Microsoft og BEA i et lukket forum. 

Specifikationen har været gennem udvikling, en offentlig feedback workshop 

og en offentlig interoperabilitets workshop hvor fem virksomheder medbragte 

implementeringer af alle tre specifikationer og demonstrerede, at de fungerede 

sammen. 

I løbet af september måned 2005 vil specifikationen sendes til OASIS 



En forretningsproces beskriver opgaverne, der skal udføres, deres rækkefølge, typen 

af data der deles og hvordan andre partnere er involveret. Når forretningsprocessen 

og forbindelserne med kunder, partnere og interne entiteter er defineret 

(f.eks. ved brug af WS-BPEL), er næste trin, at koordinere de forskellige aktiviteter 

der sker i en forretningsproces. WS-Transaction rammeværket komplementerer 

WS-BPEL, ved at tilbyde en måde hvormed virksomheder kan koordinere og 

integrere et antal forskellige webservices og forretningsprocesser, konsistent og 

troværdigt, på tværs af forskellige implementeringsmiljøer for at sikre fælles 

enighed om slutresultatet. 

Transaktions-understøttelse sikrer, at dette resultat sker konsistent på tværs af alle 

applikationer, som udgør forretningsaktiviteten. Der er dog en udfordring i, at 

webservices tilbyder en serviceorienteret, løst koblet og potentiel asynkron måde 

at udveksle information mellem parterne, mens de underliggende services bruger 

traditionel transaktionsbehandlings-infrastruktur. Udfordringen øges ved at transaktioner 

i disse bagvedliggende systemer ofte er konstrueret som ACIDtransaktioner 

(Figur 8), hvilket kan medføre, problemer når forretningsaktiviteter 

sammensættes fra disse services/ressourcer, da det kan medføre, at deltagerne låser 

ressourcer og forhindre transaktionen i at fortsætte.

Transaktioner er et fundamentalt koncept inden for opbygning af troværdige distribuerede 

applikationer. En transaktion er en mekanisme til at sikre, at alle deltagere 

i en applikation opnår et resultat, de alle er enige om. Traditionelt indeholder 

en transaktion følgende egenskaber, som også benævnes ACID: 

Atomicity: Transaktionen foregår atomisk, enten udføres hele transaktionen eller 

også udføres intet. 

Consitency: En transaktion ændrer stadiet fra én konsistent tilstand til en anden 

konsistent tilstand. 

Isolation: Transaktioner er isolerede fra hinanden. Dvs. en transaktions ændringer 

er skjulte for andre samtidige transaktioner, indtil transaktionen er gennemført. 

Durability: Når en transaktion er gennemført, overlever dens opdateringer, selv 

hvis systemet senere går ned. 

Figur 8 Hvad forstås ved ACID-transaktioner 

Behovet for ACID-transaktioner kan illustreres, når man ønsker at overføre penge 

fra en konto til en anden via sin netbank. Disse konti kan være i den samme finansielle 

institution eller i forskellige. Det vigtige er, at pengene aldrig må forsvinde. 

Pengene er repræsenteret som data i to databaser, som samarbejder for at sikre at 

de data de indeholder, altid er i en kendt og konsistens tilstand. Det betyder, at en 

enkelt transaktion kan manipulere med data i begge databaser og at noget vil garantere, 

at kun en ud af to mulige resultater vil ske: enten er alle ændringer sket 

succesfuldt eller også er der ingen ændringer foretaget. Dette skal også kunne ske 

i et distribueret webservice-miljø med forskellige transaktionssystemer hos de enkelte 

deltagere. 

17.3.1. Formålet med WS-Transaction rammeværket 

Formålet med WS-Transaction rammeværket er at fungere som basis, hvorpå der 

kan bygges interoperable, distribuerede applikationer, der har behov for at koordinere 

deres fælles arbejde. 

WS-Transaction rammeværket indeholder specifikationen WS-Coordination, der 

tilbyder et rammeværk til at udarbejde protokoller, som kan koordinere aktiviteter 

blandt distribuerede applikationer. Rammeværket defineret i WS-Coordination 

giver mulighed for, at en applikationsservice kan danne det indhold, som er nødvendigt 

for at udbrede en aktivitet til andre services og til at registrerer koordinationsprotokoller. 

Rammeværket tillader eksisterende workflow til behandling af 

transaktioner, workflow og andre koordinationssystemer at skjule deres proprietære 

protokol og operere i et heterogent miljø. Specifikationerne WS- 

AtomicTransaction og WS-BusinessActivity er protokolspecifikationer udarbejdet 

på grundlag af WS-Coordination rammeværket.

WS-AtomicTransaction 2 bruges, når man bygger applikationer, der kræver en 

konsistent forståelse af resultatet ved korterevarende distribuerede aktiviteter af 

typen ”alt eller intet”. Det vil sige, at de handlinger, der tages før bekræftelsen, 

kun er foreløbige, altså ikke endelige og ikke synlige for andre aktiviteter. Når en 

applikation afsluttes, anmoder den koordinatoren om at bestemme resultatet af 

transaktionen. Koordinatoren undersøger, om der har været nogle fejl i behandlingen 

ved at spørge deltagerne. Hvis alle deltagerne siger, at de eksekverede korrekt, 

vil koordinatoren bekræfte alle handlinger, og de vil være synlige for andre 

transaktioner. Hvis en deltager siger, at han ikke eksekverede korrekt, vil koordinatoren 

afbryde alle handlinger, og de vil blive stillet tilbage, som om handlingen 

aldrig var udført. 

WS-BusinessActivity 3 , som bruges, når man bygger applikationer, der kræver en 

konsistent forståelse af koordineringen af en længerevarende distribueret aktivitet, 

f.eks. hvor der kræves menneskelig godkendelse, produktion eller leverance af 

en vare, før et svar kan sendes tilbage. Ressourcer kan derfor ikke låses (eller det 

er ikke praktisk at gøre det) og de handlinger, der udføres, kan ikke skjules for 

andre aktiviteter, men er øjeblikkeligt tilgængelige. I tilfælde af fejl er det derfor 

nødvendigt at udføre kompensationsaktiviteter, da man ikke kan returnere til det 

oprindelige stadie. En WS-BusinessActivity-service vil typisk koordinere flere 

WS-AtomicTransactions. Selvom komplet ACID ikke opnås ved en BA, kan konsistens 

stadig opnås gennem kompensation. Opgaven med at skrive korrekte kompensationsaktiviteter 

(og derved den samlede systemkonsistens) er delegeret til 

udviklerne af de services, der kontrolleres af BA-koordinatoren. Sådanne kompensationer 

kan foretage tilbagestillinger, men vil typisk involverer fremadrettede 

kompensationsaktiviteter. 



WS-Coordination bruges til at koordinere WS-BPEL forretningsprocesser 

Den anvender WS-policy familien af specifikationer til at tilbyde deltagere og koordinatorer 

at beskrive og annoncerer deres muligheder og/eller krav. 

I Figur 4 angiver hvordan Microsoft og IBM ser placeringen af transaktioner i 

webservice-protokolarkitekturen 

2 http://www-106.ibm.com/developerworks/library/ws-atomtran/ 

3 http://www-106.ibm.com/developerworks/library/ws-busact/index.html

Figur 9 Placeringen af webservice-standarderne (kilde Microsoft og IBM) 




Specifikationen er baseret på XML og er ligesom andre webservice/specifikationer 

opbygget efter ”composability”-princippet, hver specifikation 

der udvikles, løser et specifikt behov og er værdifuld i sig selv. 

Standarderne er opbygget efter principper om udvidelsesbar, hvilket betyder, at 

virksomheder kan udvide og tilrette rammeværket til at imødegå ændrede forretningskrav. 

Det tillader, at værktøjerne kan udvikles i samklang med udviklingen i 

forretningskravene, hvorved længerevarende udviklingsomkostninger spares, efterhånden 

som ens behov ændres. 

WS-Transcation rammeværket indeholder ikke selv en overordnet specifikation, 

men indeholder pt. kun WS-Coordination rammeværket, der udover en generel 

specifikation af hovedelementer til brug ved koordineringer, indeholder koordinationsprotokollerne 

WS-BusinessActivity og WS-AtomicTransaction. Denne opbygning 

kan give lidt forvirring og det må forventes, at når den har været gennem 

OASIS-standardiseringen, vil det være meget tydeligt.

17.5.1. WS-Coordination 

WS-Coordination rammeværket definerer tre hovedelementer som sædvanligvis 

bruges i forskellige koordinationsmodeller. 

En Activation Service, en service der bruges af klienterne til at danne et 

koordineret indhold (en aktivitet). Det er den, der begynder en ny aktivitet 

ved at returnere en CoordinationContext, der indeholder information som: 

o Et unikt navn til at identificere hver CoordinationContext 

o Hvornår aktiviteten udløber (timeout værdi) 

o En koordinationstype der beskriver hvilken koordinations protokol 

der skal bruges (f.eks. AtomicTransaction) 

o Adressen for registreringsservicen 

o Implementeringsspecifikke udvidelser 

En Registration service, en service brugt af deltagerne til at registrerer 

ressourcer, der skal inkluderes i en specifik koordinationsprotokol. 

En Coordination service, for behandling i forbindelse med aktivitetens afslutning 

Når en koordinationsprotokol er brugt, er der flere enslydende krav, der kan bruges 

af enhver samling af webservices, der ønsker at udføre en koordineret aktivitet 

Instantiering (eller aktivering) af en ny koordinator for den specifikke koordinationsprotokol 

for en specifik applikationsinstans. Her bliver deltagerne 

forbundet. 

Registrering af deltagerne hos koordinatoren, sådan at de vil modtage koordinatorens 

protokolbesked gennem applikationens livstid. 

Udsendelse af kontekst-information mellem webservices der udgør applikationen 

En entitet der udfører koordinationsprotokollen, indtil den er afsluttet 

Figur 10 illustrerer de ovenfor nævnte typer af services.

Figur 10 Illustration af typer af services involveret i en koordinering (kilde Microsoft) 

1. Ved at sende en CreateCoordinationContext besked til Activation servicen 

instantieres en aktivitet 

2. CoordinationContext er udsendt fra A til B som en SOAP header i en applikationsbesked. 

Det fungerer som en invitation til B om at deltage i aktiviteten 

ved brug af en af koordinationsprotokollerne for denne koordinationstype. 

B kan enten vælge at registre eller lade være. 

3. Service B registrerer sig hos A ved brug af indholdet i CoordinationContext 

4. Koordinationsprotokollen kan derefter begynde mellem deltagerne 

WS-AtomicTransaction 

WS-AtomicTransaction protokollen bruges i eksisterende miljøer, hvor behandlingen 

er baseret på den kendte atomic-transaktionsmodel. Det muliggør bevarelse 

af eksisterende softwareinvesteringer når virksomheden anvender et webservicemiljø. 

Den beskriver tre koordinationsprotokoller (opsplittet i Figur 11) 

Completion: En applikation fortæller koordinatoren at den enten skal forsøge at 

bekræfte eller aflyse en atomic-transaktion (Completion Participant Service) 

Volatile2PC: Efter koordinatoren modtager en commit besked, begynder den forbered 

(prepare) fasen hos alle deltagere registreret til Volatile2PC protokollen. 

Alle deltagere skal svare før end en Prepare besked er sendt til deltagere registre-

et for Durable2PC protokollen (Volatile2PC bruges til at håndtere flygtige ressourcer 

såsom en cache) (Volatile2PC participant service) 

Durable2PC: Når prepare-fasen for Volatile2PC deltagere er afsluttet, kan koordinatoren 

påbegynde prepare-fasen for Durable2PC deltagere. Alle delagere registreret 

til denne protokol må svare enten Prepared eller ReadOnly før en commmit 

notifikation er sendt til deltagere registreret for alle protokoller. Denne protokol 

garanterer, at beskeden med det endelige resultat bliver afleveret til hver enkelt 

deltager. (varige ressourcer såsom databaser, filsystemer eller en varig køservice 

bør bruge denne two-phase-commit (2PC) protokol) (Durable2PC participant 

service) 

Figur 11 Beskedsekvens ved en Atomic Transaction commit (kilde Microsoft) 

1. Når alt arbejdet er afsluttet, vil applikationen starte commit processen ved 

at sende en Commit-besked til koordinatoren. Koordinatoren starter Preparefasen 

hos Volatile2PC deltagerne ved at sende en Prepare-besked. Hver Volatile2PC 

deltager signaler, at den har afsluttet succesfuldt ved at sende en Prepared-besked. 

2. Koordinatoren starter Prepare-fasen hos Volatile2PC-deltagerne ved at 

sende en Prepare-besked. Hver Volatile2PC-deltager signalerer, at det succesfuldt 

har afsluttet forberedelsen ved at sende en Prepared-besked 

3. Når alle Prepared-beskeder er modtaget, vil koordinatoren påbegynde Prepare-fasen 

hos Durable2PC deltagerne ved at sende en Prepare-besked. Hver 

Volatile2PC-deltager signalerer, at det succesfuldt har afsluttet forberedelsen 

ved at sende en Prepared-besked 

4. Når alle Prepared-beskeder er modtaget, vil koordinatoren beslutte at bekræfte 

ved at sende en Comitted-besked til applikationen og en Commit-

esked til både Volatil2PC og Durable2PC deltagerne. Der er ingen specifik 

rækkefølge. 

WS-BusinessActivity 

En Business Activity service forventes at bruge flere atomic transactions for at 

flytte en applikation fra et konsistent stadie til et andet. Protokollerne tilbyder en 

standardiseret måde, hvormed services kan opnå en samlet enighed, samtidighed 

med at deres autonomi bibeholdes. 

Figur 12 Business Activity eksempel (kilde Microsoft) 

1. Køberens service sender hver sælger en Indkøbsordre-besked med en 

CoordinationContext header. 

2. Alle tre sælgere registrerer sig 

3. Herefter har hver af de tre sælgere forskelligt forløb 

a. Sælger A kan ikke afgive et tilbud. Det notificerer køberen ved at 

bruge protokollens Fault-besked 

b. Både sælger B og C kan afgive et tilbud. De informerer køberen 

ved brug af protokollens Completed-besked, prisinformation vil 

være inkluderet i beskeden. 

4. Efter at have kigget på tilbuddene fra B og C vælger køberen B 

a. Den informerer B med protokollens Close-besked 

b. Den informerer C med protokollens Compensate-besked.



Den er ikke afløser for andre standarder




De to drivkræfter bag web service standarder (IBM, Microsoft) står sammen med 

enkelte andre organisationer (BEA, IONA og Hitachi) bag denne standard. Det er 

derfor sandsynligt, at en koordinationsstandard vil basere sig på denne, men standarden 

er kun i begrænset omfang implementeret i egentlige produkter og derfor 

også begrænset anvendt i faktiske implementeringer. 


Standarderne er endnu ikke sendt til noget standardorgan og brugen af standarden 

er også begrænset. 

WS-Transactions rammeværket er ment som en portefølje af transaktionsmodeller, 

hver tilpasset et specifikt problemdomæne. Efterhånden som der kommer 

brugssituationer, der ikke kan understøttes med de eksisterende protokoller, vil 

nye protokoller blive tilføjet. 



Standarden er baseret omkring webservice-standarderne og vil derfor indgå som 

en naturlig del af andre standarder indenfor forvaltning i Danmark. 




Interoperabilitet mellem eksisterende transaktions-systemer er en vigtig del af 

webservices-transaktioner. Sådanne systemer udgør allerede rygraden i mange 

virksomheders systemer og vil fortsætte med at gøre det med webservices. B2B 

aktiviteter vil involvere back-end transaktions-systemer enten direkte eller indirekte 

og muligheden for at binde disse miljøet sammen, vil være afgørende for 

succesfuld anvendelse af webservices-transaktioner 

WS-BusinessActivity giver mulighed for, at udviklere af services kan definere 

deres egne kompensationsmekanismer, som passer bedst til deres forhold, samtidig 

med, at der tilbydes en simpel model for brugere af disse services. 

WS-Transaction protokollerne udvider derved muligheden for ACIDtransaktioner 

til et løst koblet miljø og samtidig bibeholdes det bagvedliggende 

typisk tæt koblede interne miljø i virksomheden.

18.5. Problemer eller potentielle problemer – 

(Problemer eller eventuelle fremtidige problemer forbundet med standarden. Fx 

manglende interoperabilitet mellem versioner.) 

Standarden er endnu ikke sendt til nogen standardiseringsorgan og det må forventes 

at der vil ske nogle ændringer. De grundlæggende funktioner vil dog ligge fast. 




Der er lavet flere initiativer for opbygning af transaktionsprotokoller. Det førsteforsøg 

var OASIS Business Transaction Protocol fra 2001; det var efterfulgt af 

Web Services Atomic Transaction og Web Services Business Activity specfikationen 

fra IBM, Microsoft og BEA i august 2002 og opdateret november 2004 og 

senest Web Services Transaction Management specifikationen fra Sun, Oracle og 

andre i august 2003.

19. Åbenhed: 



eller andet.) 

Den OASIS Technical Committee (TC) der nedsættes for at standardisere specifikationen 

vil operere under "RF (Royalty Free) on RAND Terms" IPR mode, som 

defineret i OASIS Intellectual Property Rights (IPR) Policy 




Der forventes ingen ændringer i anvendelsesvilkårene 




Specifikationen er veldokumenteret og er tilgængelig for alle.

20. Status: 

20.1. Foreslået status - Anbefalet, godkendt, de facto, kommende, 

opretholdt eller forlad. 

Kommende 


status. 

Der er fortsat megen usikkerhed om hvor godt standarden er designet. Forholdet 

til den konkurrerende standard Web Services Transaction Management er også 

uafklaret, ligesom at den praktiske anvendelse er meget begrænset. Det er mulighed 

for at Web Service Transaction Management protokollen bliver bygget som 

en del af WS-Coordination, men der er endnu ingen endelig afklaring. 

Hvis der er behov for en koordinationsprotokol på dette stadie anbefales det at 

anvende WS-Coordination protokollerne. Dog skal man være opmærksom på at 

koordinationsprotokoller af disse typer er typisk noget der er dybt implementeret i 

produkterne og ikke et sprog man vælger såsom WS-BPEL. F.ek.s. vil WS- 

AtomicTransaction & WS-Coordination blive implementeret som del af Windows 

Communication Foundation (WCF). WS-AT er den måde WCF håndterer transactions-flow 

mellem services. 


http://www-128.ibm.com/developerworks/library/specification/ws-tx/ 

Forvent dog, at det vil ændre sig når den bliver overgivet til OASIS

Vurdering af BPMN - IT- og Telestyrelsen

Create successful ePaper yourself

Delete template?

Save as template?