Indkodning af Mobile Workflows i Reactive XML

Transkript

1 Indkodning af Mobile Workflows i Reactive XML Martin Olsen Afsluttende speciale IT-Universitetet d. 2. januar 2006 Vejledere: Thomas Hildebrandt Henning Niss

2 Abstract WS-BPEL is one out of several recently proposed XML-based languages for modeling business processes. Reactive XML is an XML-centric platform for coordination of data and processes. Reactive XML has a theoretical foundation, a general distributed extensible process calculus (dix) inspired by the theory of Bigraphical Reactive Systems. Reactive XML offers an distributed implementation based on a peer-to-peer XML Store. The distributed implementation allows the state of processes to be distributed among different clients. In this thesis we investigate how to encode a subset of WS-BPEL in Reactive XML. By encoding WS-BPEL in Reactive XML we are able express, not only the syntax of WS-BPEL in XML, but also the semantics. Moreover, an encoding in Reactive XML allow us to express the execution state of a process in XML. By using the distributed implementation of Reactive XML, the XML representation of the execution state can be distributed among different clients. Thus, by endoding WS-BPEL in Reactive XML we facilitate a sharing of the execution state of a process. We elaborate on how this sharing can be used to facilitate execution of processes on mobile devices and present a prototype implementation in J2ME. We show how to encode a subset of WS-BPEL in Reactive XML. When doing this, we extend the expressiveness of the dix calculus by introducing higher-order context expression, evaluation of XPath, and the ability to express a guard for a reaction rule. A prototype implementation of these extensions is presented. Furthermore, we show how the encoded subset of WS-BPEL can be used to model a real-world scenario.

3 Forord Dette speciale er skrevet i efteråret 2005, og er resultatet af mine sidste studier på IT-universitetet. Før vi går igang, vil jeg sende en stor tak til mine to vejledere Thomas Hildebrandt og Henning Niss. Uden jeres inspiration, opmuntring og tid til at lytte, når det hele ikke ville som jeg, var dette speciale aldrig blevet til. 1

4 Indhold 1 Indledning Problemformulering Et håndværker koordineringseksempel Valg af workflowssprog Reactive XML Processer som XML træer Reaktionsregler Reaktioner i XML Distribution af processer i Reactive XML XML Store Synkronisering af klienters ændringer Reactive XML på mobile enheder Peer-to-peer netværk Klient/server Tynd klient Reactive XML som WFMS Generelle betragtninger vedrørende indkodning af workflows i Reactive XML Reactive XML og Petri Net Workflows som Petri Net eller Procesudtryk? Indkodning af WS-BPEL WS-BPEL s overordnet struktur Implementeret funktionalitet Den tomme aktivitet Variabler Assign Reaktionsregler Indkodning af strukturelle aktiviteter Sekvens Parallelle aktiviteter Løkker

5 3.4.4 Switch Virkefelter Kommunikation mellem forretningsprocesser Synkronisering mellem kommunikerende processer Diskussion af udvidelser til Reactive XML Reformulering af kontekstudtryk Guards Opsummering Workflows modellering med WS-BPEL Eksemplets faser Beskrivelse af den konkrete arbejdsgang Estimering af tidsforbrug Booking af håndværkere Koordinering gennem arbejdsforløbet Fase 1. Beskrivelse af den konkrete arbejdsgang Entreprenøren Fase 2. Estimering af tidsforbrug Fase 3. Booking af håndværkere Fase 4. Koordinering gennem arbejdsforløbet Implementation af udvidelser til Reactive XML Wide regler Implementation af primreaktionsregler Implementation af wide regler Konteksthuller Ikke-lineære huller Guards WS-BPEL specifikke XPath funktioner Reactive XML på mobile enheder Netværksforbindelse XPath Portering af Reactive XML til J2ME Brugergrænseflade Konklusion Perspektivering Effektivisering af (mobil) implementation Automatisk afvikling af workflows Kommunikation med omverdenen Grafisk repræsentation - BPMN

6 A Reaktionsregler 78 A.1 Header A.2 Assign rules A.3 Sequence rules A.4 Flow rules A.5 While rules A.6 Switch rules A.7 Invoke, receive, reply rules A.8 Invoke, receive, reply with correlations B WS-BPEL Implementation af håndværkereksempelet 106 B.1 Contractor.bpel B.2 BathroomTemplate.bpel B.3 Plumber.bpel C Reactive XML kode 118 C.1 dk.itu.bpl.dix.reactivexml C.1.1 ContextHole.java C.1.2 ContextHoleMap.java C.1.3 HoleMap.java C.1.4 HoleException.java C.1.5 Match.java C.1.6 MatchFunctions.java C.1.7 MatchStore.java C.1.8 PrimeMatch.java C.1.9 RewriteException.java C.1.10 RewriteRuleSet.java C.1.11 RewriteRule.java C.1.12 RuleException.java C.1.13 WideMatch.java D J2ME Reactive XML kode 143 D.1 dk.itu.bpl.mix.frontend D.2 dk.itu.bpl.mix.reactivexml D.3 dk.itu.bpl.mix.store D.4 dk.itu.bpl.mix.xpath D.5 dk.itu.bpl.mix.xpath.parser D.6 dk.itu.bpl.mix.xpath.parser.sym

7 Kapitel 1 Indledning Inden for mange forskellige brancher er håbet, at fremtidens IT-systemer kan understøtte mobile enheder til koordinering af data og arbejdsrutiner. Som et eksempel på dette fremlagde regeringen i 2003 en vision for byggebranchen[26], hvor i det bl. a. hedder: Et af de centrale redskaber til at højne effektiviteten i byggeriet er brugen af it. (...) Visionen er at få digitaliseret informationsstrømmen i den samlede byggeproces - lige fra arkitektens og ingeniørens tegninger og helt ud til håndværkeren på byggepladsen. Et andet eksempel er sundhedsvæsenet, hvor trådløs stuegang og anvendelsen af mobiltelefonen til dataoverførsel i hjemmeplejen ikke længere blot er et fremtidsvisioner men emner for reelle forsøg og afprøvning af teknologi[9]. Vi tror, at hvis visionerne om anvendelsen af mobile enheder for alvor skal blive en del af hverdagen, er det nødvendigt at integrere de mobile enheder i de systemer der ellers bruges til koordinering af ressourcer og arbejdsrutiner. I mange virksomheder bruges ERP systemer til at koordinere data og arbejdsrutiner. Mange ERP systemer inkorporerer et Workflow Management Systemer(WFMS) til at koordinere arbejdsrutiner[14, 31]. Workflow Management Systemer(WFMS) er generelle systemer til koordinering af ressourcer og arbejdsgange. Teknologien er udbredt og brugt inden for mange forskellige brancher[14, 31]. Der er derfor god grund til at tro, at understøttelsen af mobile enheder i WFMS kommer til at spille en stor rolle for anvendeligheden af de mobile enheder til koordinering af data og ressourcer. Reactive XML[13, 39] er et system til koordinering af data og processer udviklet på ITU. Reactive XML har både en stærk teoretisk fundering inspireret af bigrafer[22] samt en distribueret implementation[13]. Det teoretiske fundament for Reactive XML tilbyder en meta-model for reaktive 5

8 systemer. Denne meta-model er en fleksibel kalkyle, hvori det er muligt at modellere domæne specifikke modeller. Ved at modellere en domæne specifik model i Reactive XML, kan man drage fordel af det teoretiske skelet til at give en formel semantik til modellen. I og med udgangspunktet er reaktive systemer er Reactive XML procesorienteret i den forstand, at det er processer der gemmes og manipuleres. Processer udtrykkes i XML og dette udnyttes i den distribuerede implementation. I og med at det er XML dokumenter der gemmes, kan distribution af kørende processer opnås ved at distribuere disse XML dokumenter. Den distribuerede implementation bruger XML Store[12] som lager. XML Store er værdiorienteret, hvilket vil sige at data en gang gemt i XML Store aldrig ændres. Desuden tilbyder XML Store en distribueret infrastruktur. Disse egenskaber ved XML Store udnyttes i Reactive XML til implementation af et distribueret lag, hvor en synkroniseringsmekanisme sørger for konflikthåndtering ved flere samtidige opdateringer. I sin egenskab af at være procesorienteret, er det vores formodning at Reactive XML egner sig godt til håndtering af Workflows. Da vi ved at modellere workflows i Reactive XML opnår, i kraft af Reactive XMLs meta - kalkyle, at få en formel semantik for disse workflows, kan vi udnytte det teoretiske fundament til en mere formel beskrivelse af opførslen af WFMS. Da der findes en delvis implementation af XML Store i J2ME til mobil enheder, er det desuden vores formodning, at en simpel understøttelse af mobile enheder i Reactive XML kan implementeres forholdsvis enkelt ved at udnytte den allerede eksisterende synkroniseringsmekanisme. Dette leder os frem til følgende problemformulering: 1.1 Problemformulering Vi vil i dette speciale undersøge muligheden for ved hjælp af Reactive XML at give en formel semantik til et workflowsprog og samtidig understøtte distribution og deling af processer imellem decentrale enheder. Målet for specialet er at give mulighed for, at konkrete workflows kan implementeres og eksekveres ved hjælp af Reactive XML. Et centralt punkt i specialet er brugen af Reactive XML til håndteringen af Workflows. Da vi ønsker en generel løsning der ikke knytter sig til et specifikt eksempel, vil vi indkode et Workflowsprog i Reactive XML og herefter bruge dette sprog til at modellere et eksempel. For at nå vores mål vil vi desuden undersøge om man kan udvide implementationen af Reactive XML til at håndtere mobile klienter. 6

9 1.2 Et håndværker koordineringseksempel For at konkretisere hvad vi forstår ved workflows og hvordan mobilitet kan spille ind, vil vi her beskrive et konkret eksempel omhandlende koordinering mellem håndværkere. Vi vil tage udgangspunkt i en situation, hvor en kunde ønsker at få renoveret et badeværelse. For at gøre dette er flere håndværkere involveret. En murer skal sætte fliser op, en blikkenslager skal sørge for VVS-installationer og en elektriker skal stå for el-installationer. Der kan være en række betingelser og afhængigheder for, hvornår de forskellige håndværkere har mulighed for at udføre deres arbejde. F. eks. kan det være tilfældet, at blikkenslageren skal være færdig med at lave VVSinstallationer, før mureren kan gå i gang - eller at elektrikeren ikke kan arbejde samtidig med mureren. Disse forskellige afhængigheder er afgørende for både planlægningen samt udførelsen af den samlede renovering. Planlægningen af en sådan renovering kan starte med, at en kunde ønsker at få et bud fra en entreprenør. Entreprenøren besigtiger omfanget af det samlede arbejde. I løbet af denne besigtigelse forestiller vi os, at entreprenøren inddeler renoveringen i forskellige mindre opgaver. En opgave kunne f. eks. være opsætning af fliser. Samtidig med opsplitningen i mindre opgaver forestiller vi os, at entreprenøren også bestemmer eventuelle afhængigheder mellem de enkelte opgaver. F. eks. at VVS-installationerne skal være færdige før fliserne kan sættes op. Derudover må entreprenøren, for at kunne give en pris på det samlede arbejde, afgøre, hvor lang tid de enkelte opgaver vil tage. Udover prisen, er et væsentligt kriterium for kunden, hvornår det nyrenoverede badeværelse kan stå færdigt. For at beregne et sluttidspunkt må entreprenøren sammenholde afhængighederne mellem de forskellige opgaver med disponibelt mandskab. Vi forestiller os, at entreprenøren har et fast mandskab af forskellige håndværkere. Håndværkerne kan være tilknyttet forskellige opgaver og har dermed forskellige arbejdsskemaer. For at afgøre, hvornår det samlede arbejde kan være færdigt, må entreprenøren se på de afhængigheder, der er defineret for de enkelte delopgaver. Hvis en delopgave skal udføres, før andre kan gå i gang, må entreprenøren først finde en håndværker med de fornødne forudsætninger til at udføre denne delopgave. Ved at undersøge hvornår en håndværker har tid, kan entreprenøren regne sig frem til et forventet sluttidspunkt for denne delopgave. Når dette er fundet kan entreprenøren begynde at se på, hvornår der er ledige håndværker til at udføre de resterende opgaver. Her gælder det, at disse opgaver ikke kan gå i gang før det forventet sluttidspunkt, for den (eller de) opgave(r) de er afhængige af. Hvis opgaverne lyder på først at lave VVS-installationer og derefter opsætte fliser, må entreprenøren først se på, hvornår der er en blikkenslagere ledig til at lave VVS installationer og derefter finde en murer, der er ledig efter blikkenslageren forventes at være færdig. 7

10 Hvis kunden accepterer pris og tid kan arbejdet begynde. Mens arbejdet står på, er der stadig brug for koordination mellem de enkelte håndværkere. For det første må de enkelte håndværkere bookes, så de ikke bliver kaldt ud til andre opgaver i de perioder, de forventes at være på dette job. For det andet kan der i løbet af byggeriet opstå forsinkelser, eller der kan vise sig at opstå nye arbejdsopgaver, der har betydning for, hvornår de andre opgaver kan udføres. Der er derfor i hele forløbet behov for koordinering mellem de enkelte håndværkere. Dette eksempel illustrerer hvordan vi opfatter workflows som en mængde af mindre delopgaver, evt. med indbyrdes afhængigheder, der sammenlagt udgører et større hele. I dette eksempel kan man specificere selve udførelsen af renoveringen som et workflow. Her vil workflowet bestå af de delopgaver (opsætning af fliser, VVS-installationer etc.), der skal udføres for at gennemføre renoveringen. Eksemplet illustrerer også, hvordan enkelte workflows kan sammensættes til en større helhed. Set fra entreprenørens synsvinkel, er udførelsen af det konkrete arbejde blot en mindre del af et større workflow, hvor der også indgår budgettering af timer, booking af håndværkere etc. Sidst men ikke mindst illustrerer eksemplet, hvordan mobilitet kan spille en væsentlig faktor i afviklingen af et workflow. Entreprenøren har behov for at kunne tilgå workflowet, når arbejdet besigtiges hos kunden, ligesom håndværkerne har behov for at kunne tilgå workflowet, når arbejdet udføres. 1.3 Valg af workflowssprog Der findes mange forskellige workflowssprog. Vi har i dette speciale valgt at fokusere på sproget WS-BPEL[3]. Grunden til, at valget er faldet på WS- BPEL, er flere. WS-BPEL er det tætteste man i dag kommer på en standard inden for workflowssprog[11]. WS-BPEL er et industrieltsprog, som er udfaldet af et samarbejde mellem Microsoft, IBM og SAP[3]. Det, at sproget kommer fra industrien og ikke fra forskningsverdenen, giver nogle interessante udfordringer. Sproget er udformet til at kunne modellere konkrete eksempler fra virkeligheden, hvilket gør, at det gør brug af nogle avanceret funktioner som XPath, variabel håndtering og lign. I [2] identificeres der 20 generelle workflows mønstre der, ifølge Aalst et al, kan bruges til evaluering af workflowssprog. I [27, 35] evalueres WS- BPEL og andre workflows sprog i forhold til disse mønstre og det vises, at WS-BPEL er blandt de sprog hvori de fleste mønstre lader sig udtrykke. Sidst, men ikke mindst er WS-BPEL udtrykt i XML. Når vi allerede har en XML syntaks for sproget, er det vores formodning, at indkodningen i Reactive XML lettes, da flere konstruktioner hermed vil kunne oversættes direkte til Reactive XML. 8

11 Kapitel 2 Reactive XML Reactive XML[13, 39] er et system til koordinering af processer og data gemt som XML dokumenter. Reactive XML består på den ene side af en proceskalkyle kaldet dix (distributed, extensible Process Calculus), samt en distribueret implementation baseret på XML Store[12]. Det teoretiske fundament er stærkt inspireret af teorien om bigrafer[22]. Som i bigrafer er ideen bag dix, at lave en meta-model for reaktive systemer, hvori det er muligt at modellere domæne specifikke modeller. En sådan domæne specifik model kan herefter dage nytte af den generelle teori[13]. Vi vil i dette kapitel præsentere Reactive XML, samt se på mulighederne for at få Reactive XML implementeret på mobile enheder. Desuden vil vi tage en diskussion af, hvordan Reactive XML adskiller sig i forhold til standard WFMS, samt hvilken overordnet strategi, vi vil bruge i indkodningen af et workflowssprog i Reactive XML. Vi vil i det følgende simplificere ved brug af en forsimplet udgave af CCS[21] udtrykt ved følgende grammatik: P ::= 0 P P a!.p a?.p Hvor P P angiver at to processer kører parallelt. A.P angiver en sekventiel proces, hvor handlingen A udføres først og derefter udføres processen P. a! angiver en handling, hvor der sendes over kanalen a og a? angiver en handling, hvor der modtages på kanalen a. 0 er den tomme proces. Den tomme proces er processen der ikke udfører nogle handlinger. Vi vil ofte skrive A for processen A.0, der udfører handlingen A og derefter ikke udfører flere handlinger. 2.1 Processer som XML træer Grundstenen i Reactive XML er observationen af, at procesudtryk i reaktive systemer lader sig udtrykke i træer. En sekventiel proces som A 1.A 2 kan udtrykkes som følgende træ: 9

12 A 1 A 2 Et sådan træ kan direkte oversættes til XML. I dette tilfælde vil træstrukturen oversat til XML få følgende udtryk: <A1> <A2/> <A1> Parallelle processer kan udtrykkes som to træer. Da et XML dokument kun kan indeholde et træ, er denne strategi ikke bekvem for oversættelsen til XML. Derfor forsynes hver proces med en rodknude r. For at konstruere en parallel proces, føjer man de to rodknuder sammen og lader de to processer være hver sit undertræ[39]. Et eksempel på dette er vist i eksempel Eksempel Sammensætningen af parallelle processer. A 1.A 2 A 3.A 4 A 1.A 2 A 3.A 4 r A 1 r A 3 r A 1 A 3 A 2 A 4 A 2 A 4 Parallelle processer kan nu også udtrykkes direkte i XML. Den parallelle proces i eksempel 2.1.1, vil få følgende udtryk i XML: <r> <A1> <A2/> </A1> <A3> <A4/> </A3> </r> Udover at have et navn (som f. eks. A 1 eller A 2 ), kan en handling også have nogle attributter. Ser vi på synkroniseringshandling i CCS, vil en synkronisering mellem to processer kunne lade sig gøre, såfremt den ene proces kan sende på en navngivet kanal, og en anden parallel proces kan modtage på samme kanal. Vi har derfor behov for at udtrykke, at en given handling som f. eks. send, sender på en specifik kanal. Ved at udtrykke disse attributter som element attributter i XML, kan vi oversætte den forsimplede udgave af CCS som følger: 10

13 [P ] = <r>[p ] o </r> [a!.p ] o = <send ch="a">[p ] o </send> [a?.p ] o = <rec ch="a">[p ] o </rec> [0] o = ɛ [P P ] o = [P ] o [P ] o Fremfor at skulle definere en grammatik for hvert domæne der modelleres i Reactive XML, generaliseres processer udtrykt i XML ved dix kalkylen. Dette gøres ved at definere en signatur Σ = (Σ, N, Att, ar), hvor Σ er en mængde af kontroller, N er en uendelig mængde af navne, Att en endelig mængde af indekssæt, og ar : Σ Att en funktion, der tildeler et indekssæt til hver kontrol[13]. Ud fra denne signatur defineres nu procesudtryk med følgende grammatik[13]: w ::= wide.r Σ-processer r ::= r r reg.p 0 wide-processer p ::= κ{i : x i i ar(κ).p p p 1 prim-processer For κ Σ, x i N og wide, reg / Σ Wide processer angiver, at to processer kører parallelt et eller andet sted i systemet, men ikke nødvendigvis inde for samme lokalitet. Bemærk, at vi ved at indsætte de to specielle kontroller reg og wide, muliggør en direkte oversættelse til XML, uden at skulle indsætte en særlig rodknude. Dette er en ændring af syntaksen som fremlagt i [13], der ikke tager højde for, at der er behov for at indsætte en ekstra rodknude for at kunne oversætte til et gyldigt XML dokument. Vi oversætter procesudtryk ved hjælp af følgende oversættelse: [wide.r ] = <wide>[r ]</wide> [reg.p] = [p] [r r ] = [r ][r ] [0] = ɛ [κ{a i : x i ai ar(κ).p] = <κ a 1 ="x 1 "... a j ="x j ">[p]</κ> [p p ] = [p][p ] [1] = ɛ Vi kan nu definere vores forsimplede CCS kalkyle i Reactive XML, hvor Σ = {send, rec og ar(send) = ar(rec) = {ch. I det følgende vil vi anvende en forkortet notation, hvor vi udelader wide og reg således, at f. eks. wide.reg.p ofte skrives som p. 11

14 2.2 Reaktionsregler For at give semantik til vores procesudtryk defineres nogle reaktionsregler. For vores forsimplede udgave af CCS kalkylen vil vi gerne definere, at to processer kan synkronisere, såfremt der findes en send og rec kontrol, der kommunikerer på samme kanal. F. eks. vil vi gerne kunne udtrykke følgende reaktion (bemærk vi bruger dix notation): send{ch : a.p rec{ch : a.p p p For at kunne give en generel regel, og ikke bare en regel som ovenstående, der angiver, at synkronisering over kanalen a kan finde sted i det tilfælde, hvor kontrollen send er efterfulgt af processen p og rec af processen p indføres der kontekstudtryk. Et kontekstudtryk består af procesudtryk, huller og navnesubstitution. Et hul, [ ] j, angiver et sted, hvor en hvilken som helst proces kan indsættes. Navnesubstitutionen består i at erstatte navne - eller i XML terminologi, attributværdier, med værdier fra den proces, hvori kontekstudtrykket indsættes. Dog vil vi i visse tilfælde gerne kunne udtrykke, at en attributværdi skal have en fast værdi. Derfor indføres der i dix en skelnen mellem konstanter og variabler. Variabler angives ved at skrive attributværdien med kursiv og præfiks $. Den formelle definition af kontekstudtryk for en signatur Σ = (Σ, N, Att, ar) er som følger: W ::= σ wide.r Σ-proceskontekster R ::= R R reg.p 0 wide proceskontekster P ::= κ{i : x i i ar(κ).p P P 1 [ ] j prim proceskontekster Hvor σ er en endelig navnesubstitution, κ Σ og x i N. Som før vil vi ofte udelade de specielle kontroller reg og wide. Vi kan med kontekstudtryk nu udtrykke en generel udgave af reglen ovenfor: send{ch : $chn.[ ] 1 rec{ch : $chn.[ ] 2 [ ] 1 [ ] 2 I kontekstudtrykket på venstresiden af denne regel kan der indsættes parametrene p og p. Disse kan samles i en wide proces D = p p. Vi siger, at en wide proces har bredden j svarende til antallet af primprocesser, den er sammensat af. Ovenstående wide proces vil således have bredden 2. Indsætningen af wide udtryk i en kontekst sker ved, at den j te region indsættes i et hul med indeks j. Har vi en wide proces w = wide.(reg.p 1 reg.p 2... reg.p n ), kan denne indsættes i en kontekst W, hvor hullerne har indeks i{1... n. I ovenstående kontekstudtryk wide.reg.(send{ch : $chn.[ ] 1 rec{ch : $chn.[ ] 2 ) kan processen wide.(reg.p 1 reg.p 2 ) indsættes ved, at p 1 indsættes i hul med indeks 1 og p 2 i hul med indeks 2. 12

15 En proces p kan reagere, hvis der for en navnesubstitution findes en kontekst C, hvor kontekstudtrykket på venstresiden af reglen, indsat parametrene D, er lig p. Resultatet af denne reaktion vil være C, hvor højresiden af reglen er indsat med samme parametre. Lidt mere formelt kan vi sige, at for en reaktionsregel (R R ) kan en proces p reagere og ændre tilstand til C(R (D)σ) hvis p = C(R(D)σ) for en kontekst C, en navnesubstitution σ og et argument D, hvor D er en wide proces indeholdende parametrene. Aktive præfiks Generelt set ønsker vi ikke, at alle kontekster er aktive. Hvis vi ser på et udtryk som: send{ch : a.(send{ch : b rec{ch : b) Her har vi en proces, hvor der findes to parallelle processer, en send, samt en rec, der begge kommunikere over kanalen b. Ifølge ovenstående reaktionsregel vil denne proces kunne reagere. I den aktive reaktion har vi konteksten C = send{ch : a.[ ], R = send{ch : $chn.[ ] 1 rec{ch : $chn.[ ] 2, R = [ ] 1 [ ] 2, navnesubstitutionen σ($chn) = b og argumentet D = 1 1. Da vi i CCS kun ønsker, at processer, der står i præfiks (dvs. processer der ikke er indlejret i andre processer ved hjælp af. operatoren), er aktive, ønsker vi i dette tilfælde ikke, at denne reaktion er aktiv, førend processen send{ch : a er udført. For at kunne give sådanne restriktioner, indføres der i dix begrebet aktive præfiks[13]. De aktive præfiks Ξ Σ {wide, reg er en mængde af kontroller, der definerer hvilke kontekster, vi må indsætte kontekstudtryk i. Kun kontekster, hvor der udelukkende er aktive præfiks på stien ned til hullet, hvor kontekstudtrykket indsættes, er tilladte. Vi vil i det følgende betegne disse kontekster som evalueringskontekster. I vores CCS-eksempel kan vi definere, at ingen processer kan være aktive, medmindre de er de yderste processer i procesudtrykket, ved at definere mængden af aktive præfiks, Ξ, til kun at være de specielle kontroller wide og reg, således at Ξ = {reg, wide. Wide-reaktionsregler Med wide udtryk kan vi også definere wide regler. Som et eksempel på dette kan vi udvide vores CCS kalkyle sådan, at det er muligt for to processer at synkronisere, selvom de ikke er indenfor samme lokalitet. For at gøre dette udvider vi kalkylen til at indbefatte en kontrol, location, som modellerer en lokalitet. For at gøre det muligt for processer at kommunikere indenfor en location, erklærer vi denne som et aktivt præfiks. I Reactive XML får vi således følgende definition Σ = {send, rec, location, ar(send) = ar(rec) = {ch og Ξ = {wide, reg, location. 13

16 Vi kan nu forestille os følgende proces: location.send{ch : a.p location.rec{ch : a.p For at indfange, at de to processer send og rec kan synkronisere på trods af, at de ikke befinder sig inde for samme lokalitet, kan vi erklære følgende wide-reaktionsregel: send{ch : $chn.[ ] 1 rec{ch : $chn.[ ] 2 [ ] 1 [ ] 2 Med denne regel kan processen reagere og ændre tilstand til location.p location.p Wide regler er ikke implementeret i Reactive XML. I afsnit 5.1 vil vi diskutere hvordan vi kan gøre dette Reaktioner i XML Hver reaktionsregel tilføjes et navn, og vi udvider vores oversættelse med følgende for at få reaktionsregler udtrykt i XML: [[ ] j ] = <RULE HOLE NAME="j"/> [(R R, n)] = <REWRITE RULE NAME="n"> <RULE LEFT>[R]</RULE LEFT> <RULE RIGHT>[R ]</RULE RIGHT> </REWRITE RULE> Når der skal udføres en reaktion p p på processen p, handler det som nævnt om for en reaktionsregel (R R ) at finde en evalueringskontekst C E, sådan at p = C E (R(D)σ) og derefter beregne p = C E (R (D)σ). For at finde de aktive evalueringskontekster i p, bruges et XPath udtryk. Med et XPath udtryk kan vi udvælge de undertræer af p, der opfylder kriterierne om, at der udelukkende må være aktive præfiks på stien til dem. Hvis mængden af passive præfiks er Σ\Ξ = {κ 1,..., κ k, kan vi finde de undertræer, der opfylder betingelsen ved følgende XPath: XP ath(ξ) = //*not(ancestor-or-self::*[ name()= κ 1 or name()= κ 2 or... name()= κ k ]) Dette XPath-udtryk eksekveret på processen p, vil returnere en mængde af undertræer til p, der opfylder betingelsen at roden i undertræet, samt alle forældre til denne rod, er aktive præfiks. Hvis et undertræ til p, κ.(p p ), er fundet ved at eksekvere XPathen φ på p, sådan at p = E (κ.(p p )) er E (κ.(p [ ])), hvor κ Ξ, en evalueringskontekst. Hvis betingelsen, p = C E (R(D)σ) skal være opfyldt, og C E = E (κ.(p [ ])), og R er et primudtryk sådan, at R = reg.p, kan vi slutte, 14

17 at betingelsen p = P (D)σ skal være opfyldt, for at processen p kan reagere. Husk på, at når et kontekstudtryk indsættes i en kontekst fjerne vi reg kontrollerne. Derfor siger vi at p = P (D)σ og ikke p = R(D)σ. For at afgøre, hvorvidt der findes aktive reaktioner, laves en sammenligning af p og P, hvor alle mulige navnesubstitutioner afprøves. For at finde parameter til et evt. hul, findes først et match mellem de processer, der er søskende til hullet i P. Hvis der findes et match for alle disse, men p indeholder flere processer end dem, der er matchet med tilsvarende processer i P, indsættes disse resterende processer i hullet. Såfremt der er fundet et match, hvor alle processer i p er matchet mod en tilsvarende proces i P, indsættes den tomme proces i hullet. For hver kombination af σ og D, hvor p = P (D)σ, er der en aktiv reaktion. For at beregne resultatet af en af disse reaktioner, er alt der kræves, at beregne E κ(p R (D)σ). For helhedens skyld skal det nævnes, at den fulde oversættelse til XML af et sæt af reaktionsregler P React Σ,Ξ = {R 1 = (R 1 R 1 ),..., R n = (R n R n), sker ved at tilføje følgende til vores oversættelse: [P React Σ,Ξ ] = <REWRITE RULE SET CONSTRAINT="XP ath(ξ)"> [R 1 ][R 2 ]... [R n ] </REWRITE RULE SET> 2.3 Distribution af processer i Reactive XML Reactive XML tilbyder som nævnt en distribueret implementation. Den overordnede arkitektur er, at flere klienter gennem et peer-to-peer netværk kan dele en proces gemt i Reactive XML. På figur 2.1 er vist et sådan system, hvor fire klienter deles om en proces. Hver af de enkelte klienter har deres eget sæt af reaktionsregler, der kan bruges til at manipulere processen. Distribution af processen opnås gennem brug af XML Store[12, 28] XML Store XML Store er et værdiorienteret lagersystem til lagring af XML dokumenter. Det værdiorienterede koncept betyder, at knuder gemt i XML Store er uforanderlige. Derfor må der ved en ændring af en knude oprettes en ny. Den samme knude gemmes kun en gang i XML Store. Dette gøres ved at gemme knuderne under såkaldte value references(vref s). En vref beregnes på baggrund af indholdet af knuden (herunder også indholdet af evt. børn knuden måtte have). To knuder med samme indhold vil derfor have samme vref. Træstrukturen mellem de enkelte knuder opretholdes af pegere mellem knuderne. Da den samme knude kun gemmes en gang, må der være mulighed for, at en enkelt knude kan være en del af flere træer. Derfor peges der kun nedad i træet. En knude kender således sine børn, men ikke dens forældre. 15

18 Client 1 R 1 R 3 Client 3 XML Store p p Client 2 R 2 R 4 Client 4 Figur 2.1: Arkitekturen for distribution af processer i Reactive XML På grund af at de enkelte knuder er uforanderlige, må vi som nævnt oprette en ny knude ved ændring. Ved ændring af en knude nede i et træ må træet opbygges på ny, da de overliggende knuder har fået et nyt barn (den nye knude), og derved er ændret. På figur 2.2[13] er en sådan situation vist. Træet, der ønskes ændret, er vist i figur 2.2(a). Efter opdatering har træet en tilstand som vist på figur 2.2(b). For at kunne identificere et givent træ, kan en knude, ved hjælp af en såkaldt NameServer, bindes til en streng. For at vide hvilken rodknude i figur 2.2, der er den nyeste version af træet, kan rodknuden bindes til at navn. Når træet ændres, binder man nu dette navn til den nye rod. En sådan binding er således ikke værdiorienteret, men imperativ. Når et allerede bundet navn bindes til en ny knude, gøres dette ved hjælp af en atomisk compare-and-swap algoritme, der garanterer, at ingen har ændret bindingen i tiden t = [t read ; t swap ]. XML Store tilbyder distribution af træer gemt i XML Store gennem et peer-to-peer netværk. Når et XML Store oprettes, oprettes dette som et lokalt XML Store, der persisterer til den lokale disk. Et lokalt XML Store kan distribueres ved at dekorere det med en passende decorator[10], der tilbyder den ønskede funktionalitet. XML Store API et tilbyder bl. a. en DistributedXMLStore decorator, der sørger for den nævnte distribution gennem et peer-to-peer netværk. Udover peer-to-peer distribution, tilbyder XML Store også en klient/server distribution. Ved at bruge decorator-designmønstret opnås, at distributionen er gemt for applikationspro- 16

19 person floor room building status (bookedby: hniss) model room floor status (bookedby: none) room (a) person person floor room building status (bookedby: hniss) model room floor status (bookedby: none) room person (b) model building floor room status (bookedby: hilde) Figur 2.2: Genbrug af uændret knuder (de stiplede pile indikerer genbrug; fed tekst indikerer den nye sti oprettet efter ændringen). Figuren er sakset fra [13] grammøren, da et lokalt og et distribueret XML Store har samme interface Synkronisering af klienters ændringer Når det tillades, at flere klienter udfører reaktionsregler på den samme proces, er der behov for, at synkronisere samtidige ændringer fra flere klienter. Lad os antage, at to klienter, K 1 og K 2, læser processen p på samme tidspunkt. Begge beregner og udfører en reaktion. Hvis begge klienter laver en ændring i samme knude, i det træ der udgør p, vil den endelige udgave af p, når begge klienter har gemt deres ændring, kun indeholde ændringen fra den klient, der gemte sidst. Dette er et kendt problem i distribuerede systemer, og benævnes ofte som problemet med tabte opdateringer[6]. Et andet problem kan være, at den ene klient ændrer i data, som den anden bruger til at beregne en ændring. I dette tilfælde kan det være, at K 1 har fundet, at for en reaktionsregel (R R ), en evalueringskontekst E, en nanvesubstitution σ samt et argument D, er p = E(R(D)σ) og på baggrund af dette udføres reaktionen. Hvis K 2 i mellemtiden har ændret p, sådan at p E(R(D)σ), er der et problem, da de to reaktioner fra K 1 og K 2 ikke er uafhængige af den rækkefølge, de udføres i. Hvis K 2 havde udført sin reaktion før K 1 læste p, ville K 1 ikke have udført reaktionen. Vi siger, at ændringer fra to klienter er i konflikt, hvis de to ændringer, enten fører til tabte opdateringer, eller er afhængige af hinanden. Overordnet set findes der to forskellige løsninger til at håndtere disse problemer. En optimistisk og en pessimistisk synkroniseringsmodel[6]. I korte træk håndteres konflikter i den pessimistiske synkroniseringsmodel ved at låse data, sådan at en klient ikke får lov til at læse data, medmindre det kan garanteres, at der ikke er mulighed for konflikter (f. eks. hvis klienten ikke har til hensigt at ændre dataene). Den optimistiske, derimod, tillader 17

20 altid klienter at læse data, men validerer ændringer inden de persisteres. Hvis en validering ikke forløber tilfredsstillende, nægtes en klient at gemme sine ændringer. I Reactive XML synkroniseres ændringer ved hjælp af en optimistisk synkroniseringsmodel. Konflikter kan opdages, ved at se på, hvilken kontekst en given reaktion bruger. Hvis et udgangspunkt for en reaktionsregel R 1 er reaktionsregelen (R 1 R 1 ), og p = E 1(R 1 (D 1 )σ 1 ) med et efterfølgende resultat p = E 1 (R 1 (D 1)σ 1 ), ved vi, at forskelle mellem p og p må findes i det hul i E 1, hvor R 1 er indsat. Hvis t 1 er et undertræ til p, således at t 1 = R 1 (D 1 )σ 1 og p = E 1 (t 1 ) kan vi ligeledes fastslå, at alle forskelle mellem p og p må være at finde i undertræet t 1. Har vi nu en anden reaktion R 2, hvor udgangspunktet for reaktionen er p = E 2 (R 2 (D 2 )σ 2 ) og undertræet til p, t 2 = R 2 (D 2 )σ 2, kan vi nu udlede, at såfremt der ikke er nogen overlappende knuder mellem t 1 og t 2, vil de to reaktioner ikke ændre i de samme knuder. Samtidig kan vi fastslå, at de to reaktioner ikke er afhængige, da de to reaktioner ikke ændrer i stien til de huller, den anden bruger. Dvs., at selvom reaktionen R 1 er udført, vil der stadig eksistere en evalueringskontekst E 2, sådan at p = E 2 (t 2) og omvendt - efter at reaktionen R 2 er udført, vil der stadig eksistere en evalueringskontekst E 1, sådan at p = E 1 (t 1). Dette bruges i Reactive XML til implementeringen af en optimistisk synkroniseringsmodel, hvor alle klienter tillades, at læse den delte proces på ethvert tidspunkt. Når en klient har fundet en aktiv reaktion, og beregnet den nye tilstand for processen, undersøges det, hvorvidt andre klienter i mellemtiden har udført reaktioner. Hvis der er det, valideres denne reaktion nu i forhold til de andre reaktioner. Såfremt der ikke er konflikter, inkorporeres nu ændringerne fra de mellemliggende reaktioner, og det nye procesudtryk (nu indeholdende alle ændringer) gemmes, ved at binde roden i dette nye træ til det fælles navn for procesudtrykket. Hvis der er konflikter med nogen af de mellemliggende reaktioner, afbrydes operationen, og klienten tillades ikke at gemme sine ændringer. For at gøre det muligt, at gennemføre denne validering, er det nødvendigt for hver reaktion at gemme oplysninger om, hvilke ændringer der er fortaget. Dette indfanges ved brug af såkaldte versioner. En version indeholder det resulterende procesudtryk fremkommet ved en reaktion, samt et såkaldt changeset. Et changeset indeholder oplysninger om de ændringer, der er foretaget, for at få det originale procesudtryk (procesudtrykket som det så ud før reaktionen) til at ændre tilstand til det procesudtryk gemt i denne version. Mere specifikt gemmes det undertræ af procesudtrykket, der blev indsat i evalueringskonteksten (det vi benævnte t 1 eller t 2 i diskussion om opdagelse af konflikter), det træ som dette undertræ erstattes med, samt en sti udtrykt som en XPath til det sted i procesudtrykket, hvor ændringen har fundet sted. Det, der gemmes i XML Store, er således den seneste version af det delte procesudtryk, samt en liste af de versioner procesudtrykket har gennemgået, 18

21 for at opnå den nuværende tilstand. På grund af den deling af knuder, der foregår i XML Store (den samme knude gemmes kun engang, hvorefter flere træer kan oprette pegere til denne knude) undgås det, på trods af disse versioner, at gemme de samme dele af procesudtrykket igen og igen. En sideeffekt, ved at gemme disse changeset, er, at det på ethvert tidspunkt er muligt at gå tilbage, og se hvilke ændringer der er fortaget for at opnå en given tilstand. En god egenskab, hvis man f. eks. skal debugge en proces. 2.4 Reactive XML på mobile enheder Som nævnt i indledningen, er en del af motivationen for dette speciale, at få mulighed for at afvikle workflows på mobile enheder som PDA er og mobiltelefoner. Når vi bruger Reactive XML til afvikling af workflows, vil første skridt til at nå dette mål derfor være, at implementere Reactive XML på mobile enheder. Vi vil i dette afsnit diskutere forskellige muligheder for, at implementere Reactive XML på mobile enheder. Et væsentligt aspekt at holde i mente, når der diskuteres implementation på mobile enheder, er de begrænsede ressourcer, der er til rådighed på disse. Ofte er både hukommelse, processerkraft samt persistent lagerplads stærkt begrænset. En anden udfordring, man må være opmærksom på, er, at man ikke altid kan forvente, at have netværksforbindelse på en mobil enhed. Qua mobiliteten, kan den mobile enhed naturligvis ikke altid antages, at være et sted med netværksdækning. Dette kan skabe problemer med adgang til data, og kan efterlade den mobile enhed ubrugelig uden netværksdækning. Der er mange aspekter at tage højde for, hvis vi vil tillade operationer uden netværkstilslutning (disconnected operations). For det første skal de mobile klienter have mulighed for at læse data - også når de er offline. Dette problem kan løses, ved at cache data på den mobile enhed[16]. For at undgå, at de mobile enheder skal have en kopi af alt data liggende, kan man forestille sig en intelligent måde at cache på. I Reactive XML kunne dette f. eks. være, at man cacher nok data til at kunne udføre x antal reaktionsregler. En anden interessant workflowsspecifik vinkel på dette problem udforskes i [4, 8, 18]. Indgangsvinklen er her, at indrette workflowssprog således, at workflowssproget indeholder konstruktioner til at angive, at dele af et workflow kan udføres offline. Den mængde data, der er behov for på den mobile enhed, kan så beregnes på baggrund af disse. Når data caches på klienter, og klienter tillades at ændre dette, er der behov for en synkroniseringsmekanisme. Dette kan enten være en pessimistisk eller optimistisk model[16]. Disconnected operations er i sig selv et stort emne, og vi vil ikke her gå nærmere i detaljer. I stedet vil vi se lidt nærmere på de mere overordnede arkitektur modeller for de mobile enheder. I det følgende vil vi gennemgå fordele og ulemper ved følgende arkitekturer: 19

22 Fuld peer-to-peer netværk, hvor den mobile enhed indgår som en peer i et peer-to-peer netværk på lige fod med andre stationære enheder. Klient/Server, hvor den mobile klient indgår som klient i en klient/server løsning. Når klienten har brug for data, kontaktes en server. Klienten beregner reaktioner på baggrund af data modtaget fra serveren. En variant af denne model er, at lade klienten gemme de data, der modtages til senere brug (f. eks. til brug for disconnected operations). Tynd klient, hvor den mobile klient bruger både data og processerkraft fra serveren. Når en klient vil udføre en reaktion, henter den ikke data fra serveren, men lader serveren beregne de mulige reaktioner. Den mobile enhed vil i dette tilfælde kun agere som et interface til serveren, der udfører alle beregninger Peer-to-peer netværk Implementationen af et peer-to-peer netværk på en mobil enhed vil kræve ressourcer, både i form af lagerplads, men også i form af processerkraft og hukommelse til at tage sig af netværkstraffik. Hvis det skal være muligt, at køre en peer-to-peer klient på en mobil enhed, må man derfor, enten have en yderst effektiv implementation, eller begrænse sig til højtydende enheder. Et andet problem er, at et peer-to-peer netværk kan være meget udsat ved manglende netværksforbindelse. Hvis en peer forlader netværket, kan denne efterlade det resterende netværk ubrugeligt, såfremt denne peer ligger inde med vital data, der ikke er tilgængelig andre steder. Dette kan man dog tage højde for ved en tilstrækkelig replikation af data. F. eks. kunne man forestille sig, at en stationær peer altid opretholder en kopi af alt data. En brugbar implementation af et peer-to-peer netværk på mobile enheder er, grundet de begrænsede ressourcer, en stor udfordring. Der er dog interessante brugsscenarier for et peer-to-peer netværk på mobile enheder. Et af de mere interessante er muligheden for at få et netværk direkte mellem mobile enheder uden brug af en server. Man kan f. eks. forestille sig, at selv steder uden netværksforbindelse vil to mobile enheder have mulighed for, at dele data gennem andre kommunikationsprotokoller som f. eks. bluetooth. Dette vil åbne op for muligheden for mere ad hoc netværk, hvor mobile enheder danner netværk og udveksler data på baggrund af lokalitet. Med hensyn til disconnected operations vil sådanne ad hoc netværksforbindelser give mulighed for, at klienter kan synkronisere deres data og på den måde sikre en større konsistens i delte data, uden at skulle kontakte en server Klient/server Grundet de begrænsede ressourcer på de mobile enheder er en klassisk klient/server løsning et mere realistisk bud på en arkitektur til implementeringen 20

23 af Reactive XML på mobile enheder. Som nævnt i afsnit 2.3.1, kan XML Store også bruges i en klient/server opsætning. I afsnit 2.3 så vi, hvordan vi distribuerer processer i Reactive XML gennem et peer-to-peer netværk. En reel indsigelse mod at bruge en klient/server løsning til mobile enheder er derfor, at det kan blive komplekst, at skulle opretholde både et klient/server netværk (fra den mobile enhed til en stationær server), samt et peer-to-peer netværk (netværket mellem stationære Reactive XML klienter). Brugen af XML Store reducerer dog denne kompleksitet. En XML Store peer i et peerto-peer netværk kan tage rollen som server i et klient/server forhold. Når klienten i klient/server forholdet kontakter serveren for at hente data, sørger serveren for, at hente de korrekte data i det peer-to-peer netværk, den er del af. Dette betyder samtidig, at man ikke er begrænset af at skulle have en central server. Enhver peer i peer-to-peer netværket kan agere som server. Plan-X[12] tilbyder en minimal XML Store klient implementeret i Java Micro Edition(J2ME). Denne klient omfatter ikke XPath. En implementation af Reactive XML på mobile enheder vil derfor omfatte en implementation af XPath, en implementation af et J2ME brugerinterface, samt en oversættelse fra J2SE til J2ME af kildekoden til Reactive XML Tynd klient Den mest minimale implementering af Reactive XML på mobile enheder er, at bruge den mobile enhed som en tynd klient. Udgangspunktet for denne opsætning er en klient/server opsætning som beskrevet ovenfor. Fremfor at hente data på serveren, beder vi serveren om at eksekvere kode. Dvs. at hvis vi f. eks. skal finde aktive reaktioner, beder vi serveren om dette. Denne returnerer resultatet af beregningen, og dette kan nu præsenteres for brugen på den mobile enhed. På samme måde, når en reaktion skal udføres, beder vi serveren om at udføre reaktionen. Den store fordel ved denne opsætning er, at den mobile klient ikke skal bruge kræfter på andet, end at præsentere brugeren for skærmbilleder. Alle andre beregninger fortages af en server. Dette minimere kravene til ressourcerne på den mobile enhed. Ulempen er, at der altid er brug for en netværksforbindelse for at gøre noget som helst. Det er således ikke muligt, at have nogen form for disconnected operations med denne arkitektur. XML Store API et tilbyder en ExecXMLStore decorator, der muliggør er eksekvering af kode gemt i XML Store. Ved brug af denne, sammen med J2ME klienten, er det muligt at få kode eksekveret på et andet XML Store, der i denne henseende vil tage rollen som server. Implementationen af en tynd mobil klient til Reactive XML vil omfatte en J2ME GUI, samt implementering af det kode, der skal eksekveres i XML Store. 21

24 2.5 Reactive XML som WFMS Reactive XML adskiller sig i forhold til et mere traditionelt WFMS. Vi vil her kort skitsere hvordan. Et traditionelt WFMS er typisk opdelt i tre lag. En WFMS klient, en WFMS server, samt en relationel database[19]. Første lag, WFMS klienten, kører typisk på en slutbrugers pc, og sørger for at genere en brugergrænseflade. Klienten interagerer gennem en veldefineret grænseflade med WFMS serveren. Ved at interagere med denne, kan en bruger oprette workflowsbeskrivelser, der siden hen kan eksekveres. Når et workflow eksekveres, bruger WFMS serveren en relationel database til at gemme tilstandsdata[19]. Alt data der siger noget om hvor langt i processen et specifikt workflow er, er således gemt i en relationel database, og kan kun tilgås af WFMS serveren. I Reactive XML er tilstanden i en specifik proces gemt som et XML dokument i XML Store. Når en proces ændrer tilstand, sker det, ved at omskrive procesbeskrivelsen, og der er på denne måde ingen skelnen mellem procesbeskrivelse og tilstandsdata, der begge udtrykkes af samme XML dokument. Ved at distribuere dette XML dokument gennem XML Store opnår man i Reactive XML, at tilstanden af en proces distribueres. I et mere traditionelt WFMS system opnår man distribution, ved at flere klienter (eller andre kørende processer), gennem WFMS serveren, kan udføre på forhånd definerede operationer på et workflow. Selve tilstanden for workflowet er gemt i den relationelle database, og klienter eller andre kørende workflows har ikke adgang til denne. I Reactive XML har vi således, til forskel fra et traditionelt WFMS, distribution af en enkelt kørende proces. 2.6 Generelle betragtninger vedrørende indkodning af workflows i Reactive XML Når vi skal indkode workflows i Reactive XML, har vi to overordnede strategier at vælge imellem. Den ene er, at modellere workflows som en proceskalkyle, hvor de enkelte aktiviteter modelleres som processer. Når en aktivitet udføres, vil dette svare til en omskrivning af procesudtrykket, hvor processen repræsenterende den udførte aktivitet er fjernet. brydgulvop.lavv V S.opsætF liser lavv V S.opsætF liser Figur 2.3: Omskrivning af et procesudtryk når aktiviteten brydgulvop udføres Denne omskrivning er vist på figur 2.3. Hvis vi repræsenterer aktiviteter som procesudtryk, vil vi kunne skelne aktive (dvs. processer, der er parate til at blive udført) fra inaktive processer ved hjælp af deres position i proce- 22

25 sudtrykket. For at en proces skal kunne udføres, skal denne stå som det første i procesudtrykket. I procesudtrykket vist på figur 2.3 vil processen (eller aktiviteten) opsætf liser således ikke kunne udføres, før både brydgulvop og lavv V S er udført Reactive XML og Petri Net En anden måde at modellere workflows på, er ved hjælp af tilstandsmodeller som f. eks. Petri Net[29]. Petri Net er den første tilstandsmodel for samtidige synkroniserende processer, og er meget anvendt til beskrivelse af workflows[36]. I Petri Net foretager vi ikke nogen omskrivning. Derimod flytter vi brikker rundt mellem forskellige pladser. Et simpelt Petri Net består, udover brikker og pladser, af transitioner og orienterede forbindelser. Figur 2.4 viser et simpelt Petri Net. En brik kan flyttes fra en plads gennem en transition til en anden plads. Forbindelserne mellem transitioner og pladser angiver, hvordan brikkerne kan flytte rundt. P lads Brik T ransition brydgulvop lavv V S opsætf liser Figur 2.4: Et simpelt Petri Net I [23] giver Milner en indkodning af Petri Nets i bigrafer. Vi kan bruge denne indkodning til at indkode Petri Net i Reactive XML. I figur 2.5 er vist et lidt mere kompliceret Petri Net. Med Milners indkodning bruger vi to forskellige kontroller, m og u (marked, unmarked), til at angive pladser, henholdsvis med og uden en brik. Et alternativ til Milners indkodningen kunne være, at have en kontrol place og inde i denne placere de enkelte brikker. Dette alternativ vil have den fordel, at der på en enkelt plads kan være mere end en brik. Milners indkodning af transitioner, sker ved at oprette kontrollerne t hk for transitioner med h præbetingelser og k postbetingelser. Transitioner forbindes transitioner med pladser ved hjælp af attributter. 23