WORKFLOW CONTROL-FLOW PATTERNS A Revised View

Transcription

1 WORKFLOW CONTROL-FLOW PATTERNS A Revised View Nik Russell 1, Arthur H.M. ter Hofstede 1, 1 BPM Group, Queensland University of Tehnology GPO Box 2434, Brisbane QLD 4001, Australia {n.russell,a.terhofstede}@qut.edu.au Wil M.P. van der Aalst 1,2, Nataliya Mulyar 2 2 Department of Tehnology Management, Eindhoven University of Tehnology PO Box 513, NL-5600 MB Eindhoven, The Netherlands {w.m.p.v.d.aalst,n.mulyar}@tm.tue.nl Abstrat The Workflow Patterns Initiative was established with the aim of delineating the fundamental requirements that arise during business proess modelling on a reurring basis and desribe them in an imperative way. The first deliverable of this researh projet was a set of twenty patterns desribing the ontrol-flow perspetive of workflow systems. Sine their release, these patterns have been widely used by pratitioners, vendors and aademis alike in the seletion, design and development of workflow systems [vdathkb03]. This paper presents the first systemati review of the original twenty ontrol-flow patterns and provides a formal desription of eah of them in the form of a Coloured Petri-Net (CPN) model. It also identifies twenty three new patterns relevant to the ontrol-flow perspetive. Detailed ontext onditions and evaluation riteria are presented for eah pattern and their implementation is assessed in fourteen ommerial offerings inluding workflow and ase handling systems, business proess modelling formalisms and business proess exeution languages. 1 Introdution It has been seven years sine the Workflow Patterns Initiative first ommened identifying the ore arhitetural onstruts inherent in workflow tehnology [vdabthk00, vdathkb03]. The original objetive was to delineate the fundamental requirements that arise during business proess modelling on a reurring basis and desribe them in an imperative way. A patterns-based approah was taken to desribing these requirements as it offered both a language-independent and tehnology-independent means This researh is onduted in the ontext of the Patterns for Proess-Aware Information Systems (P4PAIS) projet whih is supported by the Netherlands Organisation for Sientifi Researh (NWO). It is also reeives partial support from the Australian Researh Counil under the Disovery Grant Expressiveness Comparison and Interhange Failitation between Business Proess Exeution Languages. 1

2 of expressing their ore harateristis in a form that was suffiiently generi to allow for its appliation to a wide variety of offerings. One of the drivers for this researh was the observation that although many workflow systems were based on similar oneptual underpinnings, they differed markedly in their expressive power and the range of onepts that they were able to apture. Indeed these differenes were so signifiant that it raised the question of how the suitability of speifi tools for speifi purposes might be evaluated. Despite the plethora of workflow systems in both the ommerial and researh domains, there was a notable absene of ore foundational onepts that individual offerings ould be expeted to support or that ould be used as a basis for omparison. This absene differs markedly from other areas of information systems suh as database design or transation management whih are based on formal oneptual foundations that have effetively beome de fato standards. In line with the traditional patterns approahes employed by Alexander [AIS77] and the Gang of Four [GHJV95], that are based on broad survey of existing problems and praties within a partiular domain, the original twenty ontrol-flow patterns were identified through a omprehensive evaluation of workflow systems and proess modelling formalisms. They desribe a series of onstruts that are embodied in existing offers in response to atual modelling requirements. The imperative approah employed in their desription ensures that their intent and funtion is learly presented without mandating a speifi implementation approah. An overriding objetive was that they desribe ontrol-flow harateristis whih it would be desirable to support in a given offering. The publiation of the original patterns in 2000 [vdathkb03] had a galvanising effet on the workflow ommunity. It provided larity to onepts that were not previously well-defined and provided a basis for omparative disussion of the apabilities of individual workflow systems. Amongst some vendors, the extent of patterns support soon beame a basis for produt differentiation and promotion. Although initially foussed on workflow systems, it soon beame lear that the patterns were appliable in a muh broader sense and they were used to examine the apabilities of business proess modelling languages suh as BPMN, UML Ativity Diagrams and EPCs, web servie omposition languages suh as WCSI and business proess exeution languages suh as BPML, XPDL and BPEL. Their overage was also extended to the other lassial workflow perspetives [JB96] and a series of new patterns were identified in the data [RtHEvdA05], resoure [RvdAtHE05] and exeption [RvdAtH06] perspetives. These patterns have been used to extend the reviews desribed above and have provided a series of new insights into the apabilities of partiular offerings. The ontrol-flow patterns have been subjet to ongoing srutiny over the past few years partiularly in terms of their ompleteness and preision. In order to ensure their ontinued relevane, a omprehensive review of the ontrol-flow perspetive has been onduted over the past six months, the results of whih are presented in this doument. As well as assessing their ontinued appliability, one of the major objetives of this review was to thoroughly overhaul the desription of eah of the patterns and to put them on a more formal footing to remove any potential ambiguities that may have previously existed. This has been ahieved by augmenting eah pattern desription with a Coloured Petri-Net model [Jen97] desribing its operation. There is also a more detailed disussion of the operational ontext in whih eah of the pat- 2

3 terns is intended to funtion and a speifi set of evaluation riteria whih desribe how pattern support is assessed in an offering. This review has onfirmed the ontinued appliability of the original twenty patterns, all of whih ontinue to be widely supported. It has also identified twenty three new patterns whih are appliable to the ontrol-flow perspetive, some of whih are based on refinements of the original patterns and many of whih are the result of ritial assessment of additional fators whih are relevant to the ontrol-flow perspetive. A omprehensive review of patterns support has been onduted in fourteen distint offerings inluding workflow systems (Staffware, WebSphere MQ, COSA, iplanet, SAP Workflow and FileNet), ase handling systems (FLOWer), business proess modelling languages (BPMN, UML 2.0 Ativity Diagrams and EPCs) and business proess exeution languages (BPEL4WS, WebSphere BPEL, Orale BPEL and XPDL). The remainder of this paper proeeds as follows: Setion 2 provides bakground information on the patterns and disusses related work. Setion 3 presents a ompletely revised set of desriptions for the original twenty patterns. Setion 4 douments the new ontrol-flow patterns that have been identified. Setion 5 disusses the results of the produt evaluations whih have been onduted using the omplete set of patterns. Setion 6 disusses the relationships whih exist between the patterns and Setion 7 onludes the paper. 2 Bakground and Related Work The notion of patterns as a means of ategorising reurring problems and solutions in a partiular domain is generally attributed to Christopher Alexander [AIS77] as is the onept of a patterns language for desribing the inter-relationships between speifi patterns. The original patterns work entred on the field of arhiteture, however the onept has general appliability and has been used widely in a number of other domains. It has had most impat however in the field of information tehnology where patterns have been used to ategorise the major onepts in a number of areas inluding system design [GHJV95], business analysis [Hay95, Fow96], business proess design [EP00], software arhiteture [BMR + 96, SSRB00] and enterprise appliation integration [HW04]. The appliation of a patterns-based approah to the identifiation of generi workflow onstruts was first proposed in [vdabthk00], whih identified several ontrolflow patterns relevant to the ontrol-flow perspetive of workflow systems. This work was subsequently expanded to enompass twenty ontrol-flow patterns together with a formalisation and analysis of their implementation in fifteen ommerial and researh workflow systems. This work triggered researh efforts in two main diretions: the first of these being the use of the patterns to establish a formal basis for understanding the requirements of the ontrol-flow perspetive, the seond being the use of the patterns to evaluate the apabilities of a series of business proess modelling languages and web servies standards. In [Kie03], the patterns were used to motivate an investigation into the fundamentals of workflow tehnology, in partiular the expressiveness of various approahes to implementing ontrol-flow onstruts in workflow systems. In [DtH01], 3

4 they were first utilised to examine the apabilities of speifi modelling languages, in this ase UML 1.4 Ativity Diagrams, in an effort to understand its strengths, weaknesses and also to suggest areas for possible improvement. This researh strategy led to a series of subsequent investigations into the expressiveness of languages inluding BPEL4WS [WvdADtH03], BML [WPDtH03], UML 2.0 Ativity Diagrams [WvdAD + 05b, RvdAtHW06] and BPMN [Whi04, WvdAD + 05a]. The original workflow patterns foussed on the ontrol-flow perspetive, however as noted in [JB96], a omprehensive desription of a workflow proess also requires onsideration of the data and resoure perspetives. With this requirement in mind, the Workflow Patterns Initiative was subsequently extended to inlude 40 patterns in the data perspetive [RtHEvdA05] and 43 patterns in the resoure perspetive [RtHEvdA05, RvdAtHE05]. Subsequent researh [RvdAtH06] has also investigated inter-relationships between these perspetives and has proposed a patterns-based approah to workflow exeption handling. There has also been researh into the use of patterns for haraterising servie interations [BDtH05]. Most reently, the Workflow Pattern Speifiation Language (WPSL) [MvdAtHR06] has been developed. This is a formal language motivated by the workflow patterns whih provides a deterministi basis for apturing and omparing the ontrol-flow apabilities of Proess-Aware Information Systems (PAISs). The workflow patterns have provided the oneptual basis for the YAWL workflow system [vdath05]. YAWL is an aronym for Y et Another W orkflow Language, an initiative that aims to provide both a workflow language that is based on the workflow patterns and also an open-soure referene implementation that demonstrates the manner in whih these onstruts an interoperate. Sine their release, the workflow patterns have been used for a wide variety of purposes inluding evaluation of PAISs, tool seletion, proess design, eduation and training. They have been enthusiastially reeived by both industry pratitioners and aademis alike. The original Workflow Patterns paper has been ited by over 150 aademi publiations and the workflow patterns website has been visited more than 40,000 times. Full details an be found at The webpage also ontains an impat page desribing the tangible effet of the patterns. Many organizations around the globe and in partiular in The Netherlands have used the patterns for workflow management system seletion. The patterns have also diretly influened the development of many aademi and ommerial tools and have influened the development of standards inluding BPMN and BPEL. The ontribution of this paper to the problem domain is twofold: (1) it provides a ritial evaluation of the existing patterns on a formal basis using CPN Tools and (2) it defines 23 new patterns whose semantis are also formalised and expressed in terms of CPN Tools. 3 A Review of the Original Control-Flow Patterns In this setion, we examine the original twenty ontrol-flow patterns and revise their definitions. The format in whih eah pattern is presented has been signifiantly expanded to inorporate a more detailed desription of the pattern and a more omprehensive rationale for its usage. One of the major areas of ambiguity in regard to the original desriptions related 4

5 to varying interpretations of their appliability and operation. In an effort to remove this area of unertainty, we provide a detailed definition of the operational semantis of eah pattern in the form of a Coloured Petri-Net (CPN) diagram 1 [Jen97] together with the ontext onditions that apply to the pattern. One again, we examine the operational support for the pattern aross a series of ontemporary offerings in the business proess management field and we extend the range of produts we review to inlude not only urrent ommerial workflow and ase handling produts, but also business proess modelling notations suh as BPMN, EPCs and UML 2.0 Ativity Diagrams and business proess exeution languages suh as XPDL and BPEL. A signifiant hange in the manner in whih this proess is undertaken is the establishment of a definitive set of evaluation riteria for rating patterns support in a given offering. Details of these riteria are inluded for eah pattern. 3.1 Review and Augmentation of the Original Control-Flow Patterns The original set of twenty patterns in the ontrol-flow perspetive were derived from a detailed examination of ontemporary workflow systems and business proess modelling notations in order to identify generi, reurring onstruts. They have proven to be extremely popular with both theoretiians and pratitioners alike as they provide a useful basis for disussing and omparing the apabilities and expressiveness of individual offerings in a manner whih is independent of speifi modelling formalisms and implementation tehnologies. More reently, it has beome lear that there are a number of additional senarios in the ontrol-flow perspetive that require ategorization. Moreover, there are several of the original patterns that would benefit from a more preise desription in order to remove potential ambiguities in relation to the onepts that they are intended to represent. Indeed with a more rigorous foundation, it beomes possible to further refine several of the patterns into forms that more effetively desribe and distinguish between the distint situations to whih they might be appliable. As a onsequene of this refletion there have been some hanges to the existing pattern definitions and the identifiation of twenty three new patterns, some of them new and some based on speializations of existing patterns. The original Synhronizing Merge pattern did not adequately differentiate between possible ontext assumptions, eah of whih has a distint semantis. Consequently, it has now been divided into three distint patterns: the Strutured Synhronizing Merge (WCP-7), whih restrits the original pattern to use in a strutured workflow ontext and sees it take the form of a join whih is paired with a speifi preeding Multi-Choie i.e. there is a one-to-one orrespondene between split and join; the Ayli Synhronizing Merge (WCP-37), whih reognizes tratable OR-join implementations, based on onventions suh as true/false token passing, whih allow their evaluation to be based on information diretly available to the merge (i.e. loal semantis) but whih are unable to deal with loops; and 1 We use CPN Tools for preparation and validation of these models, opies of whih are available from More details on CPN Tools an be found at wiki.daimi.au.dk/pntools/ 5

6 the General Synhronizing Merge (WCP-38), whih denotes a general solution to OR-join evaluation based on a thorough analysis of the urrent and potential future states of a proess instane (i.e. non-loal semantis). In a similar vein, the original Disriminator pattern did not differentiate between distint implementation approahes and the degree to whih they were able to deal with onurreny within a proess instane. It is now reognized as having three distint forms: the Strutured Disriminator (WCP-9), where it operates in a safe and strutured workflow ontext (i.e. it is assumed that eah branh exeutes preisely one before a reset takes plae and there is a one-to-one orrespondene between splits and joins); the Bloking Disriminator (WCP-28), where onurreny within a proess instane is dealt with by bloking additional exeution threads within a given branh until the disriminator has reset; and the Canelling Disriminator (WCP-29), where remaining inoming branhes whih are still exeuting after the disriminator fires are anelled. The Partial (or N-out-of-M) Join pattern, whih had previously only been denoted as a sub-ase of the Disriminator, is now also reognized as a pattern in its own right with three distint forms: the Strutured Partial Join (WCP-30), the Bloking Partial Join (WCP-31) and the Canelling Partial Join (WCP-32). The Strutured Loop (WCP-21) pattern has been introdued to deal with more restritive forms of iteration suh as while and repeat loops whih are not adequately overed by the Arbitrary Cyles pattern. Similarly the Reursion pattern (WCP-22) overs repetitive ativity exeution whih is based on self-invoation. Existing multiple instane patterns assume that all ativity instanes must omplete before a subsequent ativity an be enabled. In reognition that more effiient means exist of implementing onurreny with respet to overall proess exeution and determination as to when the proess an proeed beyond the multiple instane task, three new patterns have been introdued: the Stati Partial Join for Multiple Instanes (WCP-34), the Canelling Partial Join for Multiple Instanes (WCP-35) and the Dynami Partial Join for Multiple Instanes (WCP-36). The ability to respond to external signals within a proess instane was not well overed by the original patterns other than by the Deferred Choie (WCP-16) whih allows a deision regarding possible exeution paths to be based on environmental input. To remedy this, two new patterns are introdued to denote the ability of external signals to affet proess exeution. These are the Transient Trigger (WCP- 23) and the Persistent Trigger (WCP-24). The Interleaved Parallel Routing pattern (WCP-17) is extended to two new patterns: the Critial Setion pattern (WCP-39), whih provides the ability to prevent onurrent exeution of speifi parts of a proess; and the Interleaved Routing pattern (WCP-40), whih denotes situations where a group of ativities an be exeuted sequentially in any order. Previous notions of anellation only related to individual ativities and omplete proess instanes (ases). In order to deal with anellation in a more general sense, 6

7 the Canel Region pattern (WCP-25) has been introdued, whih allows for arbitrary groups of ativities in a proess to be anelled during exeution. Similarly, in reognition that the semantis of anelling a multiple instane ativity is different to those assoiated with anelling a normal ativity, the Canel Multiple Instane Ativity (WCP-26) pattern has also been inluded and there is also a Complete Multiple Instane Ativity (WCP-27) to handle the situation where a multiple instane ativity is fored to omplete during exeution. Other new inlusions are the Generalised AND-Join pattern (WCP-33) whih defines a model of AND-join operation for use in highly onurrent proesses, Thread Merge (WCP-41) and Thread Split (WCP-42) whih provide for oalesene and divergene of distint threads of ontrol along a single branh and Expliit Termination (WCP-43) whih provides an alternative approah to defining proess ompletion. 3.2 Context Assumptions As far as possible, eah pattern is illustrated using the Coloured Petri-Net (CPN) formalism. This allows us to provide a preise desription of eah pattern that is both deterministi and exeutable. This approah beomes inreasingly important with some of the revised pattern definitions (as well as for some of the new patterns) as the atual ontext in whih the pattern an our requires detailed desription. There are some blanket assumptions that apply to all of the CPN models used in this paper. For eah of them, we adopt a notation in whih input plaes are labelled i1...in, output plaes are labelled o1...on, internal plaes are labelled p1...pn and transitions are labelled A...Z. In the ase where either plaes or transitions serve a more signifiant role in the ontext of the pattern, they are given more meaningful names (e.g. buffer or anti-plae). In general, transitions are intended to represent tasks or ativities in proesses and plaes are the preeding and subsequent states whih desribe when the ativity an be enabled and what the onsequenes of its ompletion are. Unless stated otherwise, we assume that the tokens flowing through a CPN model that signify ontrol-flow are typed (short for Case ID ) and that eah exeuting ase (i.e. proess instane) has a distint ase identifer. For most patterns, the assumption is also made that the model is safe i.e. that eah plae in the model an only ontain at most one token (i.e. one thread of ontrol for eah ase urrently being exeuted). This provides larity in regard to the way in whih eah of the CPN models desribing pattern operation are intended to funtion. Safe behaviour is not a mandatory quality of workflow systems. Some of the systems that we examine during the ourse of this paper, do implement safe proess models whilst others do not. Where a system does provide a safe exeution environment, this is typially ahieved in one of two ways: either (1) during exeution, the state of a given ase is never allowed to transition into an unsafe state. This is the approah adopted by COSA, whih bloks an ativity s exeution where it has a token in the plae immediately after it and allowing it to exeute ould potentially result in an unsafe state (i.e. the following plae having two tokens in it). The other alternative (2) is to detet any unsafe situations that may arise and migrate them to safe states. An example of this is the strategy employed by Staffware (often referred to as the Pa-Man approah ) where any additional triggerings reeived by an ativity that is urrently exeuting are oalesed into the same thread of ontrol 7

8 resulting in a single thread of ontrol being delivered to outgoing branhes when the ativity ompletes. These variations in the ways in whih distint offerings implement onurreny with a proess instane lead to differenes in the ranges of patterns that they are able to support and the means by whih they realise them. In the following setions, we will provide preise desription of eah pattern and examine the approahes to their implementation taken by various workflow tools and business proess modelling languages. 3.3 Revisiting the Original Patterns This setion presents a revised desription of the original twenty ontrol-flow patterns previously presented in [vdathkb03]. Although this material is motivated by earlier researh onduted as part of the Workflow Patterns Initiative 2, the desriptions for eah of these patterns have been thoroughly revised and a new set of evaluations have been undertaken. In several ases, detailed review of a pattern has indiated that there are potentially several distint ways in whih the original pattern ould be interpreted and implemented. In order to resolve these ambiguities, we have taken the deision to base the revised definition of the original pattern on the most restritive interpretation of its operation and to delineate this from other possible interpretations that ould be made. In several situations, a substantive ase exists for onsideration of these alterative operational senarios and where this applies, these are presented in the form of new ontrol-flow patterns in Setion Basi Control-Flow Patterns This lass of patterns aptures elementary aspets of proess ontrol and are similar to the definitions of these onepts initially proposed by the Workflow Management Coalition (WfMC) [Wor99]. Pattern WCP-1 (Sequene) Desription An ativity in a workflow proess is enabled after the ompletion of a preeding ativity in the same proess. Synonyms Sequential routing, serial routing. Examples The verify-aount ativity exeutes after the redit ard details have been aptured. The odail-signature ativity follows the ontrat-signature ativity. A reeipt is printed after the train tiket is issued. Motivation The Sequene pattern serves as the fundamental building blok for workflow proesses. It is used to onstrut a series of onseutive ativities whih exeute in turn one after the other. Two ativities form part of a Sequene if there is a ontrol-flow edge from one of them to the next whih has no guards or onditions assoiated with it. Context Figure 1 illustrates the Sequene pattern using the Coloured Petri-Net (CPN) formalism. 2 See for further details. 8

9 i1 A p1 B o1 Figure 1: Sequene pattern Implementation The Sequene pattern is widely supported and all of the workflow systems and business proess modelling languages examined diretly implement it. Issues Although all of the offerings examined implement the Sequene pattern, there are however, subtle variations in the manner in whih it is supported. In the main, these differenes entre on how individual offerings deal with onurreny within a given proess instane and also between distint proess instanes. In essene these variations are haraterised by whether the offering implements a safe proess model or not. In CPN terms, this orresponds to whether eah of the plaes in the proess model suh as that in Figure 1 are 1-bounded (i.e. an only ontain at most one token for a ase) or not. Solutions This issue is handled in a variety of differing ways. BPMN, XPDL and UML 2.0 Ativity Diagrams assume the use of a token-based approah to managing proess instanes and distinguishing between them, although no details are given as to how this atually ours. Further, although individual tokens are assumed to be onserved during exeution of a proess instane, it is possible for an ativity, split or join onstrut to speifially add or remove tokens during exeution beyond what would reasonably be expeted. Staffware simply ignores the issue and where a step reeives two threads (or more) of exeution at the same time, they are simply oalesed into a single firing of the step (thus resulting in rae onditions). COSA adopts a prevention strategy, both by implementing a safe proess model and also by disabling the ativity(s) preeding a urrently enabled ativity and not allowing the preeding ativity(s) to fire until the subsequent ativity has ompleted. Evaluation Criteria Full support for this pattern is demonstrated by any offering whih is able to provide a means of speifying the exeution sequene of two (or more) ativities. This may be based on direted ars between ativities or rules speifying the overall exeution sequene. Pattern WCP-2 (Parallel Split) Desription The divergene of a branh into two or more parallel branhes eah of whih exeute onurrently. Synonyms AND-split, parallel routing, parallel split, fork. Examples After ompletion of the apture enrolment ativity, run the reate student profile and issue enrolment onfirmation ativities simultaneously. When an intrusion alarm is reeived, trigger the despath patrol ativity and the inform polie ativity immediately. One the ustomer has paid for the goods, issue a reeipt and pak them for despath. Motivation The Parallel Split pattern allows a single thread of exeution to be split into two or more branhes whih an exeute ativities onurrently. These branhes may or may not be re-synhronized at some future time. 9

10 Context Figure 2 illustrates the implementation of the Parallel Split. After ativity A has ompleted, two distint threads of exeution are initiated and ativities B and C an proeed onurrently. i1 A p1 p2 B C o1 o2 Figure 2: Parallel split pattern Implementation The Parallel Split pattern is implemented by all of the offerings examined. It may be depited either expliitly or impliitly in proess models. Where it is represented expliitly, a speifi onstrut exists for the Parallel Split with one inoming edge and two or more outgoing edges. Where it is represented impliitly, this an be done in one of two ways: either (1) the edge representing ontrol-flow an split into two (or more) distint branhes or (2) the ativity after whih the Parallel Split ours has multiple outgoing edges whih do not have any onditions assoiated with them. Of the offerings examined, Staffware, WebSphere MQ, FLOWer, COSA and iplanet represent the pattern impliitly. SAP Workflow, EPCs and BPEL 3 do so with expliit branhing onstruts. UML 2.0 ADs, BPMN and XPDL allow it to be represented in both ways. Issues None identified. Solutions N/A. Evaluation Criteria Full support for this pattern is demonstrated by any offering that provides a onstrut (either impliit or expliit) that allows the thread of ontrol at a given point in a proess model to be split into two or more onurrent branhes. Pattern WCP-3 (Synhronization) Desription The onvergene of two or more branhes into a single subsequent branh suh that the thread of ontrol is passed to the subsequent branh when all input branhes have been enabled. Synonyms AND-join, rendezvous, synhronizer. Examples The despath-goods ativity runs immediately after both the hek-invoie and produe-invoie ativities are ompleted. 3 In general, the two BPEL implementations examined WebSphere BPEL (whih is part of WebSphere Proess Server) and Orale BPEL provide a relatively faithful implementation of the BPEL 1.1 speifiation hene the evaluation results are idential for all three offerings. For this reason in this paper we do not list them individually unless there is a variation between them. 10

11 Cash-drawer reoniliation an only our when the store has been losed and the redit ard summary has been printed. Motivation Synhronization provides a means of reonverging the exeution threads of two or more parallel branhes. In general, these branhes are reated from a parallel split (AND-split) onstrut earlier in the proess model. The thread of ontrol is passed to the ativity immediately following the synhronizer one all of the inoming branhes have ompleted. Context The behaviour of the Synhronization pattern is illustrated by the CPN model in Figure 3. There are two important ontext onditions assoiated with this pattern: (1) eah inoming branh exeutes preisely one for a given ase and (2) the synhronizer an only be reset (and fire again) one eah inoming branh has ompleted. These onditions are important sine if all inoming branhes do not omplete, then the synhronizer will deadlok and if more than one trigger is reeived on a branh, then the behaviour of the onstrut is undefined. They also serve to alleviate the onern as to whether all of the threads being synhronized relate to the same proess instane. This issue beomes a signifiant problem in joins that do not have these restritions. i1 i2 A B p1 p2 C o1 Figure 3: Synhronization pattern Implementation Similar to the Parallel Split pattern, the synhronizer an either be represented expliitly or impliitly in a proess model. Staffware has an expliit AND-join onstrut as do SAP Workflow, EPCs, BPMN and XPDL. Other offerings WebSphere MQ, FLOWer, COSA, iplanet and BPEL represent this pattern impliitly through multiple inoming (and unonditional) ontrol edges to an ativity. Only when eah of these ars has reeived the thread of ontrol an the ativity be enabled. UML 2.0 ADs allow it to be represented in both ways. Issues The use of the Synhronization pattern an potentially give rise to a deadlok in the situation where one of the inoming branhes fails to deliver a thread of ontrol to the join onstrut. This ould be a onsequene of one of the ativities in the branh failing to omplete suessfully (e.g. as a onsequene of it experiening some form of exeption) or beause the thread of ontrol is passed outside of the branh. Solutions None of the workflow systems or business proess exeution languages examined provide support for resolving this issue where the problem is aused by ativity failure in one of the inoming branhes however the strutured nature of this pattern generally ensures that the seond possible ause of deadlok does not arise. Evaluation Criteria Full support for this pattern is demonstrated by any offering whih provides a onstrut to merge several distint threads of exeution in different branhes into a single thread of exeution in a single branh. The merge ours when a thread of ontrol has been reeived on eah of the inoming branhes. 11

12 Pattern WCP-4 (Exlusive Choie) Desription The divergene of a branh into two or more branhes. When the inoming branh is enabled, the thread of ontrol is immediately passed to preisely one of the outgoing branhes based on the outome of a logial expression assoiated with the branh. Synonyms XOR-split, exlusive OR-split, onditional routing, swith, deision, ase statement. Examples Depending on the volume of earth to be moved, either the dispath-bakhoe, despathbobat or despath-d9-exavator ativity is initiated to omplete the job. After the review eletion ativity is omplete, either the delare results or the reount votes ativity is undertaken. Motivation The Exlusive Choie pattern allows the thread of ontrol to be direted to a speifi ativity depending on the outome of a preeding ativity, the values of elements of speifi data elements in the workflow or the results of a user deision. The routing deision is made dynamially allowing it to be deferred to the latest possible moment at runtime. Context The behaviour of the Exlusive Choie pattern is illustrated by the CPN model in Figure 4. Depending on the results of the ond expression, the thread of ontrol is either routed to ativity B or C. There are two ontext onditions assoiated with this pattern: (1) the information required to alulate the logial onditions on eah of the outgoing branhes must be available at runtime at the point at whih the hoie onstrut is reahed in the proess and (2) the ondition assoiated with preisely one outgoing branh of the exlusive hoie onstrut must evaluate to true. i1 if ond then 1 else empty A p1 B o1 if ond then empty else 1 p2 C o2 Figure 4: Exlusive hoie pattern Implementation Similar to the Parallel Split and Synhronization patterns, the Exlusive Choie pattern an either be represented expliitly via a speifi onstrut or impliitly via disjoint onditions on the outgoing ontrol-flow edges of an ativity. Staffware, SAP Workflow, XPDL, EPCs and BPMN provide expliit XOR-split onstruts. In the ase of Staffware, it is a binary onstrut where as other offerings support multiple outgoing ars. BPMN and XPDL provide for multiple outgoing edges as well as a default ar. Eah edge has a ondition assoiated with it and there is also the potential for defining the evaluation sequene but only one an evaluate to true at runtime. There is no provision for managing the situation where no default is speified and none of the branh onditions evaluate to true nor where more than one branh ondition evaluates to true (simultaneously) and no evaluation sequene is speified. SAP Workflow provides three distint means of implementing 12

13 this pattern: (1) based on the evaluation of boolean expression one of two possible branhes hosen, (2) one of multiple possible branhes is hosen based on the value of a speifi data element (eah branh has a nominated set of values whih allow it to be seleted and eah possible value is assigned to exatly one branh) and (3) based on the outome of a preeding ativity, a speifi branh is hosen (a unique branh is assoiated with eah possible outome). UML 2.0 ADs also provide a dediated split onstrut although it is left to the auspies of the designer to ensure that the onditions on outgoing edges are disjoint (e.g. the same onstrut an be used for OR-splits as well). Likewise EPCs support the pattern in a similar fashion. The other offerings examined WebSphere MQ, FLOWer, COSA, iplanet and BPEL represent the pattern impliitly, typially via onditions on the outgoing ontrol-flow edges from an ativity whih must be speified in suh a way that they are disjoint. Issues One of the diffiulties assoiated with this pattern is ensuring that preisely one outgoing ar is triggered when the Exlusive Choie is enabled. Solutions The inlusion of default outgoing ars on XOR-split onstruts is an inreasingly ommon means of ensuring that an outgoing ar is triggered (and hene the thread of ontrol ontinues in the branh) when the XOR-split is enabled and none of the onditions on outgoing branhes evaluate to true. An assoiated issue is ensuring that no more than one branh is triggered. There are two possible approahes to dealing with this issue where more than one of the ar onditions will potentially evaluate to true. The first of these is to simply selet one of these ars and allow it to proeed whilst ensuring that none of the other outgoing ars are enabled. The seond option, whih is more pratial in form, is to assign an evaluation sequene to the outgoing ars whih defines the order in whih ar onditions will be evaluated. The means of determining whih ar is triggered then beomes one of evaluating the ar onditions in sequential order until one evaluates to true. The ar is then triggered and the evaluation stops (i.e. no further ars are triggered). In the event that none evaluate to true, then the default ar is triggered. Evaluation Criteria Full support for this pattern is evidened by an offering whih provides a onstrut whih enables the thread of ontrol to be direted to exatly one of several outgoing branhes. The deision as to whih branh is seleted is made at runtime on the basis of speifi onditions assoiated with eah of the branhes. Pattern WCP-5 (Simple Merge) Desription The onvergene of two or more branhes into a single subsequent branh. Eah enablement of an inoming branh results in the thread of ontrol being passed to the subsequent branh. Synonyms XOR-join, exlusive OR-join, asynhronous join, merge. Examples At the onlusion of either the bobat-exavation or the D9-exavation ativities, an estimate of the amount of earth moved is made for billing purposes. After the ash-payment or provide-redit ativities, initiate the produe-reeipt ativity. Motivation The Simple Merge pattern provides a means of merging two or more distint branhes without synhronizing them. As suh, this presents the opportunity to simplify a proess model by removing the need to expliitly repliate a sequene 13

14 of ativities that is ommon to two or more branhes. Instead, these branhes an be joined with a simple merge onstrut and the ommon set of ativities need only to be depited one in the proess model. Context Figure 5 illustrates the behaviour of this pattern. Immediately after either ativity A or B is ompleted, ativity C will be enabled. There is no onsideration of synhronization and it is a ontext ondition of this pattern that the plae at whih the merge ours (i.e. plae p1 in Figure 5) is safe and an never ontain more than one token. i1 i2 A B p1 C o1 Figure 5: Simple merge pattern Implementation Similar to patterns WCP2 WCP4 desribed above, this pattern an either be represented expliitly or impliitly. Staffware, SAP Workflow and UML 2.0 ADs provide speifi join onstruts for this purpose where as it is represented impliitly in WebSphere MQ, FLOWer, COSA and BPEL. BPMN and XPDL allow it to be represented in both ways. Issues One issue that an arise with the use of this pattern ours where it annot be ertain that the inoming plae to the merge (p1) is safe. Solutions In this situation, the ontext onditions for the pattern are not met and it annot be used, however there is an alternative pattern the Multi-Merge (WCP- 8) that is able to deal with the merging of branhes in potentially unsafe proess instanes. Evaluation Criteria Full support for this pattern in an offering is evidened by the ability to merge several distint branhes into one suh that eah thread of ontrol reeived on any inoming branh is immediately passed onto the outgoing branh Advaned Branhing and Synhronization Patterns This setion presents a series of patterns whih haraterise more omplex branhing and merging onepts whih arise in business proesses. Although relatively ommonplae in pratie, these patterns are often not diretly supported or even able to be represented in many ommerial offerings. The original ontrol-flow patterns identified four of these patterns: Multi-Choie, Synhronizing Merge, Multi-Merge and Disriminator. In this revision, the Multi-Choie and Multi-Merge have been retained in their previous form albeit with a more formal desription of their operational semantis. For the other patterns however, it has been reognized that there are a number of distint alternatives to the manner in whih they an operate. The original Synhronizing Merge now provides the basis for three patterns: the Strutured Synhronizing Merge (WCP-7), the Ayli Synhronizing Merge (WCP-37) and the General Synhronizing Merge (WCP-38). 14

15 In a similar vein, the original Disriminator pattern is divided into six distint patterns: the Strutured Disriminator (WCP-9), the Bloking Disriminator (WCP- 28), the Canelling Disriminator (WCP-29), the Strutured Partial Join (WCP-30), the Bloking Partial Join (WCP-31) and the Canelling Partial Join (WCP-32). One other addition has been the Generalized AND-Join (WCP-33) whih identifies a more flexible AND-join variant useful in onurrent proesses. Of these patterns, the original desriptions for the Synhronizing Merge and the Disriminator are superseded by their strutured definitions and are desribed in detail in this setion. The remaining new patterns are presented in Setion 4. Pattern WCP-6 (Multi-Choie) Desription The divergene of a branh into two or more branhes. When the inoming branh is enabled, the thread of ontrol is passed to one or more of the outgoing branhes based on the outome of distint logial expressions assoiated with eah of the branhes. Synonyms Conditional routing, seletion, OR-split, multiple hoie. Example Depending on the nature of the emergeny all, one or more of the despath-polie, despath-fire-engine and despath-ambulane ativities is immediately initiated. Motivation The Multi-Choie pattern provides the ability for the thread of exeution to be diverged into several onurrent threads on a seletive basis. The deision as to whether to start a given thread is made at run-time on the basis of workflow ontrol data and exeution information. This pattern is essentially an analogue of the Exlusive Choie pattern (WCP-4) in whih the onditions on the outgoing branhes are not required to be disjoint. Context The operation of the Multi-Choie pattern is illustrated in Figure 6. After ativity A has been triggered, the thread of ontrol an be passed to one or both of the following branhes depending on the evaluation of the onditions assoiated with eah of them. The main ontext riterion for this pattern is that the information required to alulate the logial onditions on eah of the outgoing branhes is available at runtime at the point at whih the Multi-Choie onstrut is reahed in the proess. if ond1 then 1 else empty p1 B o1 i1 A if ond2 then 1 else empty p2 C o2 Figure 6: Multi-hoie pattern Implementation As with other branhing and merging onstruts, the Multi-Choie pattern an either be represented impliitly or expliitly. WebSphere MQ aptures it impliitly via (non-disjoint) onditions on outgoing ars from a proess or blok onstrut, COSA and iplanet do muh the same via overlapping onditions on outgoing ars from ativities and outgoing routers respetively. Both COSA and iplanet 15

16 allow for relatively omplex expressions to be speified for these outgoing branhes and iplanet also allows for proedural elements to form part of these onditions. The modelling and business proess exeution languages examined tend to favour the use of expliit onstruts for representing the pattern: BPEL via onditional links within the <flow> onstrut, UML 2.0 ADs via the ForkNode with guards onditions on the outgoing ars and EPCs via textual notations to the OR-split onstrut. BPMN and XPDL provide three alternative representations inluding the use of an impliit split with onditions on the ars, an OR-split or a omplex gateway. Issues Two issues have been identified with the use of this pattern. First, as with the Exlusive Choie, an issue that also arises with the use of this pattern is ensuring that at least one outgoing branh is seleted from the various options available. If this is not the ase, then there is the potential for the workflow to deadlok. Seond, where an offering does not support the Multi-Choie onstrut diretly, the question arises as to whether there are any indiret means of ahieving the same behaviour. Solutions With respet to the first issue, the general solution to this issue is to enfore the use of a default outgoing ar from a Multi-Choie onstrut whih is enabled if none of the onditions on the other outgoing ars evaluate to true at runtime. For the seond issue, a work-around that an be used to support the pattern in most offerings is based on the use of an AND-split immediately followed by an (binary) XOR-split in eah subsequent branh. Another is the use of an XOR-split with an outgoing branh for eah possible ativity ombination, e.g. a Multi-Choie onstrut with outgoing branhes to ativities A and B would be modelled using an XOR-split with three outgoing branhes one to ativity A, another to ativity B and a third to an AND-split whih then triggered both ativities A and B. Further details on these transformations an be found in [vdathkb03]. Evaluation Criteria Full support for this pattern is evidened by the availability of a onstrut whih allows the thread of ontrol to be diverged into one or more branhes on the basis of onditions assoiated with eah of the branhes. Note that the work-around based on XOR-splits and AND-splits is not onsidered to onstitute support for this pattern. The first six patterns fous primarily on workflow struture and essentially orrespond to speifi onstruts that an be expeted to appear in a workflow language. Indeed the first five patterns are diretly supported in all of the offerings examined and the majority of them also support the sixth as well. In eah of these ases, the CPN model presented to illustrate the pattern orresponds very losely to the atual realisation of the pattern in individual offerings. The remainder of the patterns that we will desribe have a distint fous whih entres on their atual behaviour in a workflow ontext. As with the first six patterns, their operation is also desribed in terms of a CPN model, however the emphasis is on the atual semantis of the pattern being presented rather than the way in whih it is realised. As a onsequene there is not suh a lose strutural orrespondene between the CPN models for individual patterns and the form in whih they are realised in individual offerings and the diret repliation of the CPN model in a speifi workflow language does not neessarily demonstrate support for the pattern unless the language also repliates the semantis assoiated with the pattern. 16

17 Pattern WCP-7 (Strutured Synhronizing Merge) Desription The onvergene of two or more branhes (whih diverged earlier in the proess at a uniquely identifiable point) into a single subsequent branh. The thread of ontrol is passed to the subsequent branh when eah ative inoming branh has been enabled. Synonyms Synhronizing join, synhronizer. Example Depending on the type of emergeny, either or both of the despath-polie and despath-ambulane ativities are initiated simultaneously. When all emergeny vehiles arrive at the aident, the transfer-patient ativity ommenes. Motivation The Synhronizing Merge pattern provides a means of merging the branhes resulting from a speifi Multi-Choie or OR-split onstrut earlier in a workflow proess into a single branh. Impliit in this merging is the synhronization of all of the threads of exeution resulting from the preeding Multi-Choie. Context As already indiated, the Synhronizing Merge onstrut provides a means of merging the branhes from a preeding Multi-Choie onstrut and synhronizing the threads of ontrol flowing along eah of them. It is not neessary that all of the inoming branhes to the Synhronizing Merge are ative in order for the onstrut to be enabled, however all of the threads of ontrol assoiated with the inoming branhes must have reahed the Synhronizing Merge before it an fire. As suh there are four ontext onditions assoiated with the use of this pattern: 1. There must be a single Multi-Choie onstrut earlier in the proess model with whih the Synhronizing Merge is assoiated and it must merge all of the branhes emanating from the Multi-Choie. These branhes must either flow from the Multi-Choie to the Synhronizing Merge without any splits or joins or they must be strutured in form (i.e. balaned splits and joins) suh that it is not possible for the Synhronizing Merge to reeive multiple triggers on the same branh one the Multi-Choie has been enabled; 2. The Multi-Choie onstrut must not be re-enabled before the assoiated Synhronizing Merge onstrut has fired; 3. One the Multi-Choie has been enabled none of the ativities in the branhes leading to the Synhronizing Merge an be anelled before the merge has been triggered. The only exeption to this is that it is possible for all of the ativities leading up to the Synhronizing Merge to be anelled; and 4. The Synhronizing Merge must be able to resolve the deision as to when it should fire based on loal information available to it during the ourse of exeution. Critial to this deision is knowledge of how many branhes emanating from the Multi-Choie are ative and require synhronization. This is ruial in order to remove any potential for the viious irle paradox [Kin06] to arise where the determination of exatly when the merge an fire is based on non-loal semantis whih by neessity inlude a self-referening definition and make the firing deision inherently ambiguous. 17

18 Implementation Addressing the last of the ontext onditions without introduing non-loal semantis for the Synhronizing Merge an be ahieved in several ways inluding (1) struturing of the proess model following a Multi-Choie suh that the subsequent Synhronizing Merge will always reeive preisely one trigger on eah of its inoming branhes and no additional knowledge is required to make the deision as to when it should be enabled, (2) by providing the merge onstrut with knowledge of how many inoming branhes require synhronization and (3) by undertaking a thorough analysis of possible future exeution states to determine when the Synhronizing Merge an fire. The first of these implementation alternatives forms the basis for this pattern and is illustrated in Figure 7. It involves adding an alternate bypass path around eah branh from the multi-merge to the Synhronizing Merge whih is enabled in the event that the normal path is not hosen. The bypass path is merged with the normal path for eah branh prior to the Synhronizing Merge onstrut ensuring that it always gets a trigger on all inoming branhes and an hene be implemented as an AND-join onstrut. Figure 7: Strutured synhronizing merge pattern The seond implementation alternative forms the basis for the Ayli Synhronizing Merge (WCP-37) pattern. It an be failitated in several distint ways. One option [Rit99] is based on the immediate ommuniation from the preeding Multi- Choie to the Synhronizing Merge of how many branhes require synhronization. Another option (illustrated in Figure 8) involves the introdution of true/false tokens following a multi-merge indiating whether a given branh has been hosen or not. This pattern variant is disussed further on page 69. The third implementation alternative undertaking a omplete exeution analysis to determine when the Synhronizing Merge should be enabled forms the basis for the General Synhronizing Merge (WCP-38) pattern and is disussed on page 71. The Strutured Synhronizing Merge an be implemented in any workflow language whih supports the Multi-Choie onstrut and an satisfy the four ontext onditions listed above. It is diretly supported in WebSphere MQ, FLOWer, FileNet, BPMN, BPEL, XPDL and EPCs. Issues One onsideration that arises with the implementation of the OR-join is providing a form that is able to be used in loops and more omplex proess models whih are not strutured in form. The Strutured Synhronizing Merge annot be used in these ontexts. Solutions Both the Ayli Synhronizing Merge (WCP-37) and the General Syn- 18

19 Figure 8: Ayli synhronizing merge pattern hronizing Merge (WCP-38) are able to be used in unstrutured proess models. The latter is also able to be used in loops. The Ayli Synhronizing Merge tends to be more attrative from an implementation perspetive as it is less omputationally expensive than the General Synhronizing Merge. Evaluation Criteria Full support for this pattern in an offering is evidened by the availability of a onstrut whih demonstrates all of the ontext requirements for this pattern. Any offering whih allows the threads of ontrol in any subset of the input branhes to the merge to be anelled before it is triggered ahieves a rating of partial support. Pattern WCP-8 (Multi-Merge) Desription The onvergene of two or more branhes into a single subsequent branh. Eah enablement of an inoming branh results in the thread of ontrol being passed to the subsequent branh. Synonyms None. Example The lay foundations, order materials and book labourer ativities our in parallel as separate proess branhes. After eah of them ompletes the quality review ativity is run before that branh of the proess ompletes. Motivation The Multi-Merge pattern provides a means of merging distint branhes in a proess into a single branh. Although several exeution paths are merged, there is no synhronization of ontrol-flow and eah thread of ontrol whih is urrently ative in any of the preeding branhes will flow unimpeded into the merged branh. Context The operation of this pattern is illustrated in Figure 9. The main ondition assoiated with it is that multiple branhes preeding the Multi-Merge should result in an ative thread of ontrol in the branh after the Multi-Merge. In CPN terms, eah inoming token to plae p1 should be preserved. The distintion between this pattern and the Simple Merge is that it is possible for more than one inoming branh to be ative simultaneously and there is no neessity for plae p1 to be safe. 19

20 i1 i2 A B p1 C o1 Figure 9: Multi-merge pattern Implementation iplanet allows the Multi-Merge pattern to be implemented by speifying a trigger ondition for an ativity that allows it to be triggered when any of its inoming routers are triggered. BPMN and XPDL diretly implement it via the XOR-join onstrut and UML 2.0 ADs have an analogue in the form of the Merge- Node onstrut. EPCs also provide the XOR-join onstrut however it only expets one inoming thread of ontrol and ignores subsequent simultaneous triggers, hene it does not support the pattern. FLOWer is able to support multiple onurrent threads through dynami subplans however its highly strutured nature does not enable it to provide general support for the Multi-Merge pattern. Although COSA is based on a Petri Net foundation, it only supports safe models and hene is unable to fully support the pattern. For example, both A and B in Figure 9 will blok if there is a token in plae p1. Staffware attempts to maintain a safe proess model by oalesing subsequent triggerings of a step whilst it is ative into the same thread of ontrol hene it is also unable to support this pattern. This behaviour is quite problemati as it reates a rae ondition in whih all of the exeution sequenes ABC, BAC, ACBC and BCAB are possible. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support if it satisfies the ontext riterion for the pattern. Partial support is awarded to offerings that do not provide support for multiple branhes to merge simultaneously or do not provide for preservation of all threads of ontrol where this does our. Pattern WCP-9 (Strutured Disriminator) Desription The onvergene of two or more branhes into a single subsequent branh following a orresponding divergene earlier in the proess model. The thread of ontrol is passed to the subsequent branh when the first inoming branh has been enabled. Subsequent enablements of inoming branhes do not result in the thread of ontrol being passed on. The disriminator onstrut resets when all inoming branhes have been enabled. Synonym 1-out-of-M join. Example When handling a ardia arrest, the hek breathing and hek pulse ativities run in parallel. One the first of these has ompleted, the triage ativity is ommened. Completion of the other ativity is ignored and does not result in a seond instane of the triage ativity. 20

21 Motivation The Disriminator pattern provides a means of merging two or more distint branhes in a proess into a single subsequent branh suh that the first of them to omplete results in the subsequent branh being triggered, but ompletions of other inoming branhes thereafter have no effet on (and do not trigger) the subsequent branh. As suh, the Disriminator provides a mehanism for progressing the exeution of a proess one the first of a series of onurrent ativities has ompleted. Context The Disriminator pattern provides a means of merging two or more branhes in a workflow and progressing exeution of the workflow as rapidly as possible by enabling the subsequent (merged) branh as soon as a thread of ontrol is reeived on one of the inoming branhes. There are five ontext onditions assoiated with the use of this pattern: 1. The Disriminator is assoiated with preisely one Parallel Split earlier in the proess and eah of the outputs from the Parallel Split is an input to the Disriminator; 2. The branhes from the Parallel Split to the Disriminator are strutured in form and any splits and merge in the branhes are balaned; 3. Eah of the inoming branhes to the Disriminator must only be triggered one prior to it being reset; 4. The Disriminator resets (and an be re-enabled) one all of its inoming branhes have been enabled preisely one; and 5. One the Parallel Split has been enabled none of the ativities in the branhes leading to the Disriminator an be anelled before the join has been triggered. The only exeption to this is that it is possible for all of the ativities leading up to the Disriminator to be anelled. The operation of the Strutured Disriminator pattern is illustrated in Figure 10. The () notation indiates a simple untyped token. Initially there is suh a token in plae p2 (whih indiates that the Disriminator is ready to be enabled). The first token reeived at any of the inoming plaes i1 to im results in the Disriminator being enabled and an output token being produed in output plae o1. An untyped token is also produed in plae p3 indiating that the Disriminator has fired but not yet reset. Subsequent tokens reeived at eah of the other input plaes have no effet on the Disriminator (and do not result in any output tokens in plae o1). One one token has been reeived by eah input plae, the Disriminator resets and an be re-enabled one again. This ours when m-1 tokens have aumulated at plae p1 allowing the reset transition to be enabled. 4 There are two possible variants of this pattern that arise from relaxing some of the ontext onditions assoiated with the Strutured Disriminator pattern. Both of these improve the appliability of the Strutured Disriminator pattern whilst retaining its overall behaviour. First, the Bloking Disriminator (WCP-28) removes the requirement that eah inoming branh an only be enabled one between Disriminator resets. It allows 4 As a general omment, the notation x on an input ar to a CPN transition means that x instanes of token are required for the input ar to be enabled. 21

22 Figure 10: Strutured disriminator pattern eah inoming branh to be triggered multiple times although the onstrut only resets when one triggering has been reeived on eah input branh. It is illustrated in Figure 11 and disussed in further detail on page 54. Figure 11: Bloking disriminator pattern The seond alternative, the Canelling Disriminator (WCP-29), improves the effiieny of the pattern further by preventing any subsequent ativities in the remaining inoming branhes to the Disriminator from being enabled one the first branh has ompleted. Instead the remaining branhes are effetively put into a bypass mode where any remaining ativities are skipped hene expediting the reset of the onstrut. It is illustrated in Figure 12 and disussed in further detail on page 54. Implementation The Strutured Disriminator an be diretly implemented in iplanet by speifying a ustom trigger ondition for an ativity with multiple inoming routers whih only fires when the first router is enabled. BPMN and XPDL potentially support the pattern with a COMPLEX-Join onstrut however it is unlear how the InomingCondition for the join is speified. UML 2.0 ADs shares a similar problem with its JoinNode onstrut. SAP Workflow provides partial support for this pattern via the fork onstrut although any unfinished branhes are anelled one the first ompletes. Issues One issue that an arise with the Strutured Disriminator is that failure to reeive input on eah of the inoming branhes may result in the proess instane (and possibly other proess instanes) deadloking. Solutions The alternate versions of this pattern provide potential solutions to the is- 22

23 Figure 12: Canelling disriminator pattern sue. The Bloking Disriminator allows multiple exeution threads in a given proess instane to be handled by a single Disriminator (although a subsequent thread an only trigger the onstrut when inputs have been reeived on all inoming branhes and the Disriminator has reset). The Canelling Disriminator only requires the first thread of ontrol to be reeived in an inoming branh. One this has been reeived, the remaining branhes are effetively put into bypass mode and any remaining ativities in those branhes that have not already been ommened are skipped allowing the disriminator to be reset as soon as possible. Evaluation Criteria An offering ahieves full support if it satisfies the ontext riteria for the pattern. It rates as partial support if the Disriminator an reset without all ativities in inoming branhes having run to ompletion Strutural Patterns Strutural patterns haraterise design restritions that speifi workflow languages may have on the form of proess model that they are able to represent and how these models behave at runtime. There are two main areas that are of interest in strutural terms: (1) the form of yles or loops that an be represented within the proess model and (2) whether the termination of a proess instane must be expliitly aptured within the proess model. Looping is a ommon onstrut that arises during proess modelling in situations where individual ativities or groups of ativities must be repeated. Three distint forms of repetition an be identified: Arbitrary Cyles, Strutured Loops and Reursion. In lassial programming terms, these orrespond to the notions of (1) loops based on goto statements, whih tend to be somewhat unstrutured in format with repetition ahieved by simply moving the thread of exeution to a different part of the proess model, possibly repeatedly, (2) more strutured forms of repetition based on dediated programmati onstruts suh as while...do and repeat...until statements 5 and (3) repetition based on self-invoation. All of these strutural forms of repetition have distint haraterizations and they form the basis for the Arbitrary 5 The omparison of arbitrary loops to goto statements is a bit misleading. Note that in most graphial modelling languages, it is possible to onnet one node to another (independent of loops). This should not be onsidered as sloppy modelling, but rather as a feature! 23

24 Cyles (WCP-10), Strutured Loop (WCP-21) and Reursion (WCP-22) patterns. In the original set of patterns there was no onsideration of strutured loops or reursive iteration. Another strutural onsideration assoiated with individual proess modelling formalisms is whether a proess instane should simply end when there is no remaining work to be done or whether a speifi onstrut should exist in the proess model to denote the termination of a proess instane. The first of these alternatives is arguably a loser analogue to the way in whih many business proesses atually operate. It is desribed in the form of the Impliit Termination pattern (WCP-11). A seond pattern Expliit Termination pattern (WCP-43) has been introdued to reognize the fat that many workflow languages opt for a onrete form of denoting proess endpoints. Pattern WCP-10 (Arbitrary Cyles) Desription The ability to represent yles in a proess model that have more than one entry or exit point. Synonyms Unstrutured loop, iteration, yle. Example Figure 13 provides an illustration of the pattern with two entry points: p3 and p4. Figure 13: Arbitrary yles pattern Motivation The Arbitrary Cyles pattern provides a means of supporting repetition in a proess model in an unstrutured way without the need for speifi looping operators or restritions on the overall format of the proess model. Context There are no speifi ontext onditions assoiated with the inlusion of arbitrary yles in a proess model other than the obvious requirement that the proess model is able to support yles (i.e. it is not blok strutured). Implementation Staffware, COSA, iplanet, FileNet, BPMN, XPDL, UML 2.0 ADs and EPCs are all apable of apturing the arbitrary yles pattern. Blok strutured offerings suh as WebSphere MQ, FLOWer, SAP Workflow and BPEL are not able to represent arbitrary proess strutures. Issues The unstrutured ourrenes of the Arbitrary Cyles pattern are diffiult to apture in many types of workflow produts, partiularly those that implement strutured proess models. Solutions In some situations it is possible to transform proess models ontaining Arbitrary Cyles into strutured workflows, thus allowing them to be aptured in 24

25 strutured workflow produts. Further details on the types of proess models that an be transformed and the approahes to doing so an be found in [KtHB00] and [Kie03]. Evaluation Criteria An offering ahieves full support for the pattern if it is able to apture unstrutured yles that have more than one entry or exit point. Pattern WCP-11 (Impliit Termination) Desription A given proess (or sub-proess) instane should terminate when there are no remaining work items that are able to be done either now or at any time in the future. Synonyms None. Example N/A. Motivation The rationale for this pattern is that it represents the most realisti approah to determining when a proess instane an be designated as omplete. This is when there is no remaining work to be ompleted as part of it and it is not possible that work items will arise at some future time. Context There are no speifi ontext onsiderations assoiated with this pattern. Implementation Staffware, WebSphere MQ, FLOWer, FileNet, BPEL, BPMN, XPDL, UML 2.0 ADs and EPCs support this pattern. iplanet requires proesses to have a unique end node. COSA terminates a proess instane when a speifi type of end node is reahed. Issues Where an offering does not diretly support this pattern, the question arises as to whether it an implement a proess model whih has been developed based on the notion of impliit termination. Solutions For simple proess models, it may be possible to indiretly ahieve the same effet by replaing all of the end nodes for a proess with links to an OR-join whih then links to a single final node. However, it is less lear for more omplex proess models involving multiple instane ativities whether they are always able to be onverted to a model with a single terminating node. Potential solutions to this are disussed at length in [KtHvdA03]. It is worthwhile noting that some languages do not offer this onstrut on purpose: the Impliit Termination pattern makes it diffiult (or even impossible) to distinguish proper termination from deadlok! Additionally, workflows without expliit endpoints are more diffiult to use in ompositions. Evaluation Criteria An offering ahieves full support for this pattern if proess (or sub-proess) instanes terminate when there are no remaining ativities to be ompleted now or at any time in the future and the proess instane is not in deadlok Multiple Instane Patterns Multiple instane patterns desribe situations where there are multiple threads of exeution ative in a proess model whih relate to the same ativity (and hene share the same implementation definition). Multiple instanes an arise in three situations: 25

26 1. An ativity is able to initiate multiple instanes of itself when triggered (we denote this form of ativity a multiple instane ativity); 2. A given ativity is initiated multiple times as a onsequene of it reeiving several independent triggerings, e.g. as part of a loop or in a proess instane in whih there are several onurrent threads of exeution as might result from a Multi-Merge for example; and 3. Two or more ativities in a proess share the same implementation definition. This may be the same ativity definition in the ase of a multiple instane ativity or a ommon sub-proess definition in the ase of a blok ativity. Two (or more) of these ativities are triggered suh that their exeutions overlap (either partially or wholly). Although all of these situations potentially involve multiple onurrent instanes of an ativity or sub-proess, it is the first of them in whih we are most interested as they require the triggering and synhronization of multiple onurrent ativity instanes. This group of patterns fousses on the various ways in whih these events an our. Similar to the differentiation introdued in the Advaned Branhing and Synhronization Patterns to apture the distintion between the Disriminator and the Partial Join pattern variants, three new patterns have been introdued to reognize alternative operational semantis for multiple instanes. These are the the Stati Partial Join for Multiple Instanes (WCP-34), the Canelling Partial Join for Multiple Instanes (WCP-35) and the Dynami Partial Join for Multiple Instanes (WCP-36), eah of whih is disussed in detail in Setion 4. Pattern WCP-12 (Multiple Instanes without Synhronization) Desription Within a given proess instane, multiple instanes of an ativity an be reated. These instanes are independent of eah other and run onurrently. There is no requirement to synhronize them upon ompletion. Synonyms Multi threading without synhronization, spawn off faility. Example A list of traffi infringements is reeived by the Transport Department. For eah infringement on the list an Issue-Infringement-Notie ativity is reated. These ativities run to ompletion in parallel and do not trigger any subsequent ativities. They do not need to be synhronized at ompletion. Motivation This pattern provides a means of reating multiple instanes of a given ativity. It is partiularly suited to situations where the number of individual ativities required is known before the spawning ation ommenes, the ativities an exeute independently of eah other and no subsequent synhronization is required. Context There are two possible variants in the way in whih this pattern an operate. The first is illustrated by Figure 14 in whih the reate instane ativity runs within a loop and the new ativity instanes are reated sequentially. Plae p2 indiates the number of instanes required and is deremented as eah new instane is reated. New instanes an only be reated when the token in p2 > 0 the guard on the reate instane ativity ensures this is the ase. When all instanes have 26

27 Figure 14: Multiple instanes without synhronization pattern - 1 been reated, the next ativity (B) an be enabled again the guard on ativity B ensures this is also the ase. In Figure 15, the ativity instanes are all reated simultaneously. In both variants, it is a requirement that the number of new instanes required is known before the reation ativity ommenes. It is also assumed that ativity instanes an be reated that run independently (and in addition to the thread of ontrol whih started them) and that they do not require synhronizing as part of this onstrut. Figure 15: Multiple instanes without synhronization pattern - 2 There are two ontext onditions assoiated with this pattern: (1) eah of the multiple instane ativities that are reated must exeute within the ontext of the proess instane from whih they were started (i.e. they must share the same ase id and have aess to the same data elements) and (2) eah of the multiple instane ativities must exeute independently from and without referene to the ativity that started them. Implementation Most offerings COSA, iplanet, BPEL, BPMN, XPDL and UML 2.0 ADs support the sequential variant of this pattern (as illustrated in Figure 14) with the ativity reation ourring within a loop. SAP Workflow also do so, but with the limitation that a new proess instane is started for eah ativity instane invoked. BPMN also supports the seond variant, as do Staffware and FLOWer, and they provide the ability to reate the required number of ativity instanes simultaneously. Issues Where an offering provides support for this pattern, one issue that an potentially arise is how the various threads of exeution might be synhronized at some future point in the proess. 27

28 Solutions This is potentially problemati as it is likely that the individual threads of exeution may ultimately flow down the same path and most offerings do not provide a onstrut for this form of synhronization. In reognition of this need (and the fat that some languages do provide suh a faility), the Thread Merge (WCP-41) and Thread Split (WCP-42) patterns have been introdued. Evaluation Criteria An offering ahieves full support if it satisfies the ontext requirements for the pattern. Where the newly reated ativity instanes run in a distint proess instane to the ativity that started them or they annot aess the same data elements as the parent ativity, the offering ahieves only partial support. Pattern WCP-13 (Multiple Instanes with a priori Design-Time Knowledge) Desription Within a given proess instane, multiple instanes of an ativity an be reated. The required number of instanes is known at design time. These instanes are independent of eah other and run onurrently. It is neessary to synhronize the ativity instanes at ompletion before any subsequent ativities an be triggered. Synonyms None. Example The Annual Report must be signed by all six of the Diretors before it an be issued. Motivation This pattern provides the basis for onurrent exeution of a nominated ativity a predefined number of times. It also ensures that all ativity instanes are omplete before subsequent ativities are initiated. Context Similar to WCP-12, the Multiple Instanes without Synhronization pattern, there are both sequential and simultaneous variants of this pattern illustrated in Figures 16 and 17 respetively. In both figures, ativity C is the one that exeutes multiple times. Figure 16: Multiple instanes with a priori design-time knowledge - 1 Figure 17: Multiple instanes with a priori design-time knowledge

29 There are three ontext onditions assoiated with this pattern: (1) the number of ativity instanes required must be speified in the design-time proess model, (2) it must be possible for the ativity instanes to exeute onurrently (although it is not neessarily required that they do all exeute in parallel) and (3) all ativity instanes must omplete before subsequent ativities in the proess an be triggered. Implementation In order to implement this pattern, an offering must provide a speifi onstrut in the proess model that is able to denote the speifi number of onurrent ativity instanes that are required. Staffware, FLOWer, SAP Workflow and UML 2.0 ADs support the simultaneous variant of the pattern through the use of dynami subproedure, dynami subplan, multi-line ontainer element and ExpansionRegion onstruts respetively. BPMN and XPDL support both options via the multi-instane loop ativity onstrut with the MI Ordering attribute supporting both sequential and parallel values depending on whether the ativities should be started one-by-one or all together. Unlike other BPEL offerings whih do not support this pattern, Orale BPEL provides a <flown> onstrut that enables the reation of multiple onurrent instanes of an ativity. Issues Many offerings provide a work-around for this pattern by embedding some form of ativity invoation within a loop. These implementation approahes have two signifiant problems assoiated with them: (1) the ativity invoations our at disrete time intervals and it is possible for the individual ativity instanes to have potentially distint states at the time they are invoked (i.e. the ativities do not need to be exeuted in sequene and an be handled onurrently) and (2) there is no onsideration of the means by whih the distint ativity instanes will be synhronized. These issues, together with the neessity for the designer to effetively raft the pattern themselves (rather than having it provided by the offering) rule out this form of implementation from being onsidered as satisfying the requirements for full support. Solutions One possibility that exists where this funtionality is not provided by an offering but an analogous form of operation is required is to simply repliate the ativity in the proess-model. Alternatively a solution based on iteration an be utilized. Evaluation Criteria An offering ahieves full support if it provides a onstrut that satisfies the ontext riteria for the pattern. Although work-arounds are possible whih ahieve the same behaviour through the use of various onstruts within an offering suh as ativity repliation or loops, they have a number of shortomings and are not onsidered to onstitute support for the pattern. Pattern WCP-14 (Multiple Instanes with a priori Run-Time Knowledge) Desription Within a given proess instane, multiple instanes of an ativity an be reated. The required number of instanes may depend on a number of runtime fators, inluding state data, resoure availability and inter-proess ommuniations, but is known before the ativity instanes must be reated. One initiated, these instanes are independent of eah other and run onurrently. It is neessary to synhronize the instanes at ompletion before any subsequent ativities an be triggered. Synonyms None. 29

30 Examples When diagnosing an engine fault, the hek-sensor ativity an run multiple times depending on the the number of error messages reeived. Only when all messages have been proessed, an the identify-fault ativity be initiated; In the review proess for a journal paper submitted to a journal, the review paper ativity is exeuted several times depending on the ontent of the paper, the availability of referees and the redentials of the authors. The review proess an only ontinue when all reviews have been returned; When dispensing a presription, the weigh ompound ativity must be ompleted for eah ingredient before the preparation an be ompounded and dispensed. Motivation The Multiple Instanes with a priori Run-Time Knowledge pattern provides a means of exeuting multiple instanes of a given ativity in a synhronized manner with the determination of exatly how many instanes will be reated being deferred to the latest possible time before the first of the ativities is started. Context As with other multiple instane patterns, there are two variants of this pattern depending on whether the instanes are reated sequentially or simultaneously as illustrated in Figures 18 and 19. In both ases, the number of instanes of ativity C to be exeuted (indiated in these diagrams by the variable numinst) is ommuniated at the same time that the thread of ontrol is passed for the proess instane.! Figure 18: Multiple instanes with a priori run-time knowledge pattern - 1 Figure 19: Multiple instanes with a priori run-time knowledge pattern - 2 There are three ontext onditions assoiated with this pattern: (1) the number of ativity instanes required must be known at run-time prior to the invoation of the multiple instane ativity, (2) it must be possible for the ativity instanes to 30

31 exeute onurrently (although it is not neessarily required that they do all exeute in parallel) and (3) all ativity instanes must omplete before subsequent ativities in the proess an be triggered. Implementation Staffware, FLOWer and UML 2.0 ADs support the simultaneous variant of the pattern through the use of dynami subplan and ExpansionRegion onstruts respetively. BPMN and XPDL support both options via the multi-instane loop ativity onstrut. In the ase of FLOWer, BPMN and XPDL, the atual number of instanes required is indiated through a variable passed to the onstrut at runtime. For UML 2.0 ADs, the ExpansionRegion onstrut supports multiple instantiations of an ativity based on the number of instanes of a defined data element(s) passed at run-time. Orale BPEL supports the pattern via its (unique) <flown> onstrut. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support if it provides a onstrut that satisfies the ontext riteria for the pattern. Pattern WCP-15 (Multiple instanes without a priori run-time knowledge) Desription Within a given proess instane, multiple instanes of an ativity an be reated. The required number of instanes may depend on a number of runtime fators, inluding state data, resoure availability and inter-proess ommuniations and is not known until the final instane has ompleted. One initiated, these instanes are independent of eah other and run onurrently. At any time, whilst instanes are running, it is possible for additional instanes to be initiated. It is neessary to synhronize the instanes at ompletion before any subsequent ativities an be triggered. Synonyms None. Example The despath of an oil rig from fatory to site involves numerous transport shipment ativities. These our onurrently and although suffiient ativities are started to over initial estimates of the required transport volumes, it is always possible for additional ativities to be initiated if there is a shortfall in transportation requirements. One the whole oil rig has been transported, and all transport shipment ativities are omplete, the next ativity (assemble rig) an ommene. Motivation This pattern is an extension to WCP-14 Multiple Instanes with a priori Run-Time Knowledge whih defers the need to determine how many onurrent instanes of the ativity are required until the last possible moment either when the final join onstrut fires or the last of the exeuting instanes ompletes. It offers more flexibility in that additional instanes an be reated on-the-fly without any neessary hange to the proess model or the synhronization onditions for the ativity. Context Similar to other multiple instane patterns, there are two variants to this pattern depending on whether the initial round of instanes are started sequentially 31

32 or simultaneously. These senarios are depited in Figures 20 and 21. It should be noted that it is possible to add additional instanes of ativity C in both of these implementations via the add instane transition at any time up until all instanes have ompleted and the join assoiated with them has fired triggering the subsequent ativity (B). #! " Figure 20: Multiple instanes without a priori run-time knowledge pattern - 1 Figure 21: Multiple instanes without a priori run-time knowledge pattern - 2 There are three ontext onditions assoiated with this pattern: (1) the number of ativity instanes required must be known at run-time prior to the ompletion of the multiple instane ativity (note that the final number of instanes does not need to be known when initializing the MI ativity), (2) it must be possible for the ativity instanes to exeute onurrently (although it is not neessarily required that they do all exeute in parallel) and (3) all ativity instanes must omplete before subsequent ativities in the proess an be triggered. Implementation Only one of the offerings examined FLOWer provides diret support for this pattern. It does this through the dynami subplan onstrut. 32

33 Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support if it provides a onstrut that satisfies the ontext riteria for the pattern State-based Patterns State-based patterns reflet situations for whih solutions are most easily aomplished in proess languages that support the notion of state. In this ontext, we onsider the state of a proess instane to inlude the broad olletion of data assoiated with urrent exeution inluding the status of various ativities as well as proess-relevant working data suh as ativity and ase data elements. The original patterns inlude three patterns in whih the urrent state is the main determinant in the ourse of ation that will be taken from a ontrol-flow perspetive. These are: Deferred Choie (WCP-16), where the deision about whih branh to take is based on interation with the operating environment, Interleaved Parallel Routing (WCP-17), where two or more sequenes of ativities are undertaken on an interleaved basis suh that only one ativity instane is exeuting at any given time and Milestone (WCP-18), where the enabling of a given ativity only ours where the proess is in a speifi state. In reognition of further state-based modelling senarios, four new patterns have also been identified and are disussed in detail in Setion 4. These are: Critial Setion (WCP-39), whih provides the ability to prevent onurrent exeution of speifi parts of a proess, Interleaved Routing (WCP-40), whih denotes situations where a group of ativities an be exeuted sequentially in any order, and Thread Merge (WCP-41) and Thread Split (WCP-42) whih provide for oalesene and divergene of distint threads of ontrol along a single branh. Pattern WCP-16 (Deferred Choie) Desription A point in a workflow proess where one of several branhes is hosen based on interation with the operating environment. Prior to the deision, all branhes present possible future ourses of exeution. The deision is made by initiating the first ativity in one of the branhes i.e. there is no expliit hoie but rather a rae between different branhes. After the deision is made, exeution alternatives in branhes other than the one seleted are withdrawn. Synonyms External hoie, impliit hoie, deferred XOR-split. Examples At the ommenement of the Resolve omplaint proess, there is a deferred hoie between the Initial ustomer ontat ativity and the Esalate to manager ativity. The Initial ustomer ontat is initiated when it is started by a ustomer servies team member. The Esalate to manager ativity ommenes 48 hours after the proess instane ommenes. One one of these ativities is initiated, the other is withdrawn. One a ustomer requests an airbag shipment, it is either piked up by the postman or a ourier driver depending on whih is available to visit the ustomer site first. Motivation The Deferred Choie pattern provides the ability to defer the moment of hoie in a proess, i.e. the moment as to whih one of several possible ourses of 33

34 ation should be hosen is delayed to the last possible time and is based on fators external to the proess instane (e.g. inoming messages, environment data, resoure availability, timeouts et.). Up until the point at whih the deision is made, any of the alternatives presented represent viable ourses of future ation. Context The operation of this pattern is illustrated in Figure 22. The moment of hoie is signified by plae p1. Either ativity B or C represent valid ourses of ation but only one of them an be hosen. It is a ontext ondition of this pattern that one one of the possible alternative ourses of ation is hosen, any possible ations assoiated with other branhes are immediately withdrawn. B o1 i1 A p1 C o2 Figure 22: Deferred hoie onstrut Implementation This is a omplex pattern and it is interesting to see that only those offerings that an laim some sort of token-based underpinning are able to suessfully support it. COSA is based on a Petri-Net foundation and an implement the pattern in muh the same way as it is presented in Figure 22. BPEL provides support for it via the <pik> onstrut, BPMN through the event-based gateway onstrut, XPDL using the XOREVENT-split onstrut and UML 2.0 ADs using a ForkNode followed by a set of AeptSignal ations, one preeding eah ation in the hoie. In the ase of the latter three offerings, the atual hoie is made based on message-based event interations. FLOWer does not diretly provide a notion of state but it provides several ways of supporting this pattern through the use of user and system deisions on plan types and also by using ar guards that evaluate to NIL in onjuntion with data elements to make the deision as to whih branh is seleted. FileNet provides partial support for the pattern as it only allows for withdrawal of timer-based branhes not of all branhes other than the one seleted for exeution. Issue None identified. Solution N/A. Evaluation Criteria An offering ahieves full support if it provides a onstrut that satisfies the ontext riteria for the pattern. If there are any restritions on whih branhes an be seleted or withdrawn, then the offering is rated as having partial support. Pattern WCP-17 (Interleaved Parallel Routing) Desription A set of ativities has a partial ordering defining the requirements with respet to the order in whih they must be exeuted. Eah ativity in the set must be exeuted one and they an be ompleted in any order that aords with the partial 34

35 order. However, as an additional requirement, no two ativities an be exeuted at the same time (i.e. no two ativities an be ative for the same proess instane at the same time). Synonyms None. Example When despathing an order, the pik goods, pak goods and prepare invoie ativities must be ompleted. The pik goods ativity must be done before the pak goods ativity. The prepare invoie ativity an our at any time. Only one of these ativities an be done at any time for a given order. Motivation The Interleaved Parallel Routing pattern offers the possibility of relaxing the strit ordering that a proess usually imposes over a set of ativities. Note that Interleaved Parallel Routing is related to mutual exlusion, i.e. a semaphore makes sure that ativities are not exeuted at the same time without enforing a partiular order. Context Figure 23 provides an example of interleaved parallel routing. Plae p3 enfores that ativities B, C and D be exeuted in some order. In this example, the permissible ativity orderings are: ABDCE, ABCDE and ACBDE. Figure 23: Interleaved parallel routing pattern There are three ontext onditions assoiated with this pattern: (1) for a given proess instane, no two ativities from the set of ativities subjet to interleaved parallel routing may be exeuted at the same time, (2) there must be some (partial) ordering defined between the ativities and (3) ativities must be initiated and ompleted on a sequential basis, it is not possible to suspend one ativity during its exeution to work on another. If the seond ondition is not satisfied, then the senario is atually one of Interleaved Routing and is desribed by pattern WCP-40 on page 73. Implementation In order to effetively implement this pattern, an offering must have an integrated notion of state that is available during exeution of the ontrolflow perspetive. COSA has this from its Petri-Net foundation and is able to diretly support the pattern. Other offerings lak this apability and hene are not able to diretly support this pattern. BPEL (although surprisingly not Orale BPEL) an indiretly ahieve similar effets using serializable sopes within the ontext of a <pik> onstrut although only ativities in the same blok an be inluded within it. It also has the shortoming that every permissible exeution sequene of interleaved ativities must be expliitly modelled. FLOWer has a distint foundation to that inherent in other workflow produts in whih all ativities in a ase are always alloated to the 35

36 same resoure for ompletion hene interleaving of ativity exeution is guaranteed, however it is also possible for a resoure to suspend an ativity during exeution to work on another hene the ontext onditions for this pattern are not fully satisfied. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support if it it is able to satisfy the ontext riteria for the pattern. It ahieves a partial support rating if there are any limitations on the set of ativities that be interleaved or if ativities an be suspended during exeution. Pattern WCP-18 (Milestone) Desription An ativity is only enabled when the proess instane (of whih it is part) is in a speifi state (typially in a parallel branh). The state is assumed to be a speifi exeution point (also known as a milestone) in the proess model. When this exeution point is reahed the nominated ativity an be enabled. If the proess instane has progressed beyond this state, then the ativity annot be enabled now or at any future time (i.e. the deadline has expired). Note that the exeution does not influene the state itself, i.e. unlike normal ontrol-flow dependenies it is a test rather than a trigger. Synonyms Test ar, deadline, state ondition, withdraw message. Example Most budget airlines allow the routing of a booking to be hanged providing the tiket has not been issued; The enrol student ativity an only exeute whilst new enrolments are being aepted. This is after the open enrolment ativity has ompleted and before the lose off enrolment ativity ommenes. Motivation The Milestone pattern provides a mehanism for supporting the onditional exeution of an ativity or sub-proess (possibly on a repeated basis) where the proess instane is in a given state. The notion of state is generally taken to mean that ontrol-flow has reahed a nominated point in the exeution of the proess instane (i.e. a milestone). As suh, it provides a means of synhronizing two distint branhes of a proess instane, suh that one branh annot proeed unless the other branh has reahed a speified state. Context The nominal form of the milestone pattern is illustrated by Figure 24. Ativity A annot be enabled when it reeives the thread of ontrol unless the other branh is in state p1 (i.e. there is a token in plae p1). This situation presumes that the proess instane is either in state p1 or will be at some future time. It is important to note that the repeated exeution of A does not influene the top parallel branh. Note that A an only our if there is a token in p1. Hene a milestone may have a potential deadlok. There are at least two ways of avoiding this. First of all, it is possible to define an alternative ativity for A whih takes a token from the input plae(s) of A without taking a token from p1. One an think of this ativity as a time-out or a skip ativity. This way the proess does not get stuk if C ours before A. Moreover, it is possible to delay the exeution of C until the lower branh finishes. 36

37 i1 B p1 C o1 in A on Figure 24: Milestone pattern Note that in both ases A may be optional (i.e. not exeute at all) or an our multiple times beause the token in p1 is only tested and not removed. Implementation The neessity for an inherent notion of state within the proess model means that the Milestone pattern is not widely supported. Of the offerings examined, only COSA is able to diretly represent it. FLOWer offers indiret support for the pattern through the introdution of a data element for eah situation in whih a milestone is required. This data element an be updated with a value when the milestone is reahed and the branh whih must test for the Milestone ahievement an do so using the FLOWer milestone onstrut. Note that this is only possible in a data-driven system like FLOWer. It is not possible to use variables this way in a lassial ontrol-flow driven system beause a busy wait would be needed to onstantly inspet the value of this variable. (Note that FLOWer only re-evaluates the state after eah hange with respet to data elements). Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support if it provides a onstrut that allows the exeution of a given ativity to be dependent on the proess instane being in some predefined state Canellation Patterns Several of the patterns in previous setions (e.g. (WCP-6) Strutured Synhronizing Merge and (WCP-9) Strutured Disriminator) have variants that utilize the onept of ativity anellation where enabled or ative ativity instanes are withdrawn. Various forms of exeption handling in proesses are also based on anellation onepts. This setion presents two anellation patterns Canel Ativity (WCP-19) and Canel Case (WCP-20). Three new anellation patterns have also been identified Canel Region (WCP- 25), Canel Multiple Instane Ativity (WCP-26) and Complete Multiple Instane Ativity (WCP-27). These are disussed in Setion 4. Pattern WCP-19 (Canel Ativity) Desription An enabled ativity is withdrawn prior to it ommening exeution. If the ativity has started, it is disabled and, where possible, the urrently running instane is halted and removed. 37

38 Synonym Withdraw ativity. Examples The assess damage ativity is undertaken by two insurane assessors. One the first assessor has ompleted the ativity, the seond is anelled; The purhaser an anel their building inspetion ativity at any time before it ommenes. Motivation The Canel Ativity pattern provides the ability to withdraw an ativity whih has been enabled. This ensures that it will not ommene exeution. Context The general interpretation of the Canel Ativity pattern is illustrated by Figure 25. The trigger whih has enabled ativity B is removed, preventing the ativity from proeeding. Figure 25: Canel ativity pattern - 1 There is also a seond variant of the pattern where the ativity has already ommened exeution but has not yet ompleted. This senario is shown in Figure 26, where an ativity whih has been enabled or is urrently exeuting an be anelled. It is important to note for both variants that anellation is not guaranteed and it is possible that the ativity will ontinue exeuting to ompletion. In effet, the anellation vs ontinuation deision operates as a deferred hoie with a rae ondition being set up between the anellation event and the muh slower ativity of resoures responding to work assignment. For all pratial purposes, it is muh more likely that the anellation will be effeted rather than the ativity being ontinued. Figure 26: Canel ativity pattern - 2 Where guaranteed anellation is required, the implementation of ativities should take the form illustrated in Figure 27. The deision to anel ativity B an only be made after it has been enabled and prior to it ompleting. One this deision is made, it is not possible for the ativity to progress any further. For obvious reasons, it is not possible to anel an ativity whih has not been enabled (i.e. there is no memory assoiated with the ation of anelling an ativity in the way that there is for triggers) nor is it possible to anel an ativity whih has already ompleted exeution. 38

39 ativity B i1 A p1 startb P2 endb p3 C o1 e e e e e enabled e E anelb E e terminate Figure 27: Canel ativity pattern with guaranteed termination Implementation The majority of the offerings examined provide support for this pattern within their proess models. Most support the first variant as illustrated in Figure 25: Staffware does so with the withdraw onstrut, COSA allows tokens to be withdrawn from the plaes before ativities, iplanet provides the AbortAtivity method, FileNet provides the <Terminate Branh> onstrut and SAP Workflow provides the proess ontrol step for this purpose although it has limited usage. BPEL supports the seond variant via fault ompensation handlers attahed to ativities, as do BPMN and XPDL using error type triggers attahed to the boundary of the ativity to be anelled. UML 2.0 ADs provide a similar apability by plaing the ativity to be anelled in an interruptible region triggered by a signal or another ativity. FLOWer does not diretly support the pattern although ativities an be skipped and redone. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support for the pattern if it provides the ability to denote ativity anellation within a proess model. If there are any side-effets assoiated with the anellation (e.g. fored ompletion of other ativities, the anelled ativity being marked as omplete), then the offering is rated as having partial support. Pattern WCP-20 (Canel Case) Desription A omplete proess instane is removed. This inludes urrently exeuting ativities, those whih may exeute at some future time and all sub-proesses. The proess instane is reorded as having ompleted unsuessfully. Synonym Withdraw ase. Examples During an insurane laim proess, it is disovered that the poliy has expired and, as a onsequene, all ativities assoiated with the partiular proess instane are anelled; During a mortgage appliation, the purhaser deides not to ontinue with a house purhase and withdraws the appliation. Motivation This pattern provides a means of halting a speified proess instane and withdrawing any ativities assoiated with it. 39

40 Context Canellation of an entire ase involves the disabling of all urrently enabled ativities. Figure 28 illustrates one sheme for ahieving this. It is based on the identifiation of all possible sets of states that the proess may exhibit for a proess instane. Eah ombination has a transition assoiated with it (illustrated by C1, C2.. et) that disables all enabled ativities. Where anellation of a ase is enabled, it is assumed that preisely one of the anelling transitions (i.e. C1, C2...) will fire anelling all neessary enabled ativities. To ahieve this, it is neessary that none of the anelling transitions represent a state that is a superset of another possible state, otherwise tokens may be left behind after the anellation. anel Trigger C1 C2 C3 C4 start end Figure 28: Canel ase pattern - 1 An alternative sheme is presented in Figure 29, where every state has a set of anellation transitions assoiated with it (illustrated by C1, C2.. et.). When the anellation is initiated, these transitions are enabled for a very short time interval (in essene the differene between time t and t + epsilon where epsilon is a time interval approahing zero), thus effeting an instantaneous anellation for a given state that avoids the potential deadloks that might arise with the approah shown in Figure 28. A more general approah to anellation is illustrated in Figure 30. This may be used to anel individual ativities, regions or even whole ases. It is premised on the reation of an alternative bypass ativity for eah ativity in a proess that may need to be anelled. When a anellation is initiated, the ase ontinues proessing but the bypass ativities are exeuted rather than the normal ativities, so in effet no further work is atually ahieved on the ase. There is an important ontext ondition assoiated with this pattern: anellation of a exeuting ase must be viewed as unsuessful ompletion of the ase. This means that even though the ase was terminated in an orderly manner, perhaps even with tokens reahing its final end state, this should not be interpreted in any way as a suessful outome. For example, where a log is kept of events ourring during proess exeution, the ase should be reorded as inomplete or anelled. Implementation There is reasonable support for this pattern amongst the offerings examined. SAP Workflow provides the proess ontrol step for this purpose, FileNet provides the <Terminate Proess> onstrut, BPEL provide the <terminate> onstrut, BPMN and XPDL provide support by inluding the entire proess in a trans- 40

41 anel Trigger t t@+epsilon p1 t begin anel end anel t p2 t t t t t C1 C2 C3 C4 start end Figure 29: Canel ase pattern - 2 anel region t Trigger ative anel normal end end start start region t bypass end t t SKIP t SKIP Figure 30: Canel region implementation ation with an assoiated end event that allows all exeuting ativities in a proess instane to be terminated. Similarly UML 2.0 ADs ahieve the same effet using the InterruptibleAtivityRegion onstrut. FLOWer provide partial support for the pattern through its ability to skip or redo entire ases. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support for the pattern if it provides the ability to denote the anellation of an entire proess instane in a proess model and satisfies the ontext requirements for the pattern. If there are any side-effets assoiated with the anellation (e.g. fored ompletion of other ativities, the proess instane being marked as omplete), then the offering is rated as having partial support. 41

42 4 New Control-Flow Patterns Review of the patterns assoiated with the ontrol-flow perspetive over the past few years has led to the reognition that there are a number of distint modelling onstruts that an be identified during proess modelling that are not adequately aptured by the original set of twenty patterns. In this setion, we present twenty three new ontrol-flow patterns that augment the existing range of patterns desribed in the previous setion and elsewhere [vdabthk00, vdathkb03]. In an attempt to desribe the operational harateristis of eah pattern more rigourously, we also present a formal model in Coloured Petri-Net (CPN) format for eah of them. In fat the expliit modelling of the original patterns using CPN Tools (f. Setion 3), helped identify a number of new patterns as well as delineating situations where some of the original patterns turned out to be olletions of patterns. When disussing the Arbitrary Cyles pattern (WCP-10), we indiated that some people refer to suh yles as goto s. We disagree with this beause if arbitrary forward graphial onnetions are allowed, then it does not make sense to forbid bakward graphial onnetions on the basis that they onstitute sloppy modeling. Nevertheless, it may be useful to have speial onstruts for strutured loops as is illustrated by the next pattern. Pattern WCP-21 (Strutured Loop) Desription The ability to exeute an ativity or sub-proess repeatedly. The loop has either a pre-test or post-test ondition assoiated with it that is either evaluated at the beginning or end of the loop to determine whether it should ontinue. The looping struture has a single entry and exit point. Examples While the mahine still has fuel remaining, ontinue with the prodution proess. Only shedule flights if there is no storm ativity. Continue proessing photographs from the film until all of them have been printed. Repeat the selet player ativity until the entire team has been seleted. Motivation There are two general forms of this pattern the while loop whih equates to the lassi while...do pre-test loop onstrut used in programming languages and the repeat loop whih equates to the repeat...until post-test loop onstrut. The while loop allows for the repeated sequential exeution of a speified ativity or a sub-proess zero or more times providing a nominated ondition evaluates to true. The pre-test ondition is evaluated before the first iteration of the loop and is re-evaluated before eah subsequent iteration. One the pre-test ondition evaluates to false, the thread of ontrol passes to the ativity immediately following the loop. The while loop struture ensures that eah of the ativities embodied within it are exeuted the same number of times. The repeat loop allows for the exeution of an ativity or sub-proess one or more times, ontinuing with exeution until a nominated ondition evaluates to true. The post-test ondition is evaluated after the first iteration of the loop and is re-evaluated after eah subsequent iteration. One the post-test ondition evaluates to true, the thread of ontrol passes to the ativity immediately following the loop. The repeat 42

43 loop struture ensures that eah of the ativities embodied within it are exeuted the same number of times. Context As indiated above, there are two variants of this pattern: the while loop illustrated in Figure 31 and the repeat loop shown in Figure 32. In both ases, ativity B is exeuted repeatedly. Figure 31: Strutured loop pattern while variant Figure 32: Strutured loop pattern repeat variant Implementation The main onsideration in supporting the Strutured Loop pattern is the availability of a onstrut within a modelling language to denote the repeated exeution of an ativity or sub-proess based on a speified ondition. The evaluation of the ondition to determine whether to ontinue (or ease) exeution an our either before or after the ativity (or sub-proess) has been initiated. WebSphere MQ provides support for post-tested loops through the use of exit onditions on blok or proess onstruts. Similarly, FLOWer provides the sequential plan onstrut that allows a sequene of ativities to be repeated sequentially until a nominated ondition is satisfied. iplanet also supports post-tested loops through onditions on outgoing routers from an ativity that loop bak to the beginning of the same ativity. BPEL diretly supports pre-tested loops via the <while> onstrut. BPMN and XPDL allow both pre-tested and post-tested loops to be aptured through the loop ativity onstrut. Similarly UML 2.0 ADs provide the LoopNode onstrut whih has similar apabilities. SAP provides two loop onstruts orresponding to the while loop and the repeat loop. (In fat the SAP loop onstrut is more general merging both the while and repeat loop into a single onstrut). Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support for the pattern if it has a onstrut that denotes an ativity or sub-proess should be repeated whilst a speified ondition remains true or until a speified ondition beomes true. Another new pattern related to loops is the Reursion pattern. 43

44 Pattern WCP-22 (Reursion) Desription The ability of an ativity to invoke itself during its exeution or an anestor in terms of the overall deomposition struture with whih it is assoiated. Example An instane of the resolve-defet ativity is initiated for eah mehanial problem that is identified in the prodution plant. During the exeution of the resolve-defet ativity, if a mehanial fault is identified during investigations that is not related to the urrent defet, another instane of the resolve-defet is started. These subproesses an also initiate further resolve-defet ativities should they be neessary. The parent resolve-defet ativity annot omplete until all hild resolve-defet ativities that it initiated have been satisfatorily ompleted. Motivation For some types of ativity, partiularly those that may involve unplanned repetition of an ativity or sub-proess, simpler and more suint solutions an be provided through the use of reursion rather than iteration. In order to harness reursive forms of problem solving within the ontext of a workflow, a means of desribing an ativity exeution in terms of itself (i.e. the ability for an ativity to invoke another instane of itself whilst exeuting) are required. Context Figure 33 illustrates the format of the reursion pattern in Petri-Net terms. Ativity A an be deomposed into the proess model with input i1 and output o1. It is important to note that this proess also ontains the ativity A hene the ativity is desribed in terms of itself. A In i1 B p1 A p2 C o1 Out D Figure 33: Reursion pattern. It is a ontext ondition of this pattern that an offering provides the ability within a proess model to denote the synhronous invoation of an ativity or sub-proess within the same proess model. In order to ensure that use of reursion does not lead to infinite self-referening deompositions, there is also a seond ontext ondition: there must be at least one path through the proess deomposition whih is not self-referening and will terminate normally. In Figure 33, this is illustrated by the exeution sequene BDC a token from input i1 to output o1. This orresponds to the terminating ondition in mathematial desriptions of reursion and ensures that where reursion is used in a proess that the overall proess will eventually omplete normally when exeuted. Implementation In order to implement reursion within the ontext of a workflow, some means of invoking a distint instane of an ativity is required from within a given ativity implementation. Staffware, WebSphere MQ, COSA, iplanet and SAP 44

45 Workflow all provide the ability for an ativity to invoke an instane of itself whilst exeuting. Figure 34: Reursion implementation. The atual mehanis of implementing reursion for a proess suh as that depited in Figure 33 are shown in Figure 34. The exeution of the reursive ativity A is denoted by the transitions starta and enda. When an instane of ativity A is initiated in a ase, any further exeution of the ase is suspended and the thread of ontrol is passed to the deomposition that desribes the reursive ativity (in this ase, ativity B is enabled). A new ase-id is reated for the thread of ontrol that is passed to the deomposition and a mapping funtion (in this example denoted by hild()) is used to apture the relationship between the parent ase-id and the deomposition ase-id, thus ensuring that one the hild ase has ompleted, the parent ase an ontinue from the point at whih it originally suspended exeution and invoked the hild instane of itself. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support if it it is able to satisfy the ontext riteria for the pattern. The original patterns did not expliitly identify the notion of triggers. Here we identify two types of triggers: the Transient Trigger (WCP-23) and the Persistent Trigger (WCP-24) patterns. Pattern WCP-23 (Transient Trigger) Desription The ability for an ativity to be triggered by a signal from another part of the proess or from the external environment. These triggers are transient in nature and are lost if not ated on immediately by the reeiving ativity. Examples Start the Handle Overflow ativity immediately when the dam apaity full signal is reeived. If possible, initiate the Chek Sensor ativity eah time an alarm trigger signal is reeived. Motivation Transient triggers are a ommon means of signalling that a pre-defined event has ourred and that an appropriate handling response should be undertaken 45

46 omprising either the initiation of a single ativity, a sequene of ativities or a new thread of exeution in a proess. Transient triggers are events whih must be dealt with as soon as they are reeived. In other words, they must result in the immediate initiation of an ativity. The workflow provides no form of memory for transient triggers. If they are not ated on immediately, they are irrevoably lost. Context Transient triggers have two ontext onditions assoiated with them: (1) it must be possible to diret a trigger to a speifi ativity instane exeuting in a speifi proess instane and (2) if the ativity instane to whih the trigger is direted is not waiting (for the trigger) at the time that the trigger is reeived, then the trigger is lost. There are two main variants of this pattern depending on whether the proess is exeuting in a safe exeution environment or not. Figure 35 shows the safe variant, only one instane of ativity B an wait on a trigger at any given time. Note that plae p2 holds a token for any possible proess instane. This plae makes sure that at most one instane of ativity B exists at any time. Figure 35: Transient trigger pattern The alternative option for unsafe proesses is shown in Figure 36. Multiple instanes of ativity B an remain waiting for a trigger to be reeived. However only one of these an be enabled for eah trigger when it is reeived. Implementation Staffware provides support for transient triggers via the Event Step onstrut. Similarly COSA provides the trigger onstrut whih an operate in both synhronous and asynhronous mode supporting transient and persistent triggers respetively. Both of these offerings implement the safe form of the pattern (as illustrated in Figure 35). SAP Workflow provides similar support via the wait for event step onstrut. UML 2.0 ADs provide the ability for signals to be disarded where there are not immediately required through the expliit enablement feature of the AeptEventAtion onstrut whih is responsible for handling inoming signals. 46

47 Figure 36: Transient trigger pattern (unsafe variant) Issues One onsideration that arises with the use of transient triggers is what happens when multiple triggers are reeived simultaneously or in a very short time interval. Are the latter triggers inherently lost as a trigger instane is already pending or are all instanes preserved (albeit for a potentially short timeframe). Solutions In general, in the implementations examined (Staffware, COSA and SAP Workflow) it seems that all transient triggers are lost if they are not immediately onsumed. There is no provision for transient triggers to be dupliated. Evaluation Criteria An offering ahieves full support if it it is able to satisfy the ontext riteria for the pattern. Pattern WCP-24 (Persistent Trigger) Desription The ability for an ativity to be triggered by a signal from another part of the proess or from the external environment. These triggers are persistent in form and are retained by the workflow until they an be ated on by the reeiving ativity. Examples Initiate the Staff Indution ativity eah time a new staff member event ours. Start a new instane of the Inspet Vehile ativity for eah servie overdue signal that is reeived. Motivation Persistent triggers are inherently durable in nature, ensuring that they are not lost in transit and are buffered until they an be dealt with by the target ativity. This means that the signalling ativity an be ertain that the trigger will result in the ativity to whih they are direted being initiated either immediately (if it already has reeived the thread of ontrol) or at some future time. 47

48 Context There are two variants of the persistent triggers. Figure 37 illustrates the situation where a trigger is buffered until ontrol-flow passes to the ativity to whih the trigger is direted. One this ativity has reeived a trigger, it an ommene exeution. Alternatively, the trigger an initiate an ativity (or the beginning of a thread of exeution) that is not ontingent on the ompletion of any preeding ativities. This senario is illustrated by Figure 38. Figure 37: Persistent trigger pattern Figure 38: Persistent trigger pattern new exeution thread variant Implementation Of the workflow systems examined, COSA provide support for persistent triggers via its integrated trigger onstrut, SAP Workflow has the wait for event step onstrut, FLOWer and FileNet provide the ability for ativities to wait on speifi data onditions that an be updated from outside the workflow. The business proess modelling formalisms BPMN, XPDL and BPEL all provide a mehanism for this form of triggering via messages and in all ases the messages are assumed to be durable in nature and an either trigger a standalone ativity or an enable a bloked ativity waiting on reeipt of a message to ontinue. UML 2.0 Ativity Diagrams provides a similar faility using signals. Although EPCs provide support for multiple input events whih an be utilized as persistent triggers, it is not possible to differentiate between them hene this is viewed as partial support. Note that if the pattern is not diretly supported, it is often possible to implement persistent triggers indiretly by adding a dummy ativity whih athes the trigger. Issues None identified. Solutions N/A 48

49 Evaluation Criteria An offering ahieves full support for this pattern if it provides any form of durable ativity triggering that an be initiated from outside the proess environment. If triggers do not retain a disrete identity when reeived and/or stored, an offering is viewed as providing partial support. Next we onsider some additional patterns related to anellation. Pattern WCP-25 (Canel Region) Desription The ability to disable a set of ativities in a proess instane. If any of the ativities are already exeuting, then they are withdrawn. The ativities need not be a onneted subset of the overall proess model. Examples Stop any ativities in the Proseution proess whih aess the evidene database from running. Withdraw all ativities in the Waybill Booking proess after the freight-lodgement ativity. Motivation The option of being able to anel a series of (potentially unrelated) ativities is a useful apability, partiularly for handling unexpeted errors or for implementing forms of exeption handling. anel region t Trigger ative anel normal end end start start region t bypass end t t SKIP t SKIP Figure 39: Canel region implementation Context The general form of this pattern is illustrated in Figure 39. It is based on the premise that every ativity in the required region has an alternate bypass ativity. When the anellation of the region is required, the proess instane ontinues exeution, but the bypass ativities are exeuted instead of the original ativities. As a onsequene, no further work ours on the ativities in the anellation region. However, as shown for the Canel Case (WCP-20) pattern, there are several alternative mehanisms that an be used to anel parts of a proess. There are two speifi requirements for this pattern: (1) it must be possible to denote a set of (not neessarily onneted) ativities that are to be anelled and (2) one anellation of the region is invoked, all ativity instanes within the region (both urrently exeuting and also those that may exeute at some future time) must be withdrawn. 49

50 Implementation The onept of anellation regions is not widely supported. Staffware offers the opportunity to withdraw steps but only if they have not already ommened exeution. FLOWer allows individual ativities to be skipped but there is no means of anelling a group of ativities. UML 2.0 Ativity Diagrams are the only offering examined whih provides omplete support for this pattern: the InterruptibleAtivityRegion onstrut allow a set of ativities to be anelled. BPMN and XPDL offer partial support by enlosing the ativities that will potentially be anelled in a subproess and assoiating an error event with the sub-proess to trigger anellation when it is required. In both ases, the shortoming of this approah is that the ativities in the sub-proess must be a onneted subgraph of the overall proess model. Similarly BPEL only supports anellation of ativities in the same sope hene it also ahieves a partial rating. As COSA has an integrated notion of state, it is possible to implement anellation regions in a similar way that presented in Figure 39 however the overall proess model is likely to beome intratable for anellation regions of any reasonable sale hene this is viewed as partial support. Issues One issue that an arise with the implementation of the Canel Region pattern ours when the anelling ativity lies within the anellation region. Although this ativity must run to ompletion and ause the anellation of all of the ativities in the defined anellation region, one this has been ompleted, it too must be anelled. Solutions The most effetive solution to this problem is to ensure that the anelling ativity is the last of those to be proessed (i.e. the last to be terminated) of the ativities in the anellation region. Evaluation Criteria An offering ahieves full support if it provides a onstrut that satisfies the ontext requirements for the pattern. Pattern WCP-26 (Canel Multiple Instane Ativity) Desription Within a given proess instane, multiple instanes of an ativity an be reated. The required number of instanes is known at design time. These instanes are independent of eah other and run onurrently. At any time, the multiple instane ativity an be anelled and any instanes whih have not ompleted are withdrawn. This does not affet ativity instanes that have already ompleted. Example Run 500 instanes of the Protein Test ativity with distint samples. If it has not ompleted one hour after ommenement, anel it. Motivation This pattern provides a means of anelling a multiple instane ativity at any time during its exeution suh that any remaining instanes are anelled. However any instanes whih have already ompleted are unaffeted by the anellation. Context There are two variants of this pattern depending on whether the ativity instanes are started sequentially or simultaneously. These senarios are depited in Figures 40 and 41. In both ases, transition C orresponds to the multiple instane ativity, whih is exeuted numinst times. When the anel transition is enabled, any remaining instanes of ativity C that have not already exeuted are withdrawn, as is the ability to initiate any additional instanes (via the reate instane transition). No subsequent ativities are enabled as a onsequene of the anellation. Note that both CPN models are assumed to operate in a safe ontext. 50

51 $! "!!! #! % Figure 40: Canel multiple instane ativity pattern sequential instanes Figure 41: Canel multiple instane ativity pattern onurrent instanes Implementation In order to implement this pattern, an offering also needs to support one of the Multiple Instane patterns that provide synhronization of the ativity instanes at ompletion (i.e. WCP-13 WCP-15). Staffware provides the ability to immediately terminate dynami subproedures albeit with loss of any assoiated data. SAP Workflow allows multiple instanes reated from a multi-line ontainer element to be terminated when the parent ativity terminates. BPMN and XPDL support the pattern via a MI task whih has an error type intermediate event trigger at the boundary. When the MI ativity is to be anelled, a anel event is triggered to terminate any remaining MI ativities. Similarly UML 2.0 ADs provide support by inluding the multiple instane ativity in a anellation region. Orale BPEL is able to support the pattern by assoiating a fault or ompensation handler with a <flown> onstrut. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support if it provides a onstrut that satisfies the ontext requirements for the pattern. If there are any limitations on the range of ativities that an appear within the anellation region or the types of ativity instanes that an be anelled then an offering ahieves a partial rating. Pattern WCP-27 (Complete Multiple Instane Ativity) Desription Within a given proess instane, multiple instanes of an ativity an be reated. The required number of instanes is known at design time. These instanes are independent of eah other and run onurrently. It is neessary to synhronize 51

52 " " the instanes at ompletion before any subsequent ativities an be triggered. During the ourse of exeution, it is possible that the ativity needs to be foribly ompleted suh that any remaining instanes are withdrawn and the thread of ontrol is passed to subsequent ativities. Example Run 500 instanes of the Protein Test ativity with distint samples. One hour after ommenement, withdraw all remaining instanes and initiate the next ativity. Motivation This pattern provides a means of finalising a multiple instane ativity that has not yet ompleted at any time during its exeution suh that any remaining instanes are withdrawn and the thread of ontrol is immediately passed to subsequent ativities. Any instanes whih have already ompleted are unaffeted by the anellation. Context There are two variants of this pattern depending on whether the ativity instanes are started sequentially or simultaneously. These senarios are depited in Figures 42 and 43. In both ases, transition C orresponds to the multiple instane ativity, whih is exeuted numinst times. When the anel transition is enabled, any remaining instanes of ativity C that have not already exeuted are withdrawn, as is the ability to add any additional instanes (via the add transition). The subsequent ativity (illustrated by transition B) is enabled immediately. Note that both CPN models are assumed operate in a safe ontext. $ #!!! % Figure 42: Complete multiple instane ativity pattern sequential instanes Figure 43: Complete multiple instane ativity pattern onurrent instanes Implementation In order to implement this pattern, an offering also needs to support one of the Multiple Instane patterns that provide synhronization of the ativity instanes at ompletion (i.e. WCP-13 WCP-15). FLOWer provides indiret 52

53 support for this pattern via the auto-omplete ondition on dynami plans whih fore-ompletes unfinished plans when the ondition evaluates to true however this an only our when all subplans have ompleted. Similarly, it also provides deadline support for dynami plans whih ensures that all remaining instanes are fored omplete one the deadline is reahed, however this ation also auses all subsequent ativities to be fore ompleted as well. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support if it provides a onstrut that satisfies the ontext requirements for the pattern. It demonstrates partial support if there are limitations on when the ompletion ativity an be initiated or if the fore ompletion of the remaining instanes does not result in subsequent ativities in the proess instane being triggered normally. The Strutured Disriminator (WCP-9) pattern is assumed to operate in a safe ontext and waits for the ompletion of all branhes before it resets. Therefore, we propose two extensions of the basi pattern whih relax some of these ontext assumptions and allow it to operate in different senarios. These variants are the Bloking Disriminator and the Canelling Disriminator. Pattern WCP-28 (Bloking Disriminator) Desription The onvergene of two or more branhes into a single subsequent branh following one or more orresponding divergenes earlier in the proess model. The thread of ontrol is passed to the subsequent branh when the first ative inoming branh has been enabled. The disriminator onstrut resets when all ative inoming branhes have been enabled one for the same proess instane. Subsequent enablements of inoming branhes are bloked until the disriminator has reset. Example When the first member of the visiting delegation arrives, the hek redentials ativity an ommene. It onludes when all delegation members have arrived. Owing to staff onstraints, only one instane of the hek redentials ativity an be undertaken at any time. Should members of another delegation arrive, the heking of their redentials is delayed until the first hek redentials ativity has ompleted. Motivation The Bloking Disriminator pattern is a variant of the Strutured Disriminator pattern that is able to run in environments where there are potentially several onurrent exeution threads within the same proess instane. This quality allows it to be used in loops and other proess strutures where more than one exeution thread may be reeived in a given branh in the time between the first branh being enabled and the Disriminator being reset. Context Figure 44 illustrates the operation of this pattern. It is more robust than the Strutured Disriminator as it is not subjet to the onstraint that eah inoming branh an only being triggered one prior to reset. However it does have the ontext ondition that the Disriminator onstrut an only deal with one ase at a time (i.e. one one of the inoming plaes i1 to im is triggered for a given ase, all other inoming triggers that are reeived are expeted to relate to the same ase). 53

54 Figure 44: Bloking disriminator pattern The Bloking Disriminator funtions by keeping trak of whih inputs have been triggered (via the triggered input plae) and preventing them from being re-enabled until the onstrut has reset as a onsequene of reeiving a trigger on eah inoming plae. An important feature of this pattern is that it is able to be utilized in environments that do not support a safe proess model or those that may reeive multiple triggerings on the same input plae e.g. where the Disriminator is used within a loop. A variation to this proess model where the triggered input plae is extended to keep trak of both ase-id and input branh is shown in Figure 45. This allows the Disriminator to operate in a onurrent environment where it may need to handle multiple ases simultaneously 6. Figure 45: Bloking disriminator pattern extension for onurrent proess instanes Implementation In the event of onurrent proess instanes attempting to simultaneously initiate the same Disriminator, it is neessary to keep trak of both the proess instane and the input branhes that have triggered the Disriminator and also the exeution threads that are onsequently bloked until it ompletes. The Bloking Disriminator is partially supported by BPMN, XPDL and UML 2.0 ADs. Issues None identified. 6 In many of the diagrams we assume that the ontext is restrited to one proess instane exeuting in isolation. This is the ase in Figure 44 where we do not distinguish different proess instanes (i.e., ase) in the list of input already reeived. Note that the type of generalization applied in Figure 45 ould also be applied to earlier diagrams. 54

55 Solutions N/A. Evaluation Criteria An offering ahieves full support if it provides a onstrut that satisfies the ontext requirements for the pattern. If there is any ambiguity in how the join ondition is speified, an offering is onsidered to provide partial support for the pattern. Pattern WCP-29 (Canelling Disriminator) Desription The onvergene of two or more branhes into a single subsequent branh following one or more orresponding divergenes earlier in the proess model. The thread of ontrol is passed to the subsequent branh when the first ative inoming branh has been enabled. Triggering the disriminator also anels the exeution of all of the other inoming branhes and resets the onstrut. Example After the extrat-sample ativity has ompleted, parts of the sample are sent to three distint laboratories for examination. One the first of these laboratories ompletes the sample-analysis, the other two ativity instanes are anelled and the review-drilling ativity ommenes. Motivation This pattern provides a means of expediting a proess instane where a series of inoming branhes to a join need to be synhronized but it is not important that the ativities assoiated with eah of the branhes (other than the first of them) be ompleted. Context The operation of this pattern is shown in Figure 46. It is a ontext ondition of this pattern that only one thread of exeution is ative for a given proess instane in eah of the preeding branhes to the Disriminator prior to it being reset. If this is not the ase, then the behaviour of the proess instane is likely to beome unpreditable at a later stage during exeution. Figure 46: Canelling disriminator pattern Inputs i1 to im to the Disriminator serve to identify the branhes preeding the onstrut. Transitions A1 to Am signify ativities in these preeding branhes. Transitions S1 to Sm indiate alternate bypass or anellation ativities for eah of these branhes (these exeution options are not initially available to inoming exeution threads). The first ontrol-flow token for a given ase reeived at any input will 55

56 ause B to fire and put a token in o1. As soon as this ours, subsequent exeution threads on other branhes are put into bypass mode and instead of exeuting the normal ativities (A1..Am) on their speifi branh, they an exeute the bypass transitions (S1..Sm). (Note that the bypass transitions do not require any interation. Hene they are exeuted diretly by the proess engine and we an assume that the skip transitions are exeuted one they are enabled and omplete almost instantaneously hene expediting ompletion of the branh). One all inoming branhes for a given ase have been ompleted, the Disriminator onstrut an then reset and be re-enabled again for the same ase. As with the Bloking Disriminator pattern, there is a variation (illustrated in Figure 47) that enables the Disriminator to funtion in highly onurrent environments where multiple proess instanes may need to be proessed by the Disriminator simultaneously. This is ahieved by extending plae p2 to keep trak of proess instanes whih have triggered the Disriminator but not yet aused it to reset. Figure 47: Canelling disriminator pattern extension for onurrent proess instanes Implementation In order to implement this pattern, it is neessary for the offering to support some means of denoting the extent of the inoming branhes to be anelled. This an be based on the Canel Region pattern although support is only required for a restrited form of the pattern as the region to be anelled will always be a onneted subgraph of the overall proess model with the Disriminator onstrut being the onnetion point for all of the inoming branhes. This pattern is supported by the fork onstrut in SAP Workflow with the number of branhes required for ompletion set to one. In BPMN it is ahieved by inorporating the inoming branhes and the disriminator in a sub-proess that has an error event assoiated with it. The error event is triggered, anelling the remaining branhes in the sub-proess, when the Disriminator is triggered by first inoming branh. This onfiguration is illustrated in Figure 48(a). A similar solution is available in XPDL. UML 2.0 ADs support the pattern in a similar way by enlosing all of the inoming branhes in an InterruptibleAtivityRegion whih is anelled when the Disriminator fires. Issues The major diffiulty with this pattern is in determining how muh of the proess model preeding the Disriminator is to be inluded in the anellation region. 56

57 A 1 1st branh omplete A 1 B B A n A n 1st branh omplete a) BPMN implementation b) UML 2.0 ADs implementation Figure 48: Canelling disriminator pattern implemented in BPMN and UML 2.0 ADs Solutions This issue is easily addressed in strutured workflows as all of the branhes bak to the preeding split onstrut whih orresponds to the Disriminator should be subjet to anellation. In Figure 49(a), it is easy to see that the area denoted by the dotted box should be the anellation region. It is a more omplex matter when the workflow is not strutured as in Figure 49(b) or other input ars exist into the preeding branhes to the Disriminator that are not related to the orresponding split as shown in Figure 49(). In both of these situations, the overall struture of the proess leading up to the Disriminator serves as a determinant of whether the pattern an be supported or not. In Figure 49(b), a anellation region an be oneived whih reahes bak to the first AND-split and the pattern an be implemented based on this. A formal approah to determining the sope of the anellation region an be found in [vda01]. In Figure 49(), the potential for other ontrol-flows to be introdued whih do not relate to the earlier AND-split, means that the pattern probably annot be supported in a proess model of this form. Evaluation Criteria An offering ahieves full support if it provides a onstrut that satisfies the ontext requirements for the pattern. An offering is onsidered to provide partial support for the pattern if there are side-effets assoiated with the exeution of the pattern (e.g. ativities in inoming branhes whih have not ompleted being reorded as omplete). As disussed before, the Partial Join an be seen as a generalization of Disriminator pattern (i.e., a 1-out-of-M join). Hene, we introdue some patterns generalizing the different variants of the Disriminator pattern (i.e. where N>1). 57

58 a) B C A AND D E DISC H F G b) AND B C A AND D E DISC H F G ) AND B C A AND D E DISC H OR F G Figure 49: Proess struture onsiderations for anelling disriminator Pattern WCP-30 (Strutured Partial Join) Desription The onvergene of M branhes into a single subsequent branh following a orresponding divergene earlier in the proess model. The thread of ontrol is passed to the subsequent branh when N of the inoming branhes have been enabled. Subsequent enablements of inoming branhes do not result in the thread of ontrol being passed on. The join onstrut resets when all ative inoming branhes have been enabled. Example One two of the preeding three Expenditure Approval ativities have ompleted, trigger the Issue Cheque ativity. Wait until the remaining ativities have ompleted before allowing the Issue Cheque ativity to fire again. Motivation The Strutured Partial Join pattern provides a means of merging two or more distint branhes resulting from a speifi parallel split or AND-split onstrut earlier in a workflow proess into a single branh. The join onstrut does not require triggers on all inoming branhes before it an fire. Instead a given threshold an be defined whih desribes the irumstanes under whih the join should fire typially this is presented as the ratio of inoming branhes that need to be live for firing as against the total number of inoming branhes to the join e.g. a 2-out-of-3 Join 58

59 signifies that the join onstrut should fire when two of three inoming ars are live. Subsequent ompletions of other remaining inoming branhes have no effet on (and do not trigger) the subsequent branh. As suh, the Strutured Partial Join provides a mehanism for progressing the exeution of a proess one a speified number of onurrent ativities have ompleted rather than waiting for all of them to omplete. Context The Strutured Partial Join pattern is one possible variant of the AND- Join onstrut where the number of inoming ars that will ause the join to fire (N) is between 2 and M - 1 (i.e. the total number of inoming branhes less one i.e. 2 N<M). There are a number of possible speializations of the AND-join pattern and they form a hierarhy based on the value of N. Where only one inoming ar must be live for firing (i.e. N=1), this orresponds to one of the variants of the Disriminator pattern (f. WCP-9, WCP-28 and WCP-29). An AND-Join where all inoming ars must be live (i.e. N=M) is the Synhronization or Generalized AND-Join pattern (WCP-3 or WCP-33) whih is desribed below. There are a number of relationships between ontrol-flow patterns and this issue is disussed in more depth in Setion 6. The pattern provides a means of merging two or more branhes in a workflow and progressing exeution of the workflow as rapidly as possible by enabling the subsequent (merged) branh as soon as a thread of ontrol has been reeived on N of the inoming branhes where N is less than the total number of inoming branhes. There are two ontext onditions assoiated with the use of this pattern: 1. Eah of the inoming branhes to the join must only be triggered one prior to it being reset; and 2. The Partial Join resets (and an be re-enabled) one all of its inoming branhes have been enabled preisely one. The semantis of the Strutured Partial Join pattern are illustrated in Figure 50. Note that B requires n tokens in plae p1 to progress. Figure 50: Strutured partial join pattern There are two possible variants on this pattern that arise from relaxing some of the ontext onditions assoiated with it. Both of these improve on the effiieny of the join whilst retaining its overall behaviour. The first alternative, the Bloking Partial Join (WCP-31) removes the requirement that eah inoming branh an only be enabled one between join resets. It allows eah inoming branh to be triggered multiple times although the onstrut only resets when one triggering has been reeived on eah input branh. It is illustrated in Figure 51 and disussed in further 59

60 detail on page 61. Seond, the Canelling Partial Join (WCP-32), improves the effiieny of the pattern further by anelling the other inoming branhes to the join onstrut one N inoming branhes have ompleted. It is illustrated in Figure 53 and disussed in further detail on page 62. Implementation One of the diffiulties in implementing the Partial Join is that it essentially requires a speifi onstrut to represent the join if it is to be done in a tratable manner. iplanet does so via the router onstrut whih links preeding ativities to a target ativity. A router an have a ustom trigger ondition speified for it that auses the target ativity to trigger when N inoming branhes are live. SAP Workflow provides partial support for this pattern via the fork onstrut although any unfinished branhes are anelled one the first ompletes. None of the other workflow systems examined offers a dediated onstrut. Staffware provides for a 1-out-of-2 join, but more omplex joins must be onstruted from this resulting in an over-omplex proess model. Similar diffiulties exist for COSA. Of the business modelling languages, both BPMN and XPDL appear to provide support for the Partial Join via the omplex gateway onstrut but the lak of detail on how the InomingCondition results in a partial rating. UML 2.0 ADs also suffers from a similar lak of detail on the JoinSpe onfiguration required to support this pattern. There is no ability to represent the onstrut in BPEL. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support if it provides a onstrut that satisfies the ontext requirements for the pattern. If there is any ambiguity in how the join ondition is speified, an offering is onsidered to provide partial support for the pattern. Pattern WCP-31 (Bloking Partial Join) Desription The onvergene of two or more branhes into a single subsequent branh following one or more orresponding divergenes earlier in the proess model. The thread of ontrol is passed to the subsequent branh when N of the inoming branhes have been enabled. The join onstrut resets when all ative inoming branhes have been enabled one for the same proess instane. Subsequent enablements of inoming branhes are bloked until the join has reset. Example When the first member of the visiting delegation arrives, the hek redentials ativity an ommene. It onludes when 80% of delegation members have arrived. Owing to staff onstraints, only one instane of the the hek redentials ativity an be undertaken at any time. Should members of another delegation arrive, the heking of their redentials is delayed until the first hek redentials ativity has ompleted. Motivation The Bloking Partial Join is a variant of the Strutured Partial Join that is able to run in environments where there are onurrent proess instanes, partiularly proess instanes that have multiple onurrent exeution threads. Context Figure 51 illustrates the operation of this pattern. The Bloking Partial Join funtions by keeping trak of whih inputs have been enabled (via the triggered input plae) and preventing them from being re-enabled until the onstrut has reset 60

61 as a onsequene of reeiving a trigger on eah inoming plae. After N inoming triggers have been reeived for a given proess instane (via tokens being reeived in N distint input plaes from i1 to im), the join fires and a token is plaed in output o1. The ompletion of the remaining N-M branhes has no impat on the join exept that it is reset when the last of them is reeived. The pattern shares the same advantages over the Strutured Partial Join as the Bloking Disriminator does over the Strutured Disriminator, namely greater flexibility as it is able to deal with the situation where a branh is triggered more than one e.g. where the onstrut exists within a loop. It also shares the same ontext ondition: it an only deal with one ase at a time (i.e. one one of the inoming plaes i1 to in is triggered for a given ase, all other inoming triggers that are reeived are assumed to relate to the same ase). Figure 51: Bloking partial join pattern There is a variation to this proess model where the triggered input plae is extended to keep trak of both ase and enabled input branhes and plae p4 is extended to keep trak of ases where the join has triggered (but not yet reset) is shown in Figure 52. This allows the join to operate in a onurrent environment where it may need to handle multiple ases simultaneously 7. Figure 52: Bloking partial join pattern extension for onurrent proess instanes 7 This a similar analogy to that noted for the Bloking Disriminator pattern. Figure 51 assumes that only one proess instane exeutes in isolation where as Figure 52 is apable of distinguishing between and managing instanes of distint proesses. 61

62 Implementation The approah to implementing this pattern is essentially the same as that for the Bloking Disriminator exept that the join fires when N inoming branhes have triggered rather than just the first. The Bloking Partial Join is partially supported by BPMN, XPDL and UML 2.0 ADs. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support if it provides a onstrut that satisfies the ontext requirements for the pattern. If there is any ambiguity in how the join ondition is speified, an offering is onsidered to provide partial support for the pattern. Pattern WCP-32 (Canelling Partial Join) Desription The onvergene of two or more branhes into a single subsequent branh following one or more orresponding divergenes earlier in the proess model. The thread of ontrol is passed to the subsequent branh when N of the inoming branhes have been enabled. Triggering the join also anels the exeution of all of the other inoming branhes and resets the onstrut. Example One the piture is reeived, it is sent to three art dealers for the examination. One two of the prepare ondition report ativities have been ompleted, the remaining prepare ondition report ativity is anelled and the plan restoration ativity ommenes. Motivation This pattern provides a means of expediting a proess instane where a series of inoming branhes to a join need to be synhronized but only a subset of those ativities assoiated with eah of the branhes needs to be ompleted. Context The operation of this pattern is shown in Figure 53. It is a ontext ondition of this pattern that only one thread of exeution is ative for a given proess instane in eah of the preeding branhes to the disriminator. If this is not the ase, then the behaviour of the proess instane is likely to beome unpreditable at a later stage during exeution. Figure 53: Canelling partial join pattern 62

63 As with the Canelling Disriminator pattern, there is a variation (illustrated in Figure 54) that enables the join to funtion in onurrent environments where multiple proess instanes may need to be proessed by the join onstrut simultaneously. This is ahieved by extending the p2 plae to keep trak of ases where the join has been triggered but not yet reset. Figure 54: Canelling partial join pattern extension for onurrent proess instanes Implementation The approah to implementing this pattern is essentially the same as that for the Canelling Disriminator exept that the join fires when N inoming branhes have triggered rather than just the first. The Canelling Partial Join is supported by SAP Workflow and UML 2.0 ADs. BPMN and XPDL ahieve a partial support rating as it is unlear exatly how the join ondition is speified. Issues As for the Canelling Disriminator pattern. Solutions As for the Canelling Disriminator pattern. Evaluation Criteria An offering ahieves full support if it provides a onstrut that satisfies the ontext requirements for the pattern. An offering is onsidered to provide partial support for the pattern if there are undesirable side-effets assoiated with the onstrut firing (e.g. ativities in inoming branhes whih have not ompleted being reorded as omplete) or if the semantis assoiated with the join ondition are unlear. Many of the advaned synhronization patterns assume a safe ontext (i.e. a plae annot be marked twie for the same proess instane). The following pattern is not prediated on this assumption and orresponds exatly to a transition in a non-safe Petri net. Pattern WCP-33 (Generalized AND-Join) Desription The onvergene of two or more branhes into a single subsequent branh suh that the thread of ontrol is passed to the subsequent branh when all input branhes have been enabled. Additional triggers reeived on one or more branhes between firings of the join persist and are retained for future firings. 63

64 Examples When all Get Diretors Signature ativities have ompleted, run the Complete Contrat ativity. Aumulate engine, hassis and body omponents from the various prodution lines. When one of eah has been reeived, use one of eah omponent to assemble the basi ar. Motivation The Generalized AND-Join orresponds to one of the generally aepted notions of an AND-join implementation (the other situation is desribed by the Synhronization pattern) in whih several paths of exeution are synhronized and merged together. Unlike the Synhronization pattern, it supports the situation where one or more inoming branhes may reeive multiple triggers for the same proess instane (i.e. a non-safe ontext). Context The operation of the Generalized AND-Join is illustrated in Figure 55. Before transition A an be enabled, an input token (orresponding to the same ase) is required in eah of the inoming plaes (i.e. i1 to i3). When there are orresponding tokens in eah plae, transition A is enabled and onsumes a token from eah input plae and one it has ompleted, deposits a token in output plae o1. If there is more than one token at an input plae, it ignores additional tokens and they are left in plae. The proess analogy to this sequene of events is that the AND-join only fires when a trigger has been reeived on eah inoming branh for a given proess instane however additional triggers are retained for future firings. This approah to ANDjoin implementation relaxes the ontext ondition assoiated with the Synhronization pattern that only allows it to reeive one trigger on eah inoming branh and as a result, it is able to be used in onurrent exeution environments suh as proess models whih involve loops as well as offerings that do not assume a safe exeution environment. One onsideration assoiated with the Generalized AND-Join is that over time, eah of the inoming branhes should deliver the same number of triggers to the AND-join onstrut (although obviously, the timing of these triggers may vary). If this is not the ase, then there is the potential for deadloks to our and/or tokens to remain after exeution has ompleted. Figure 55: Generalised AND-join pattern Implementation This need to provide persistene of triggerings (potentially between distint firings of the join) means that this onstrut is not widely supported by 64

65 the workflow engines and business proess modelling languages examined and only FileNet provides a onstrut for it. Token-based proess models suh as BPMN and XPDL have an advantage in this regard and both modelling notations are able to support this pattern 8. EPCs provide a degree of ambiguity in their support for this pattern whilst most doumentation indiates that they do not support it, in the ARIS Simulator, they exhibit the required behaviour hene they are awarded a partial support rating on aount of this variane. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support if it provides a onstrut that satisfies the ontext requirements for the pattern. If there is any ambiguity assoiated with the speifiation or use of the onstrut, an offering is onsidered to provide partial support for the pattern. The multiple instane patterns onsidered earlier are based on the assumption that subsequent ativities should be triggered only when all instanes have ompleted. The following three patterns provide for a partial (i.e. an N-out-of-M) join between instanes thus allowing subsequent ativities to be triggered one a threshold of onurrent ativities has been reahed. Pattern WCP-34 (Stati Partial Join for Multiple Instanes) Desription Within a given proess instane, multiple onurrent instanes of an ativity an be reated. The required number of instanes is known when the first ativity instane ommenes. One N of the ativity instanes have ompleted, the next ativity in the proess is triggered. Subsequent ompletions of the remaining M-N instanes are inonsequential. Example Examine 10 samples from the prodution line for defets. Continue with the next ativity when 7 of these examinations have been ompleted. Motivation The Stati Partial Join for Multiple Instanes pattern is an extension to the Multiple Instanes with a priori Runtime Knowledge pattern whih allows the proess instane to ontinue one a given number of the ativity instanes have ompleted rather than requiring all of them to finish before the subsequent ativity an be triggered. Context The general format of the Stati Partial Join for Multiple Instanes pattern is illustrated in Figure 56. Transition A orresponds to the multiple instane ativity. There are several ontext onditions assoiated with this pattern: The number of onurrent ativity instanes (denoted by variable m in Figure 56) is known prior to ativity ommenement; The number of ativities that need to ompleted before subsequent ativities in the proess model an be triggered is known prior to ativity ommenement. This is denoted by variable n in Figure 56; 8 Although we note that these formalisms are modelling languages whih do not need to speify how a given onstrut will atually be realized 65

66 One the required number of ativities have ompleted, the thread of ontrol an immediately be passed to subsequent ativities; The number of instanes that must omplete for the join to be triggered (n) annot be greater than the total number of onurrent ativity instanes (m), i.e. n m; and Completion of the remaining ativity instanes do not trigger a subsequent ativity, however all instanes must have ompleted in order for the join onstrut to reset and be subsequently re-enabled. In terms of the operation of this pattern, one the input plae i1 is triggered for a ase, m instanes of the multi-instane ativity A are initiated onurrently and a ative status is reorded for the pattern. These instanes proeed independently and one n of them have ompleted, the join an be triggered and a token plaed in output plae o1 signalling that the thread of ontrol an be passed to subsequent ativities in the proess model. Simultaneously with the join firing, the token is removed from the the ative plae allowing the remaining n - m ativities omplete. One all m instanes of ativity A have finished, the status of the pattern hanges to ready allowing it to be re-enabled. # # $ #! " Figure 56: Stati partial join implementation for multiple instanes There are two variants of this pattern whih allow for some of the ontext onditions desribed above to be relaxed. First, the Canelling Partial Join for Multiple Instanes pattern removes the last ontext onstraint by anelling any remaining ativity instanes as soon as the join fires. It is illustrated in Figure 57 and disussed further on page 67. The seond, the Dynami Partial Join for Multiple Instanes pattern relaxes the first ontext ondition and allows the value of m to be determined during the exeution of the ativity instanes. In partiular, it allows additional ativity instanes to be reated on the fly. This pattern is illustrated in Figure 58 and desribed in further detail on page 69. Implementation BPMN and XPDL both appear to offer support for this pattern via the Multiple Instane Loop Ativity onstrut where the MI Flow Condition attribute is set to omplex and ComplexMI FlowCondition is an expression that evaluates to true when exatly M instanes have ompleted ausing a single token to be passed on to the following ativity. However no detail is provided to explain 66

67 how the ComplexMI FlowCondition is speified hene this is onsidered to onstitute partial support for the pattern. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support if it provides a onstrut that satisfies the ontext riteria for the pattern. It ahieves partial support if there is any ambiguity assoiated with the speifiation of the join ondition. Pattern WCP-35 (Canelling Partial Join for Multiple Instanes) Desription Within a given proess instane, multiple onurrent instanes of an ativity an be reated. The required number of instanes is known when the first ativity instane ommenes. One N of the ativity instanes have ompleted, the next ativity in the proess is triggered and the remaining M-N instanes are anelled. Example Run 500 instanes of the Protein Test ativity with distint samples. One 400 of these have ompleted, anel the remaining instanes and initiate the next ativity. Motivation This pattern provides a variant of the multiple instanes pattern that expedites proess throughput by both allowing the proess to ontinue to the next ativity one a speified number (N) of the multiple instane ativities have ompleted and also anels any remaining ativity instanes negating the need to expend any further effort exeuting them. Context Figure 57 illustrates the operation of this pattern. It is similar in form to that for the Stati Partial Join for Multiple Instanes pattern (WCP-34) but funtions in a different way one the join has fired. At this point any remaining instanes whih have not already ommened are bypassed by allowing the skip ativity to exeute in their plae. The skip ativity exeutes almost instantaneously for those and the pattern is almost immediately able to reset. " $ $ "! # % " Figure 57: Canelling partial join implementation for multiple instanes This pattern shares four ontext onditions with the Stati Partial Join for Multiple Instanes pattern: the number of onurrent ativity instanes (m) and the ompletion threshold (n) must be known before ommenement, the number of instanes that must omplete for the join to be triggered (n) annot be greater than the total 67

68 number of onurrent ativity instanes (m), i.e. n m and subsequent ativities an be triggered as soon as the required ompletion threshold has been reahed, however the final ontext ondition is relaxed and the pattern is able to be re-enabled almost immediately after the ompletion threshold is reahed as remaining ativity instanes are anelled. Implementation This pattern relies on the availability of a Canel Ativity or Canel Region apability within an offering and at least one of these patterns needs to be supported for this pattern to be failitated. As for WCP-34, both BPMN and XPDL appear to offer support for this pattern by assoiated an error type intermediate trigger with the multiple instane ativity. Immediately following this ativity is an ativity that issues a anel event effetively terminating any remaining ativity instanes one the first N of them have ompleted. However it is unlear how the ComplexMI FlowCondition should be speified to allow the anellation to be triggered one N ativity instanes have ompleted. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support if it provides a onstrut that satisfies the ontext riteria for the pattern. An offering ahieves partial support if there is any ambiguity assoiated with the implementation of the pattern. Pattern WCP-36 (Dynami Partial Join for Multiple Instanes) Desription Within a given proess instane, multiple onurrent instanes of an ativity an be reated. The required number of instanes may depend on a number of runtime fators, inluding state data, resoure availability and inter-proess ommuniations and is not known until the final instane has ompleted. At any time, whilst instanes are running, it is possible for additional instanes to be initiated providing the ability to do so has not been disabled. A ompletion ondition is speified whih is evaluated eah time an instane of the ativity ompletes. One the ompletion ondition evaluates to true, the next ativity in the proess is triggered. Subsequent ompletions of the remaining ativity instanes are inonsequential and no new instanes an be reated. Examples The despath of an oil rig from fatory to site involves numerous transport shipment ativities. These our onurrently and although suffiient ativities are started to over initial estimates of the required transport volumes, it is always possible for additional ativities to be initiated if there is a shortfall in transportation requirements. One 90% of the transport shipment ativities are omplete, the next ativity (invoie transport osts) an ommene. The remaining transport shipment ativities ontinue until the whole rig has been transported. Motivation This pattern is a variant of the Multiple Instanes without a priori Runtime Knowledge pattern that allows the thread of exeution to pass to subsequent ativities one a speified ompletion ondition is met. It allows the proess to progress without requiring that all instanes assoiated with a multiple instane ativity have ompleted. Context Figure 58 illustrates the operation of this pattern. The multiple instane ativity is illustrated by transition A. At ommenement, the number of instanes 68

69 initially required is indiated by variable m. Additional instanes may be added to this at any time via the start instane transition. At ommenement, the pattern is in the ative state. One enough instanes of ativity A have ompleted and the join transition has fired, the next ativity is enabled (illustrated via a token being plaed in the output plae o1) and the remaining instanes of ativity A run to ompletion before the omplete transition is enabled. No new instanes an be reated at this time. Finally when all instanes of A have ompleted, the pattern resets and an be re-enabled. An important feature of the pattern is the ability to disable further reation of ativity instanes at any time after the first instanes has been reated. " # $! %! & ' Figure 58: Dynami partial join implementation for multiple instanes Implementation Of the offerings identified, only FLOWer provides support for the dynami reation of multiple instane ativities (via dynami subplans), however it requires all of them to be ompleted before any ompletion onditions assoiated with a dynami subplan (e.g. partial joins) an be evaluated and subsequent ativities an be triggered. This is not onsidered to onstitute support for this pattern. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support if it provides a onstrut that satisfies the ontext requirements for the pattern. It ahieves partial support if the reation of ativity instanes annot be disabled one the first ativity instane has ommened. When defining the Strutured Synhronizing Merge pattern (WCP-7) was introdued several ontext assumptions where made. Now we relax some of these assumptions. Pattern WCP-37 (Ayli Synhronizing Merge) Desription The onvergene of two or more branhes whih diverged earlier in the proess into a single subsequent branh. The thread of ontrol is passed to the subsequent branh when eah ative inoming branh has been enabled. Determination of how many branhes require synhronization is made on the basis of information loally available to the merge onstrut. This may be ommuniated diretly to the 69

70 merge by the preeding diverging onstrut or alternatively it an be determined on the basis of loal data suh as the threads of ontrol arriving at the merge. Example Figure 59 provides an example of one solution to this pattern. It is based on the use of true and false tokens whih are used to indiate whether a branh is enabled or not. After the divergene at transition A, one or both of the outgoing branhes may be enabled. The determinant of whether the branh is enabled is that the token passed to the branh ontains both the ase id as well as a boolean variable whih is true if the ativities in the branh are to be exeuted, false otherwise. As the ontrol-flow token is passed down a branh, if it is a true token, then eah ativity that reeives the thread of ontrol is exeuted otherwise it is skipped (illustrated by the exeution of the bypass ativity s1..sn assoiated with eah ativity). The Synhronizing Merge, whih in this example is illustrated by transition E, an be evaluated when every inoming branh has delivered a token to the input plaes for the same ase. Figure 59: Ayli synhronizing merge pattern Another possible solution is provided by Rittgen [Rit99]. It involves the diret ommuniation of the number of ative branhes from the preeding OR-Join divergene to the Synhronizing Merge so that it is able to determine when to fire. Motivation The Ayli Synhronizing Merge provides a deterministi semantis for the Synhronizing Merge pattern whih does not rely on the proess model being strutured (as is required for the Strutured Synhronizing Merge) but also does not require the use of non-loal semantis in evaluating when the merge an fire. Context The Ayli Synhronizing Merge has two ontext onditions assoiated with its usage: (1) the merge onstrut must be able to determine how many inoming branhes require synhronization based on loal knowledge available to it during exeution and (2) eah ative inoming branh must only ontain at most one thread of ontrol for a given proess instane. One of the main onsiderations whih flows from this onstraint is that it is not possible for this pattern to be used in loops (other than by inluding the entire subproess ontaining both the preeding divergene(s) and the Ayli Synhronizing Merge whih is repeated). 70

71 Implementation WebSphere MQ, FLOWer, COSA, BPEL and EPCs provide support for this pattern. UML 2.0 ADs seems to provide support although there is some ambiguity over the atual JoinSpe onfiguration required. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support if it provides a onstrut that satisfies the ontext riteria for the pattern. If there is any ambiguity as to the manner in whih the synhronization ondition is speified, then it rates as partial support. Pattern WCP-38 (General Synhronizing Merge) Desription The onvergene of two or more branhes whih diverged earlier in the proess into a single subsequent branh. The thread of ontrol is passed to the subsequent branh when eah ative inoming branh has been enabled or it is not possible that the branh will be enabled at any future time. Example Figure 60 provides an example of the General Synhronizing Merge pattern. It shares a similar fundamental struture to the examples presented in Figures 7 and 59 for the other forms of OR-join however the feedbak path from p4 to p1 involving F (whih effetively embeds a loop within the proess) means that it is not possible to model it either in a strutured way or to to use loal information available to E to determine when the OR-join should be enabled. Figure 60: General synhronizing merge pattern Motivation This pattern provides a general approah to the evaluation of the ORjoin onstrut in workflow. It is able to be used in non-strutured and highly onurrent workflow inluding proess models that inlude looping strutures. Context This pattern provides general support for the OR-join onstrut that is widely utilised in modelling languages but is often only partially implemented or severely restrited in the form in whih it an be used. The diffiulty in implementing the Synhronizing Merge stems from the fat that its evaluation relies on non-loal semantis [vdadk02] in order to determine when it an fire. In fat it is easy to see that this onstrut an lead to the viious irle paradox [Kin06] where two OR-joins depend on one another. The OR-join an only be enabled when the thread of ontrol has been reeived from all inoming branhes and it is ertain that the remaining inoming branhes whih have not been enabled will never be enabled at any future time. Determination 71

72 of this fat requires a (omputationally expensive) evaluation of possible future states for the urrent proess instane. Implementation FileNet is the only offering examined to support this pattern. An algorithm desribing its implementation based on Reset-Nets is desribed in [WEvdAtH05] and has been used as the basis for the OR-join onstrut in the YAWL referene implementation [vdath05]. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support if it provides a onstrut that implements the ontext requirements for the pattern. When disussing the Interleaved Parallel Routing pattern (WCP-17), we assumed the interleaved ativities to be atomi. This an be generalized to ritial setions where whole sets of ativities should be exeuted on an atomi basis. Pattern WCP-39 (Critial Setion) Desription Two or more onneted subgraphs of a proess model are identified as ritial setions. At runtime for a given proess instane, only ativities in one of these ritial setions an be ative at any given time. One exeution of the ativities in one ritial setion ommenes, it must omplete before another ritial setion an ommene. Example Both the take-deposit and final-payment ativities in the holiday booking proess require the exlusive use of the redit-ard-proessing mahine. Consequently only one of them an exeute at any given time. Motivation The Critial Setion pattern provides a means of limiting two or more setions of a proess from exeuting onurrently. Generally this is neessary if ativities within this setion require exlusive aess to a ommon resoure (either data or a physial resoure) neessary for an ativity to be ompleted. However, there are also regulatory situations (e.g. as part of due diligene or quality assurane proesses) whih neessitate that two ativities do not our simultaneously. Context The operation of this pattern is illustrated in Figure 61. The mutex plae serves to ensure that within a given proess instane, only the sequene BD or CE an be ative at any given time. ritial setion p1 B p3 D p6 i1 A () () mutex () F o1 () Unit () p2 C p5 E p7 () ritial setion () Figure 61: Critial setion pattern 72

73 Implementation Although useful, this pattern is not widely supported amongst the offerings examined. BPEL allows it to be diretly implemented through its serializable sope funtionality. COSA supports this pattern by inluding a mutex plae in the proess model to prevent onurrent aess to ritial setions. FLOWer provides indiret support through the use of data elements as semaphores. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support if it provides a onstrut that implements the ontext requirements for the pattern. Where an offering is able to ahieve similar funtionality through onfiguration or extension of its existing onstruts this qualifies as partial support. Pattern WCP-40 (Interleaved Routing) Desription Eah member of a set of ativities must be exeuted one. They an be exeuted in any order but no two ativities an be exeuted at the same time (i.e. no two ativities an be ative for the same proess instane at the same time). One all of the ativities have ompleted, the next ativity in the proess an be initiated. Example The hek-oil, test-feeder, examine-main-unit and review-warranty ativities all need to be undertaken as part of the mahine-servie proess. Only one of them an be undertaken at a time, however they an be exeuted in any order. Motivation The Interleaved Routing pattern relaxes the partial ordering onstraint that exists with the Interleaved Parallel Routing pattern and allows a sequene of ativities to be exeuted in any order. Context Figure 62 illustrates the operation of this pattern. After A is ompleted, ativities B, C, D and E an be ompleted in any order. The mutex plae ensures that only one of them an be exeuted at any time. After all of them have been ompleted, ativity F an be undertaken. Figure 62: Interleaved routing pattern There are two onsiderations assoiated with the use of this pattern: (1) for a given proess instane, it is not possible for two ativities from the set of ativities 73

74 subjet to interleaved routing to be exeuted at the same time and (2) ativities must be initiated and ompleted on a sequential basis, in partiular it is not possible to suspend one ativity during its exeution to work on another. Implementation In order to effetively implement this pattern, an offering must have an integrated notion of state that is available during exeution of the ontrolflow perspetive. COSA has this from its Petri-Net foundation and is able to diretly support the pattern. Other offerings lak this apability and hene are not able to diretly support this pattern. BPEL (although not Orale BPEL) an ahieve similar effets using serializable sopes within the ontext of a <pik> onstrut. FLOWer has a distint foundation to that inherent in other workflow produts in whih all ativities in a ase are always alloated to the same resoure for ompletion hene interleaving of ativity exeution is guaranteed, however it is also possible for a resoure to suspend an ativity during exeution to work on another hene the ontext onditions for this pattern are not fully satisfied. BPMN and XPDL indiretly support the pattern through the use of ad-ho proesses however it is unlear how it is possible to ensure that eah ativity in the ad-ho sub-proess is exeuted preisely one. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support if it provides a onstrut that satisfies the ontext requirements for the pattern. An offering is rated as having partial support if it has limitations on the range of ativities that an be oordinated (e.g. ativities must be in the same proess blok) or if it annot enfore that ativities are exeuted preisely one or ensure ativities are not able to be suspended one started whilst other ativities in the interleave set are ommened. The issue of synhronizing multiple branhes within a proess model has reeived a great deal of fous and is addressed by a number of patterns earlier in this paper. However the synhronization of multiple threads of exeution within the same branh has not reeived the same degree of attention and onsequently is the subjet of the next two patterns. Pattern WCP-41 (Thread Merge) Desription At a given point in a proess, a nominated number of exeution threads in a single branh of the same proess instane should be merged together into a single thread of exeution. Example Instanes of the register-vehile ativity run independently of eah other and of other ativities in the Proess Enquiry proess. They are reated as needed. When ten of them have ompleted, the proess-registration-bath ativity should exeute one to finalise the vehile registration system reords update. Motivation This pattern provides a means of merging multiple threads within a given proess instane. It is a ounterpart to the Thread Split pattern whih reates multiple exeution threads along the same branh. In some situations, it an also be used in onjuntion with the Multiple Instanes without Synhronization pattern (WCP-12) however there is the requirement that eah of the multiple instanes exeute along the same branh in the proess. 74

75 Context The operation of this pattern is illustrated in Figure 63. A value for numinsts is inluded in the design-time proess model and indiates the number of threads to be merged. Figure 63: Thread merge pattern There are two ontext onsiderations for this pattern: (1) the number of threads needing to be merged must be known at design-time and (2) only exeution threads for the same proess instane an be merged. If it is to be used to merge independent exeution threads arising from some form of ativity spawning (e.g. as a result of WCP-12), then it must be possible to identify the speifi threads that need to be oalesed. Implementation Implementation of this pattern implies that an offering is able to support the exeution of proesses in a non-safe ontext. This rules out the majority of the workflow systems examined from providing any tratable forms of implementation. BPMN and XPDL provide diret support for the pattern by inluding an ativity after the spawned ativity in whih the StartQuantity attribute is set to the number of threads that need to be synhronized. The StartQuantity attribute speifies the number of inoming tokens required to start an ativity. UML 2.0 ADs offer a similar behaviour via weights on AtivityEdge objets. BPEL provides an indiret means of implementation based on the orrelation faility for feedbak from the <invoke> ation although some programmati housekeeping is required to determine when synhronization should our. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support for this pattern if it provides a onstrut that satisfies the ontext requirements. If any degree of programmati extension is required to ahieve the same behaviour, then the partial support rating applies. Pattern WCP-42 (Thread Split) Desription At a given point in a proess, a nominated number of exeution threads an be initiated in a single branh of the same proess instane. Example At the ompletion of the onfirm paper reeival ativity, initiate three instanes of the subsequent independent peer review ativity. Motivation This pattern provides a means of triggering multiple exeution threads along a branh within a given proess instane. It is a ounterpart to the Thread Merge pattern whih merges multiple exeution threads along the same branh. Unless used in onjuntion with the Thread Merge pattern, the exeution threads will run independently to the end of the proess. Context The operation of this pattern is illustrated in Figure 64. A value for numinsts is inluded in the design-time proess model and indiates the number of threads to be merged. 75

76 Figure 64: Thread merge pattern There are two ontext onsiderations for this pattern: (1) the number of threads to be initiated must be known at design-time and (2) all threads must be initiated from the same point in the proess model (i.e. they must flow along the same branh). Implementation As with the Thread Merge pattern, implementation of this pattern implies that an offering is able to support the exeution of proesses in a non-safe ontext. This rules out the majority of the workflow systems examined from providing any tratable forms of implementation. BPMN and XPDL provide diret support for the pattern by allowing the Quantity of tokens flowing down the outgoing sequene flow from an ativity at its onlusion to be speified. UML 2.0 ADs allow a similar behaviour to be ahieved through the use of multiple outgoing edges from an ativity to a MergeNode whih then direts the various initiated threads of ontrol down the same branh. BPEL indiretly allows the same effet to be ahieved via the <invoke> ation in onjuntion with suitably speified orrelation sets. Issues None identified. Solutions N/A. Evaluation Criteria An offering ahieves full support for this pattern if it provides a onstrut that satisfies the ontext requirements. If any degree of programmati extension is required to ahieve the same behaviour, then the partial support rating applies. Finally, we introdue the ounterpart of the Impliit Termination pattern (WCP-11). Pattern WCP-43 (Expliit Termination) Desription A given proess (or sub-proess) instane should terminate when it reahes a nominated state. Typially this is denoted by a speifi end node. When this end node is reahed, any remaining work in the proess instane is anelled and the overall proess instane is reorded as having ompleted suessfully. Example N/A. Motivation The rationale for this pattern is that it represents an alternative means of defining when a proess instane an be designated as omplete. This is when the thread of ontrol reahes a defined state within the proess model. Typially this is denoted by a designated termination node at the end of the model. Context There are two speifi ontext onditions assoiated with this pattern: (1) every ativity in a the proess must be on a path from a defined starting node to a defined end node and (2) when the thread of ontrol reahes the end node, the proess is deemed to have ompleted suessfully regardless of whether there are any ativities in progress or remaining to be exeuted. For example, where a log is kept of proess ativity, the proess instane would be reorded as ompleting suessfully. Implementation COSA, iplanet, SAP Workflow, BPMN, XPDL and UML 2.0 ADs support this pattern although other than iplanet, none of these offerings enfore that there is a single end node. 76

77 Issues One onsideration that does arise where a proess model has multiple end nodes is whether it an be transformed to one with a single end node. Solutions For simple proess models, it may be possible to simply replae all of the end nodes for a proess with links to an OR-join whih then links to a single final node. However, it is less lear for more omplex proess models involving multiple instane ativities whether they are always able to be onverted to a model with a single terminating node. Potential solutions to this are disussed at length in [KtHvdA03]. Evaluation Criteria An offering ahieves full support for this pattern if it demonstrates that it an meet the ontext requirements for the pattern. This onludes the disussion of new patterns relevant to the ontrol-flow perspetive of proess-aware information systems. We now move on to a omprehensive disussion of the degree of support for eah of these patterns in individual ommerial offerings. 77

78 5 Evaluating Proess-Aware Information Systems In this setion, we onsider the evaluation results obtained from a detailed analysis of the ontrol-flow patterns aross fourteen ommerial offerings. The produts examined inlude workflow systems, a ase handling system, business proess exeution languages and business proess modelling formalisms. The speifi produts/languages examined were: Staffware Proess Suite 10; IBM WebSphere MQ Workflow 3.4; FLOWer 3.5.1; COSA 5.1; Sun ONE iplanet Integration Server 3.0; SAP Workflow version 4.6 FileNet P8 BPM Suite version 3.5 BPEL version 1.1; WebSphere Integration Developer 6.0.2, the development environment for the Business Proess Choreographer (BPC) part of WebSphere Proess Server v6.0.2; Orale BPEL v10.1.2; BPMN version 1.0; XPDL version 2.0; UML 2.0 Ativity Diagrams; and EPCs as implemented by ARIS Toolset 6.2. Although many of the evaluation results reinfore observations regarding pattern implementation that have been made over the past seven years, it is interesting to observe some of the trends that have beome evident in reent produt offerings. These are brought into sharper relief through the augmented set of ontrol-flow patterns desribed in this paper. Traditionally workflow systems have employed proprietary approahes both to the range of onepts that an be expressed in design-time proess models and also to the way that those models are enated at run-time. The implementation of onepts suh as threads of ontrol, join semantis and loops differ markedly between offerings. The fundamental proess model employed by speifi produts has been a partiularly vague area. This seems to have hanged in reent offerings towards a more formally defined and better understood model with BPEL, BPMN, XPDL and UML 2.0 ADs all laiming an underlying exeution model that is token-based. Although the revised definitions of the original patterns inludes some more restritive definitions partiularly for patterns suh as Strutured Synhronizing Merge, Strutured Disriminator, Multiple Instanes with Design-Time Knowledge and Interleaved Parallel Routing these patterns ontinue to be relatively widely supported. In partiular all of the basi patterns (WCP-1 to WCP-5) are still supported by all offerings examined. The revised definition of the the Strutured Synhronizing Merge tends to favour blok strutured languages suh as WebSphere MQ and BPEL although it is also supported by COSA, FileNet, BPMN, XPDL and EPCs despite the restritions that it implies on the manner in whih it an be used. Although more flexible variants of it an be delineated in the form of the Ayli Synhronizing Merge and the General 78

79 Table 1: Produt Evaluations Original Patterns (WCP1 - WCP20) Staffware WebSphere MQ FLOWer COSA iplanet SAP Workflow Pattern 1 (seq) (par-spl) (synh) (ex-h) (simple-m) (m-hoie) (s-syn-m) (multi-m) +/ +/ (s-dis) + +/ +/ +/ +/ 10 (arb-) (impl-t) (mi-no-s) / (mi-dt) (mi-rt) (mi-no) + 16 (def-) + + +/ (int-par) +/ + +/ +/ 18 (milest) +/ + 19 (an-a) + +/ (an-) +/ FileNet BPEL WebSphere BPEL Orale BPEL BPMN XPDL UML ADs EPC Synhronizing Merge, these forms are only minimally supported. Similar observations an be drawn for the Strutured Disriminator and the Strutured Partial Join whih have minimal support partiularly amongst offerings with an atual exeution environment and the other flexible forms of these patterns (i.e. Bloking and Canelling Disriminator and Bloking and Canelling Partial Join) whih have extremely minimal support overall. An interesting observation arising from these patterns is that despite the laims in regard to the existene of a deterministi mapping from business modelling languages suh as BPMN and XPDL to the exeution language BPEL, there are a number of patterns suh as the Multi-Merge, all forms of the Disriminator and the Partial Join and Arbitrary Cyles whih are supported in the former languages but not in BPEL begging the question of how these patterns an atually be implemented. This finding is onsistent with other researh [OvdADtH06] and reflets the fat that modelling languages tend to fare better in patterns evaluations than atual operational produts 79

80 beause they are not faed with the burden of atually having to implement everything that they are able to model! In general, the evaluation results for the two BPEL offerings - WebSphere Integration Developer and Orale BPEL indiate that they provide relatively faithful implementations of the BPEL speifiation. One noteworthy exeption to this is the additional <flown> onstrut provided by Orale BPEL whih allows it to implement several of the multiple instane patterns whih other BPEL variants are not able to support. The form of the Arbitrary Cyles pattern tends to mitigate against it being supported in blok strutured languages suh as WebSphere MQ or BPEL. However the more restrited form of repetition the Strutured Loop pattern is quite widely supported in a number of offerings inluding WebSphere MQ, FLOWer, iplanet, FileNet, BPEL, BPMN and XPDL. Other than for the Multiple Instanes without Synhronization pattern whih is widely supported, there ontinues to be minimal support for managing ontrolled ativity onurreny in its various forms (e.g. Multiple Instanes with Design-Time/with Run-time/without Run-Time Knowledge, various forms of Partial Join for Multiple Instanes, Canel Multiple Instane Ativity). Staffware, FLOWer and Orale BPEL are the only offerings that provide some degree of runtime support for the various multiple instane patterns whilst BPMN and XPDL provide the ability to apture them in design-time models. The Expliit Termination pattern has been introdued to desribe situations where there is a dediated termination node in a proess rather than the assumption that a proess instane terminates when there is no more work remaining (i.e. Impliit Termination). Most offerings support one or the other of these patterns, but interestingly BPMN, XPDL and UML 2.0 ADs support both patterns. In terms of state-based patterns, effetive implementation of the Deferred Choie favours those offerings with a deterministi underpinning (e.g. token-based) suh as COSA, BPEL, BPMN, XPDL and UML 2.0 ADs. Only COSA diretly supports Interleaved Parallel Routing and in general, it seems that an integrated notion of state is required to effetively implement this pattern. Similar omments apply to the Milestone pattern. Where the partial ordering requirement is relaxed allowing for arbitrary exeution order (i.e. Interleaved Routing), BPEL (although not Orale BPEL) is also able to provide support. The need to ensure that ativities are not running in parallel is not present in FLOWer. However, the lak of true onurreny (other than interleaving) rules out full support for this pattern. Interestingly, the adho ativity onstrut in BPMN and XPDL provides a means of indiretly ahieving this pattern but does not faithfully ensure that eah ativity is run preisely one. The Critial Setion pattern is only supported by COSA and BPEL. Canellation patterns are another area worthy of omment. Canel Ativity is widely supported although WebSphere MQ is a notable exeption. Of interest is the distintion between withdrawing an ativity prior to it ommening (supported by Staffware, COSA, SAP) and anelling it during exeution (supported by BPEL, BPMN, XPDL and UML 2.0 ADs). Similarly the Canel Case pattern is widely supported (by SAP, FileNet, BPEL, BPMN, XPDL, UML 2.0 ADs), but anellation of an arbitrary region (i.e. Canel Region) is not, only fully supported by UML 2.0 ADs. 80

81 Table 2: Produt Evaluations New Patterns (WCP21 - WCP43) Staffware WebSphere FLOWer COSA iplanet SAP Workflow Pattern 21 (str-l) (reur) (t-trig) (p-trig) / 25 (an-r) +/ +/ +/ +/ +/ +/ + 26 (an-mi) (omp-mi) +/ 28 (b-dis) +/ +/ +/ 29 (-dis) (s-pjoin) + +/ +/ +/ +/ 31 (b-pjoin) +/ +/ +/ 32 (-pjoin) + +/ +/ + 33 (g-and-join) / 34 (st-pjoin-mi) +/ +/ 35 (-pjoin-mi) +/ +/ 36 (dyn-pjoin-mi) 37 (a-syn-m) / + 38 (g-syn-m) + 39 (rit-se) +/ (int-rout) +/ / +/ 41 (tm) +/ +/ +/ (ts) +/ +/ +/ (exp-t) FileNet BPEL WebSphere BPEL Orale BPEL BPMN XPDL UML ADs EPC 81

82 Trigger-based patterns whih offer the ability for external fators to ontrol proess exeution are also widely supported. Staffware implements transient triggers whilst persistent triggers are offered by FileNet, BPEL, BPMN and XPDL. COSA, SAP Workflow and UML 2.0 ADs implement both forms of trigger. 82

83 6 Relationships Between Patterns In his seminal work A Patterns Language [AIS77], Alexander advaned the proposition that one of the most interesting aspets of a patterns taxonomy in a given domain lays in the relationships that exist between the individual patterns. For the ontrol-flow patterns, there are two relationships that of of interest: the speialization relationship whih identifies where one pattern is a more restrited form of another pattern and the omposition relationship whih identifies groups of patterns whih an be used together to provide the same funtionality as another pattern. These are disussed in further details below. 6.1 Speialization Relationships A speialization relationship exists between two patterns where one is a more restrited form of another i.e. it supports a subset of the behaviours of another or operates in a more restrited situation. As an example of this, the Multi-hoie (WCP-6) is a more general form of the Parallel Split (WCP-2) pattern. Indeed, the Multi-hoie an be substituted for the Parallel Split without any resultant loss of funtionality. For some patterns suh as the Synhronization (WCP-2) or several of the Disriminator variants, there are several possible speializations. Table 3 identifies eah of these relationships. Table 3: Speialization relationships between workflow patterns Nr Speialized Pattern Name General Pattern 31. Bloking Partial Join 3 Synhronization 32. Canelling Partial Join (only where N=M) 33. Generalized AND-Join 38. General Synhronizing Merge 4 Exlusive Choie 6. Multi-Choie 5 Simple Merge 8. Multi-Merge 6 Multi-hoie 2. Parallel Split 7 Strutured Synhronizing Merge 37. Ayli Synhronizing Merge 9 Strutured Disriminator 28. Bloking Disriminator 30. Strutured Partial Join 13 MIs with a priori D/T Knowledge 14. MIs with a priori R/T Knowledge 14 MIs with a priori R/T Knowledge 15. MIs without a priori R/T Knowledge 19 Canel Ativity 25. Canel Region 20 Canel Case 25. Canel Region 26 Canel Multiple Instane Ativity 19. Canel Ativity 27 Complete MI Ativity 26. Canel MI Ativity 28 Bloking Disriminator 31. Bloking Partial Join 29 Canelling Disriminator 32. Canelling Partial Join 30 Strutured Partial Join 31. Bloking Partial Join 34 Stati Partial Join for MIs 36. Dynami Partial Join for MIs 37 Ayli Synhronizing Merge 38. General Synhronizing Merge 40 Interleaved Routing 17. Interleaved Parallel Routing 83

84 The speialization relationships forms a hierarhy that an also be illustrated graphially as shown in Figure 6.2. Note that implied transitive relationships have not been inluded for the sake of larity. 6.2 Composition Relationships In some ases, it is possible that a pattern an be implemented through a ombination of two (or more) other patterns. For example, the Canelling Disriminator (WCP-29) an be implemented using a ombination of the Canel Region (WCP- 25) and Bloking Disriminator (WCP-28) patterns. This type of relationship is termed a omposition relationship. Table 4 identifies the most signifiant examples of these relationships between patterns although the list is not exhaustive as differing implementation approahes for individual patterns may result alternate omposition relationships. Table 4: Composition relationships between workflow patterns Nr Pattern Name Composed From 6 Multi-Choie 2. Parallel Split in onjuntion with 4. Exlusive Choie 10 Arbitrary Cyles 9 4. Exlusive Choie together with 5. Simple Merge 12 MI without Synhronization 4 6. Multi-Choie together with 8. Multi-Merge 21 Strutured Loop 4 4. Exlusive Choie together with 8. Multi-Merge 29 Canelling Disriminator 25. Canel Region together with 28. Bloking Disriminator 32 Canelling Partial Join 25. Canel Region together with 31. Bloking Partial Join 35 Canelling Partial Join for MIs 34. Stati Partial Join for MIs together with 26. Canel MI Ativity To provide some ontext to the omplete set of relationships, the diagram in Figure 6.2 illustrates all of the relationships identified in a single diagram. Speializations are shown with a solid line and omposition relationships with a dashed line. Through this diagram it is possible to get a learer idea of the relationships between various patterns and it is an interesting observation that this onneted diagram inludes 32 of the 43 patterns identified. 84

85 Strutured Loop Exlusive Choie Canelling Partial Join for Multiple Instanes Dynami Partial Join for Multiple Instanes Stati Partial Join for Multiple Instanes Multiple Merge Multiple Choie Multiple Instanes with Design Time Knowledge Multiple Instanes with Run Time Knowledge Multiple Instanes without Run Time Knowledge Simple Merge Parallel Split Synhronization Interleaved Parallel Routing Interleaved Routing Arbitrary Cyles Generalized AND Join Bloking Partial Join General Synhronizing Merge Complete Multiple Instane Ativity Multiple Instanes without Synhronization Bloking Disriminator Strutured Partial Join Ayli Synhronizing Merge Canel Multiple Instane Ativity Canelling Disriminator Canelling Partial Join Strutured Disriminator Strutured Synhronizing Merge Canel Ativity Canel Case Canel Region Figure 65: Speialization and omposition relationships between patterns 85

86 7 Conlusions In this paper, we have reviewed the original twenty ontrol-flow patterns and have provided a preise definition of their operation and the ontext in whih they are intended to be utilized. We have also reviewed their implementation in fourteen ommerial offerings. The original set of patterns remains as valid as they were when first identified seven years ago and all of them have been retained as a result of this survey. One of the major ontributions of this researh effort is the establishment of a lear set of operational semantis for eah of pattern. This is intended to remove any potential for ambiguity or misinterpretation that may have existed with earlier doumentation. As a onsequene of refining the definition of eah pattern, it has been possible to identify twenty three additional patterns relevant to the ontrol-flow perspetive. Some of these are a result of having ahieved a better understanding of the original patterns and reognizing that in some ases individual patterns ould potentially have more than one interpretation, whilst other patterns reflet our deeper understanding of the ontrol-flow perspetive and reognize some gaps that may have existed in the original set. An important observation that we draw from this researh is the disparity that exists between modelling languages and atual produt implementations in terms of the number of patterns that they support. Whilst several of the ontemporary modelling formalisms (BPMN, XPDL, UML 2.0 ADs) are able to apture a broad range of patterns, it is interesting to note that they do not demonstrate how these patterns will atually be realized in pratie. This opens up an inherent ontradition where a partiular offering laims to be ompliant with a partiular modelling formalism but supports less patterns. Similar diffiulties exist with proposed mappings between these modelling languages and partiular exeution tools as they annot laim to be omplete. Patterns identifiation in any domain is by definition an experiental ativity and it is not possible to guarantee the ompleteness of any patterns olletion. However, it is exatly this approah to knowledge gathering that ensures that patterns remain relevant to the domain that they seek to desribe. By pairing this strategy with a formal approah to desribing the onepts that are disovered and ontinually refining these definitions on a long-term basis, the Workflow Patterns Initiative aims to provide the most omprehensive desription available of onepts relevant to the modelling and exeution of workflow systems both now and on an ongoing basis. In tandem with this researh, the YAWL System ( provides an open-soure referene model for workflow systems based on the workflow patterns. YAWL urrently supports 32 of the ontrol-flow patterns. It is subjet to ongoing development whih ontinues to broaden the range of patterns that it implements (not only from the ontrol-flow perspetive, but also for the data, resoure and exeption perspetives as well) and also to provide a vehile whih demonstrates how speifi patterns might be realized and utilized in pratie. 86

87 Aknowledgements We would like to thank David Edmond, Marlon Dumas, Petia Wohed, Boudewijn van Dongen and the members of the BPM Group at QUT and the BETA Researh Centre at TU/e for their useful omments that have helped to improve this paper. We also thank the vendors and onsultants that assisted in reviewing the results and provided some valuable feedbak. Dislaimer We, the authors and the assoiated institutions, assume no legal liability or responsibility for the auray and ompleteness of any produt-speifi information ontained in this paper. However, we have made all possible efforts to make sure that the results presented are, to the best of our knowledge, up-to-date and orret. 87

88 Referenes [AIS77] C. Alexander, S. Ishikawa, and M. Silverstein. A Pattern Language: Towns, Buildings, Constrution. Oxford University Press, New York, [BDtH05] A. Barros, M. Dumas, and A.H.M. ter Hofstede. Servie interation patterns. In W.M P. van der Aalst, B. Benatallah, F. Casati, and F. Curbera, editors, Proeedings of the 3rd International Conferene on Business Proess Management (BPM 2005), pages , Nany, Frane, Springer Verlag. [BMR + 96] [DtH01] [EP00] [Fow96] F. Bushmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Arhiteture: A System of Patterns Volume 1. Wiley, Chihester, M. Dumas and A.H.M. ter Hofstede. UML ativity diagrams as a workflow speifiation language. In M. Gogolla and C. Kobryn, editors, Proeedings of the Fourth International Conferene on the Unified Modeling Language (UML 2001), volume 2185 of Leture Notes in Computer Siene, pages 76 90, Toronto, Canada, Springer. H.E. Eriksson and M. Penker. Business Modeling with UML. OMG Press, New York, M. Fowler. Analysis Patterns : Reusable Objet Models. Addison- Wesley, Boston, [GHJV95] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Objet-Oriented Software. Addison- Wesley, Boston, USA, [Hay95] D.C. Hay. Data Model Patterns, Conventions of Thought. Dorset House, New York, [HW04] [JB96] [Jen97] G. Hohpe and B. Woolf. Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions. Addison-Wesley, Boston, S. Jablonski and C. Bussler. Workflow Management: Modeling Conepts, Arhiteture and Implementation. Thomson Computer Press, London, UK, K. Jensen. Coloured Petri Nets. Basi Conepts, Analysis Methods and Pratial Use. Volume 1, Basi Conepts. Monographs in Theoretial Computer Siene. Springer-Verlag, Berlin, [Kie03] B. Kiepuszewski. Expressiveness and Suitability of Languages for Control Flow Modelling in Workflows. PhD thesis, Queensland University of Tehnology, [Kin06] E. Kindler. On the semantis of EPCs: Resolving the viious irle. Data and Knowledge Engineering, 56(1):23 40,

89 [KtHB00] [KtHvdA03] B. Kiepuszewski, A.H.M. ter Hofstede, and C. Bussler. On strutured workflow modelling. In B. Wangler and L. Bergman, editors, Proeedings of the 12th International Conferene on Advaned Information Systems Engineering CAiSE 2000, volume 1789 of Leture Notes in Computer Siene, Stokholm, Sweden, Springer. B. Kiepuszewski, A.H.M. ter Hofstede, and W.M.P. van der Aalst. Fundamentals of ontrol flow in workflows. Ata Informatia, 39(3): , [MvdAtHR06] N. Mulyar, W.M.P. van der Aalst, A.H.M. ter Hofstede, and N. Russell. A ritial analysis of the 20 lassial workflow ontrol-flow patterns. Tehnial report, BPM Center Report BPM-06-18, [OvdADtH06] C. Ouyang, W.M.P. van der Aalst, M. Dumas, and A.H.M. ter Hofstede. Translating BPMN to BPEL. Tehnial report, BPM Center Report BPM-06-02, [Rit99] P. Rittgen. Objet-oriented analysis using event-driven method hains. In Proeedings of the MobIS-Fahtagung 1999, volume 6 of Rundbrief der GI-Fahgruppe 5.10, (in German), pages 8 23, Bamberg, Germany, [RtHEvdA05] [RvdAtH06] [RvdAtHE05] N. Russell, A.H.M. ter Hofstede, D. Edmond, and W.M.P. van der Aalst. Workflow data patterns: Identifiation, representation and tool support. In L. Delambre, C. Kop, H.C. Mayr, J. Mylopoulos, and O. Pastor, editors, Proeedings of the 24th International Conferene on Coneptual Modeling (ER 2005), volume 3716 of Leture Notes in Computer Siene, pages , Klagenfurt, Austria, Springer. N. Russell, W.M.P van der Aalst, and A.H.M. ter Hofstede. Workflow exeption patterns. In E. Dubois and K. Pohl, editors, Proeedings of the 18th International Conferene on Advaned Information Systems Engineering (CAiSE 06), volume 4001 of Leture Notes in Computer Siene, pages , Luxembourg, Luxembourg, Springer. N. Russell, W.M.P. van der Aalst, A.H.M. ter Hofstede, and D. Edmond. Workflow resoure patterns: Identifiation, representation and tool support. In O. Pastor and J. Falao é Cunha, editors, Proeedings of the 17th Conferene on Advaned Information Systems Engineering (CAiSE 05), volume 3520 of Leture Notes in Computer Siene, pages , Porto, Portugal, Springer. [RvdAtHW06] N. Russell, W.M.P van der Aalst, A.H.M. ter Hofstede, and P. Wohed. On the suitability of UML 2.0 ativity diagrams for business proess modelling. In M. Stumptner, S. Hartmann, and Y. Kiyoki, editors, Proeedings of the Third Asia-Paifi Conferene on Coneptual Modelling (APCCM2006), volume 53 of CRPIT, pages , Hobart, Australia, ACS. 89

90 [SSRB00] D. Shmidt, M. Stal, H. Rohnert, and F. Bushmann. Pattern Oriented-Software Arhiteture: Patterns for Conurrent and Networked Objets Volume 2. Wiley, Chihester, [vda01] [vdabthk00] [vdadk02] [vdath05] [vdathkb03] W.M.P. van der Aalst. Exterminating the dynami hange bug: A onrete approah to support workflow hange. Information Systems Frontiers, 3(3): , W.M.P. van der Aalst, A.P. Barros, A.H.M. ter Hofstede, and B. Kiepuszewski. Advaned workflow patterns. In O. Etzion and P. Sheuermann, editors, Proeedings of the Fifth IFCIS International Conferene on Cooperative Information Systems (CoopIS 2000), volume 1901 of Leture Notes in Computer Siene, pages 18 29, Eilat, Israel, Springer. W.M.P van der Aalst, J. Desel, and E. Kindler. On the semantis of EPCs: A viious irle. In M. Rump and F.J. Nuttgens, editors, Proeedings of the EPK 2002: Business Proess Management using EPCs, pages 71 80, Trier, Germany, Gesellshaft fur Informatik. W.M.P. van der Aalst and A.H.M. ter Hofstede. YAWL: Yet another workflow language. Information Systems, 30(4): , W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros. Workflow patterns. Distributed and Parallel Databases, 14(3):5 51, [WEvdAtH05] M.T. Wynn, D. Edmond, W.M.P. van der Aalst, and A.H.M. ter Hofstede. Ahieving a general, formal and deidable approah to the OR-join in workflow using Reset nets. In G. Ciardo and P. Darondeau, editors, Proeedings of the 26th International Conferene on Appliation and Theory of Petri nets and Other Models of Conurreny (Petri Nets 2005), volume 3536 of Leture Notes in Computer Siene, pages , Miami, USA, Springer-Verlag. [Whi04] S. White. Proess modeling notations and workflow patterns. In L. Fisher, editor, Workflow Handbook 2004, pages Future Strategies In., Lighthouse Point, FL, USA., [Wor99] Workflow Management Coalition. Terminology and glossary. Tehnial Report Doument Number WFMC-TC-1011, Issue 3.0, term glossary v3.pdf. [WPDtH03] P. Wohed, E. Perjons, M. Dumas, and A.H.M. ter Hofstede. Pattern based analysis of EAI languages - the ase of the business modeling language. In O. Camp and M. Piattini, editors, Proeedings of the 5th International Conferene on Enterprise Information Systems (ICEIS 2003), volume 3, pages , Angers, Frane, Esola Superior de Tenologia do Instituto Politenio de Setubal. 90

91 [WvdAD + 05a] P. Wohed, W.M.P. van der Aalst, M. Dumas, A.H.M. ter Hofstede, and N. Russell. Pattern-based analysis of BPMN - an extensive evaluation of the ontrol-flow, the data and the resoure perspetives. Tehnial Report BPM Center Report BPM-05-26, BPMenter.org, [WvdAD + 05b] P. Wohed, W.M.P. van der Aalst, M. Dumas, A.H.M. ter Hofstede, and N. Russell. Pattern-based analysis of UML ativity diagrams. In L. Delambre, C. Kop, H.C. Mayr, J. Mylopoulos, and O. Pastor, editors, Proeedings of the 25th International Conferene on Coneptual Modeling (ER 2005), volume 3716 of Leture Notes in Computer Siene, pages 63 78, Klagenfurt, Austria, Springer. [WvdADtH03] P. Wohed, W.M.P. van der Aalst, M. Dumas, and A.H.M. ter Hofstede. Analysis of web servies omposition languages: The ase of BPEL4WS. In I.Y. Song, S.W. Liddle, T.W. Ling, and P. Sheuermann, editors, Proeedings of the 22nd International Conferene on Coneptual Modeling (ER 2003), volume 2813 of Leture Notes in Computer Siene, pages , Chiago, IL, USA, Springer. 91

92 A Staffware This evaluation is based on Staffware Proess Suite 10. Pattern Sore Motivation 1 (seq) + Diretly supported by ars (drawn as lines from left to right) onneting steps. 2 (par-spl) + Supported through a step onstrut that has multiple outgoing ars. 3 (synh) + Supported through the wait step onstrut. Note that the wait step has one preeding step (solid line) and possibly multiple steps it is waiting for (dashed lines). The differene between the preeding step and the steps it is waiting for beomes only visible in a loop situation. In a loop the wait step only waits for the preeding step (solid line) and no longer has to wait for the other steps. The only way to get a normal synhronization is a loop is to expliitly reset the step in a loop using the SETSETSTATUS funtion. 4 (ex-h) + Supported through the ondition onstrut modeling a binary deision. The deision is evaluated using a Boolean funtion and has only one or two outgoing ars. 5 (simple-m) + Supported through a step onstrut that has multiple input ars. Also a router an be used to model suh a join. Note that Staffware only merges flows that are safe, i.e., if multiple triggers arrive at a step, only one trigger is retained. 6 (m-hoie) Not supported. The ondition onstrut an only model a binary deision. 7 (s-syn-m) Not supported. The wait step synhronizes flows and all other steps get enabled after reeiving the first trigger. 8 (multi-m) Not supported. It is not possible to trigger a step twie. Where this ours, the seond thread anels the first. 9 (s-dis) Not supported (see above). 10 (arb-) + In general, unstrutured loops are supported although there are some syntatial limitations. 11 (impl-t) + Diretly supported. A workflow ase terminates if all of its branhes have terminated. A stop symbol an be used to indiate the end of eah branh. 92

93 Pattern Sore Motivation 12 (mi-no-s) + Staffware supports stati and dynami subproedure steps. The stati subproedure step is simply a step orresponding to a subproess. When Staffware proesses a dynami sub-proedure step, it looks at the array field that has been defined for the subproedures to start. This array field may ontain no data (i.e. no sub-proedures need to be started) or multiple data elements (i.e. multiple sub-proedures need to be started) onurrently. 13 (mi-dt) + Supported using the dynami subproedure step. 14 (mi-rt) + Supported using the dynami subproedure step. 15 (mi-no) Not supported. The number of instanes is based on the array values at the moment the step is exeuted and annot be hanged later. 16 (def-) Not supported. No state support in the proess model. Although there is a workaround based on a parallel split and withdraw ations, it is not safe. 17 (int-par) Not supported. There is no way to interleave steps without speifying an order. 18 (milest) Not supported. There is no notion of state. 19 (an-a) + Supported through the withdraw onstrut, i.e., a line entering a step from above. 20 (an-) Not diretly supported, steps an be alled via API alls. 21 (str-l) Not supported. Loops an only be reated in the graphial editor. 22 (reur) + Using the dynami subproedure step it is possible to all any proedure. However, it is unlear whether this is inadvertant rather than intended behavior (i.e. a bakdoor). 23 (t-trig) + The event step onstrut allows external signals to trigger steps, ases and also to resume suspended steps. 24 (p-trig) Not supported. However, by adding a dummy step, a transient trigger an be made persistent. 25 (an-r) Not supported. Although steps an be withdrawn (providing they have not already ommened), it is not possible to speify a region, i.e., a withdraw for eah individual step is required and ompliations may our in regard to routing elements (e.g., wait steps). 26 (an-mi) + It is possible to withdraw subproedure steps. However, in this ase the sub-proedure is terminated prematurely without transferring any data bak. 27 (omp-mi) Not supported. 93

94 Pattern Sore Motivation 28 (b-dis) Not supported. As indiated above only the XOR-join and AND-join are possible using normal steps and wait steps respetively. 29 (-dis) Not supported (see above). 30 (s-pjoin) Not supported. 31 (b-pjoin) Not supported. 32 (-pjoin) Although simple versions of this pattern (e.g. 1-out-of- 2 join) an onstruted using withdrawn ations, the solution is not safe and does not sale up well to more omplex joins. 33 (g-and-join) Not supported. Although join onstruts require triggering on all branhes, subsequent triggers reeived on branhes before the join has ompleted are lost. 34 (st-pjoin-mi) Not supported. The dynami subproedure is speified using an array. It is only stopped after a failure or a withdraw of the omplete subproedure. There is no way to pass on ontrol earlier. 35 (-pjoin-mi) Not supported. 36 (dyn-pjoin-mi) Not supported. 37 (a-syn-m) Not supported. The onept of a step waiting for all preeding ativities to finish when they are optional is not possible in any form. 38 (g-syn-m) Not supported. 39 (rit-se) Not supported. Sine Staffware always immediately shedules subsequent ativities, there is no way of temporarily bloking them. Note that withdrawing a step does not solve the problem. 40 (int-rout) Not supported. The only way to model this is to enumerate sequenes and expliitly selet paths through onditions. 41 (tm) No support for user-speified thread merging. The system automatially merges distint ontrol threads whih reah the same step in a proess instane. 42 (ts) No support for user-speified thread merging. The system automatially merges distint ontrol threads whih reah the same step in a proess instane. 43 (exp-t) Not supported. A workflow ase terminates when all of its branhes have terminated. 94

95 B WebSphere MQ This evaluation is based on WebSphere MQ Workflow 3.4. Pattern Sore Motivation 1 (seq) + Diretly supported by ars onneting proess, program and blok ativities. 2 (par-spl) + Supported through multiple outgoing ars from an ativity. 3 (synh) + Supported by speifying start onditions on an ativity. 4 (ex-h) + Supported through the use of exlusive onditions on transitions. 5 (simple-m) + Supported by speifying start onditions on an ativity. 6 (m-hoie) + Supported through the use of (non-exlusive) onditions on transitions. 7 (s-syn-m) + Supported by speifying start onditions on an ativity. 8 (multi-m) Not supported. An ativity an only be triggered one, either when one or all of the inoming onnetors evaluate to true. 9 (s-dis) Not supported. The evaluation of start onditions for an ativity only ours when all preeding ativities have ompleted. 10 (arb-) Not supported. Proess models are blok-strutured. 11 (impl-t) + Diretly supported. 12 (mi-no-s) Although it is possible to to repliate an ativity by inluding it in a blok ativity with an exit ondition that is satisfied when all instanes have ompleted, it is not possible for these instanes to run onurrently. 13 (mi-dt) Not supported. No onstrut for of designating multiple instanes of an ativity in the design-time model. 14 (mi-rt) Not supported. No means of failitating multiple instanes of an ativity at runtime. 15 (mi-no) Not supported. No means of failitating multiple instanes of an ativity at runtime. 16 (def-) Not supported. There is no means of seleting that one out of a set of possible ativities be exeuted (and the other ativities be withdrawn). 17 (int-par) Not supported. There is no way to interleave ativities without speifying an order. 18 (milest) Not supported. There is no inherent notion of state. 19 (an-a) Not supported. There is no means of denoting ativity anellation with a proess model. 20 (an-) Not supported. There is no means of anelling an entire proess instane. 95

96 Pattern Sore Motivation 21 (str-l) + Post-tested loops are supported by the blok onstrut. 22 (reur) + Diretly supported. Reursive definition of proess and blok ativities is possible. 23 (t-trig) Not supported. There is no means of triggering an ativity from outside the proess instane. 24 (p-trig) Not supported. There is no means of triggering an ativity from outside the proess instane. 25 (an-r) Not supported. A set of ativities annot be anelled. 26 (an-mi) Not supported. There is no diret support for multiple instane ativities. 27 (omp-mi) Not supported. There is no diret support for multiple instane ativities. 28 (b-dis) Not supported. The evaluation of start onditions for an ativity only ours when all preeding ativities have ompleted. 29 (-dis) Not supported. There is no support for the disriminator pattern or any ability to anel a set of (preeding) ativities. 30 (s-pjoin) Not supported. There is no diret support for multiple instane ativities. 31 (b-pjoin) Not supported. There is no diret support for multiple instane ativities. 32 (-pjoin) Not supported. There is no diret support for multiple instane ativities. 33 (g-and-join) Not supported. Proess models are inherently blok strutured and an ativity annot reeive multiple threads of ontrol from the same inoming branh. 34 (st-pjoin-mi) Not supported. There is no diret support for multiple instane ativities. 35 (-pjoin-mi) Not supported. There is no diret support for multiple instane ativities. 36 (dyn-pjoin-mi) Not supported. There is no diret support for multiple instane ativities. 37 (a-syn-m) + Supported through the use of dead path elimination where true and false tokens are passed down branhes that are and are not enabled respetively. This allow the OR-join to determine when it should fire. 38 (g-syn-m) Not supported. No ability to determine when an ORjoin should fire based on an overall assessment of the state of a proess instane. 39 (rit-se) Not supported. Subsequent ativities are sheduled immediately thus removing any potential for restriting onurrent exeution of ativities. 96

97 Pattern Sore Motivation 40 (int-rout) Not supported. There is no way to interleave ativities without atually enumerating all possible exeution sequenes within the proess model and seleting one of them at runtime. 41 (tm) No support. Proess models are blok strutured and safe. 42 (ts) No support. Proess models are blok strutured and safe. 43 (exp-t) Not supported. Proess instanes terminate when there is no remaining work. 97

98 C FLOWer This evaluation is based on FLOWer Pattern Sore Motivation 1 (seq) + Supported through ars onneting plan elements. 2 (par-spl) + Nodes in stati, dynami and sequential subplans have an AND-split semantis. 3 (synh) + Nodes in stati, dynami and sequential subplans have an AND-join semantis. 4 (ex-h) + Supported through the plan type system deision (based on data) and the plan type user deision (based on a user seletion on the wavefront). Moreover, is is possible to speify guards on the ars in the stati, dynami and sequential subplans. When a guard evaluates to true the subsequent ativity is enabled otherwise it is skipped (status refused ). 5 (simple-m) + Supported by the end nodes of the plan type system deision and the plan type user deision. Multiple inoming ars in stati, dynami and sequential subplans an be used to merge flows. 6 (m-hoie) + Supported by guards on ars in stati, dynami and sequential subplans. 7 (s-syn-m) + Supported inside stati, dynami and sequential subplans. Eah plan model is a direted ayli graph of nodes representing various plan elements and ations. Nodes with multiple inoming ars wait for their predeessors to be ompleted or skipped (alled refused ). If all preeding nodes are skipped or all inoming ars have a guard evaluating to false, a node is skipped. Otherwise normal proessing is resumed. Note that the approah is similar to passing true and false tokens. True tokens orrespond to ars that evaluate to true and get triggered by ompleted nodes. False tokens orrespond to ars that evaluate to false or ars that are skipped (i.e., the preeding node is refused ). The join semantis is that if a node has at least one true token as input it beomes enabled. If all input tokens are false it is skipped (i.e., labeled as refused ). 8 (multi-m) +/ It is possible to have multiple onurrent threads using dynami subplans. Therefore, there is partial support for the pattern. However, sine plans are highly strutured, it is not possible to have an AND-split/XORjoin type of situation, i.e., the models are essentially safe (1-bounded). 98

99 Pattern Sore Motivation 9 (s-dis) Not supported. Dynami subplans an have an auto omplete ondition however this is only evaluated when all subplans have ompleted. 10 (arb-) Not supported. In fat there are no loops and the language is blok strutured. Eah plan model is a direted ayli graph of nodes representing various plan elements and ations. Iteration is ahieved through the sequential subplan or the redo role. 11 (impl-t) + Supported, plans an have multiple end nodes. Only if all are ompleted (or refused), the plan is ompleted. 12 (mi-no-s) + Diretly supported through dynami subplans. The dynami subplan an be put into another plan suh that subsequent plan elements do not have to wait for the ompletion of the plan. 13 (mi-dt) + Diretly supported through dynami subplans. For a dynami plan, the minimum and maximum number of instanes an be seleted and the atual number of instanes may be based on some expression. This expression an be a onstant, thus realizing the pattern. Multiple instane data an be passed and aessed through a so-alled dynami array. 14 (mi-rt) + Diretly supported through dynami subplans. One an speify a variable number of instanes (see above). 15 (mi-no) + Diretly supported through dynami subplans. It is possible to reate new instanes during exeution. There is a setting User may reate instanes. 99

100 Pattern Sore Motivation 16 (def-) + Although there is no expliit notion of state, there are different ways of realizing this pattern: (1) The plan type user deision (based on user seletion on the wavefront) an make the impliit hoie in some ases. (2) The plan type system deision an make the impliit hoie in other ases. Note that a system deision bloks until at least one of its onditions is true. As a onsequene, rae onditions based on time or external triggers are possible. In the latter ase, triggering is handled through data-dependenies rather than expliit ontrol-flow dependenies. (3) Yet another way to use a speifi type of deferred hoie is by using guards on ars in a plan model (i.e., inside a stati, dynami or sequential plan) that evaluate to NIL. In this ase proessing stops until the guard evaluates to true of false. A guard evaluates to NIL if e.g. it ontains an undefined variable. Moreover, using the operator HasValue this an be exploited. This way a deferred hoie may be implemented via data. Note that data an be set from outside the proess (e.g., based on a trigger). 17 (int-par) +/ Due to the ase metaphor there is only one ator working on the ase. Therefore, there is no true onurreny and any parallel routing is interleaved. Sine true onurreny is not possible, a partial support rating is given. 18 (milest) +/ There is no diret support for milestones sine there is no notion of state. However, in all situations, data dependenies an be used to emulate the onstrut. Simply introdue a data element (i.e., plae in Petrinet terms) for eah state for whih a milestone needs to be speified. 19 (an-a) +/ It is possible to skip or redo ativities. However, it is not possible to withdraw an ativity in one branh triggered by an ativity in another branh. Skip and redo are expliit user ations. Therefore, they provide only partial support. 20 (an-) +/ It is possible to skip or redo an entire plan. However, skip and redo ations are always expliit user ations. Therefore, they provide only partial support. Note that by defining a data element named anel and using this data element as a preondition for every ativity in the flow it is possible to blok a ase. Although this is an elegant solution, it is still onsidered to be indiret. 100

101 Pattern Sore Motivation 21 (str-l) + Iteration an be ahieved through the use of the sequential plan onstrut. 22 (reur) Not supported. 23 (t-trig) Triggers an be modeled by setting data elements. There are various ways to wait for data, e.g., using guards on ars or mandatory data elements of a milestone. The data elements an be onsidered as persistent. To model transient triggers one needs to reset the data value shortly after it has been set. 24 (p-trig) + Triggers an be modeled by setting data elements. There are various ways to wait for data, e.g., using guards on ars or mandatory data elements of a milestone. This naturally orresponds to persistent triggers. 25 (an-r) Not supported. There is no integrated means of anelling a group of plans or plan elements. 26 (an-mi) No diret means of anelling a dynami subplan without triggering the next ativity. 27 (omp-mi) +/ A dynami subplan an have an auto-omplete ondition an be speified for the subplan based on a variety of onditions however it only ompletes when all instanes have ompleted. The use of deadlines on a dynami subplan results in both the remaining instanes and all subsequent ativities in the proess instane being fore ompleted when the deadline is reahed. 28 (b-dis) Not supported. Note that the auto omplete ondition of a dynami subplan annot be used to ontinue proessing at a higher level while bloking the dynami subplan until all instanes omplete. 29 (-dis) Not supported. Dynami subplans an have an auto omplete ondition however this is only evaluated when all subplans have ompleted. 30 (s-pjoin) Not supported. Dynami subplans an have an auto omplete ondition however this is only evaluated when all subplans have ompleted. 31 (b-pjoin) Not supported (see above: the remaining subplan ativities are fored to omplete). 32 (-pjoin) Not supported. Dynami subplans an have an auto omplete ondition however this is only evaluated when all subplans have ompleted. 33 (g-and-join) Not supported. Note that FLOWer models are safe (1-bounded). 34 (st-pjoin-mi) Not supported. Dynami subplans an have an auto omplete ondition however this is only evaluated when all subplans have ompleted. 101

102 Pattern Sore Motivation 35 (-pjoin-mi) Not supported. Dynami subplans an have an auto omplete ondition however this is only evaluated when all subplans have ompleted. 36 (dyn-pjoin-mi) - Not supported. Dynami subplans an have an auto omplete ondition however this is only evaluated when all subplans have ompleted. 37 (a-syn-m) + Supported inside the stati, dynami and sequential subplans. Eah plan model is a direted ayli graph of nodes representing various plan elements and ations. Nodes with multiple inoming ars wait for the predeessors to be ompleted or skipped (alled refused ). If all preeding nodes are skipped or all inoming ars have a guard evaluating to false, a node is skipped. Otherwise normal proessing is resumed. 38 (g-syn-m) Not supported beause eah plan model need to orrespond to an ayli graph. 39 (rit-se) +/ Not diretly supported. However, data elements an ats as semaphores. There are no onurreny problems beause of the write-lok on ases. 40 (int-rout) +/ As for Interleaved Parallel Routing, the ase metaphor allows a user to work on any of its onstituent ativities without regard to their overall sequene. A ase is ompleted when all of its ativities have been ompleted. Although there is no diret means of ensuring that ativities are only undertaken one at a time, the fat that they are all undertaken by the same user obviates any potential for onurreny and ensures that they are interleaved. 41 (tm) Not supported. The ase metaphor prevents any possibility of multiple threads of exeution. 42 (ts) Not supported. The ase metaphor prevents any possibility of multiple threads of exeution. 43 (exp-t) Not supported. Plans omplete when all end nodes have ompleted. 102

103 D COSA This evaluation is based on COSA 5.1. Pattern Sore Motivation 1 (seq) + Diretly supported by ars onneting ativities. 2 (par-spl) + Supported by multiple outgoing ars from an ativity. None of the ars have transition onditions speified. 3 (synh) + Supported by multiple inoming ars to an ativity. None of the ars have transition onditions speified. 4 (ex-h) + Supported by multiple outgoing ars from an ativity. All of the ars have disjoint transition onditions speified. 5 (simple-m) + Supported by multiple inoming ars to a plae. 6 (m-hoie) + Supported by multiple outgoing ars from an ativity. The ars may have (possibly overlapping) transition onditions speified. 7 (s-syn-m) Proesses are not inherently strutured. 8 (multi-m) +/ Only safe Petri net diagrams an be used. 9 (s-dis) The disriminator an be modelled by using true onditions in input ars and extending the network. Unfortunately, the resulting diagram is too omplex. 10 (arb-) + Supported. Any graph struture is allowed. 11 (impl-t) Not supported, expliit termination is needed. 12 (mi-no-s) + COSA has a three level workflow model, i.e., workflow, flow, and ativity. Flows (i.e., workflow instanes) an be grouped in one workflow and share information. This ombined with a trigger mehanism to reate new flows is a possible solution where folders are used to failitate shared aess to ommon data. 13 (mi-dt) There is no means of denoting that an ativity should be exeuted multiple times. 14 (mi-rt) There is no means of denoting that an ativity should be exeuted multiple times. 15 (mi-no) There is no means of denoting that an ativity should be exeuted multiple times. 16 (def-) + Supported by multiple outgoing ars from a plae. 17 (int-par) + Diretly supported through plaes and also an optional setting of the workflow engine. 18 (milest) + Diretly supported through plaes. 19 (an-a) + Supported by removing tokens from input plaes. 20 (an-) Only supported through an API all. 21 (str-l) There is no means of speifying repeated exeution of an ativity or set of ativities. 22 (reur) + Reursive definition of proess models an be ahieved using triggers or the ativ run tool agent. 103

104 Pattern Sore Motivation 23 (t-trig) + Supported through trigger onstrut in synhronous mode. 24 (p-trig) + Supported through trigger onstrut in asynhronous mode. 25 (an-r) +/ Ahievable by speifying a shadow anellation ativity for eah ativity in the anellation region although the overall diagram is likely to be intratable for anything other than simple proess models. 26 (an-mi) Multiple instane ativities are not supported. 26 (omp-mi) Multiple instane ativities are not supported. 28 (b-dis) There is no modelling onstrut that diretly orresponds to this pattern and although the behaviour an be indiretly ahieved, the proess model required to do so is too omplex. 29 (-dis) Similar to WCP-28 (b-dis), no diret support. 30 (s-pjoin) There is no modelling onstrut that diretly orresponds to this pattern and although the behaviour an be indiretly ahieved, the proess model required to do so is too omplex. 31 (b-pjoin) Similar to WCP-30 (s-pjoin), no diret support. 32 (-pjoin) Similar to WCP-30 (s-pjoin), no diret support. 33 (g-and-join) Only safe Petri net diagrams an be used. 34 (st-pjoin-mi) Multiple instane ativities are not supported. 35 (-pjoin-mi) Multiple instane ativities are not supported. 36 (dyn-pjoin-mi) Multiple instane ativities are not supported. 37 (a-syn-m) + The ondition on an input ar to an ativity an speified suh that it will not be onsidered when the join ondition for the ativity is evaluated if the branh to whih it belongs is not live. 38 (g-syn-m) No ability to determine when an OR-join should fire based on a omplete evaluation of the overall state of the proess instane. 39 (rit-se) + Supported through the use of a mutex plae to prevent onurrent aess to the ritial setion. 40 (int-rout) + Supported through the use of a mutex plae to prevent nominated ativities from exeuting onurrently. 41 (tm) No ability to merge threads as the proess is inherently safe. 42 (ts) No ability to merge threads as the proess is inherently safe. 43 (exp-t) + Diretly supported, a proess instane ompletes when an end ativity is reahed. 104

105 E iplanet This evaluation is based on iplanet Integration Server 3.0. Pattern Sore Motivation 1 (seq) + Diretly supported by the use of ativity routers. 2 (par-spl) + Supported by multiple outgoing routers from an ativity. 3 (synh) + Supported by speifying a trigger ondition for an ativity with multiple inoming routers that only fires when all routers are ativated. 4 (ex-h) + Supported by using multiple outgoing routers from an ativity with disjoint router enabling onditions. 5 (simple-m) + Supported by speifying a trigger ondition for an ativity with multiple inoming routers that fires when any inoming router is ativated. 6 (m-hoie) + Supported by multiple outgoing routers from an ativity, eah with speifi (and possibly overlapping) enabling onditions. 7 (s-syn-m) Not supported. Proess models are not neessarily strutured. 8 (multi-m) + Supported by speifying a trigger ondition for an ativity with multiple inoming routers that fires when any inoming router is ativated. 9 (s-dis) + Supported through the use of a ustomised trigger ondition for an ativity that only fires when the first inoming router is ativated. 10 (arb-) + Arbitrary loop strutures are able to be represented. 11 (impl-t) There is a designated last ativity whih auses proess termination. 12 (mi-no-s) + Supported via asynhronous subproess ativities. 13 (mi-dt) Not supported. No means of designating that multiple instanes of an ativity are required. 14 (mi-rt) Not supported. No means of designating that multiple instanes of an ativity are required. 15 (mi-no) Not supported. No means of designating that multiple instanes of an ativity are required. 16 (def-) Not supported. No onept of state. 17 (int-par) There is no way to interleave ativities without atually enumerating all possible exeution sequenes within the proess model and seleting one of them at runtime. 18 (milest) Not supported. No onept of state. 19 (an-a) + Supported via the AbortAtivity method. 20 (an-) Not supported. There is no means of terminating a proess instane. 105

106 Pattern Sore Motivation 21 (str-l) + Supported through the use of proess variables in onjuntion with routers. 22 (reur) + Supported via synhronous subproess ativities. 23 (t-trig) No trigger support. 24 (p-trig) No trigger support. 25 (an-r) No means of anelling a region of a proess model. 26 (an-mi) No support for multiple instane ativities. 27 (omp-mi) No support for multiple instane ativities. 28 (b-dis) Not supported. No ability to blok ativity triggerings. 29 (-dis) Not supported. No ability to anel portions of a proess model. 30 (s-pjoin) + Supported through the use of a ustomised trigger ondition for an ativity that only fires when the Nth inoming router is ativated. 31 (b-pjoin) Not supported. No ability to blok ativity triggerings. 32 (-pjoin) Not supported. No ability to anel portions of a proess model. 33 (g-and-join) Not supported. No ability to buffer ativity triggers. 34 (st-pjoin-mi) No support for multiple instane ativities. 35 (-pjoin-mi) No support for multiple instane ativities. 36 (dyn-pjoin-mi) No support for multiple instane ativities. 37 (a-syn-m) No means of providing information to an OR-join to enable loal determination of when it should fire. 38 (g-syn-m) No ability to assess when an OR-join should fire through analysis of urrent/future state. 39 (rit-se) Not supported. Although ustom router onditions ould be speified that aess a mutex variable to determine when an ativity an proeed, there is no means of managing onurrent aess to the variable. 40 (int-rout) There is no way to interleave ativities without atually enumerating all possible exeution sequenes within the proess model and seleting one of them at runtime. 41 (tm) No ability to oalese threads of ontrol from independent sub-proess ativities. 42 (ts) No ability to oalese threads of ontrol from independent sub-proess ativities. 43 (exp-t) + Diretly supported. There is a designated last ativity whih auses proess termination. 106

107 F SAP Workflow This evaluation is based on SAP Workflow version 4.6. Pattern Sore Motivation 1 (seq) + Diretly supported. In SAP one an onnet ativities using ars, thus reating a sequene. 2 (par-spl) + Diretly supported. SAP allows for strutured parallel proesses, using the fork onstrut one an reate multiple parallel branhes. Sine there has to be a oneto-one orrespondene between splits and joins, some parallel proesses need to be modified to make them strutured. 3 (synh) + Diretly supported via the fork onstrut. However, as indiated before, there has to be a one-to-one orrespondene between split and join. 4 (ex-h) + Diretly supported through three onstruts: (1) the ondition step type, (2) the multiple ondition step type, (3) a hoie diretly following an ativity. The ondition step type an only be used for binary onditions based on a single Boolean expression. The multiple ondition step type an be used to selet from more than two alternatives. There is default branh that is seleted if none of the other branhes an be taken. The hoie diretly following an ativity is similar to the multiple ondition step type but is not shown graphially in the workflow model. As for the parallel split and synhronization onstruts, eah split needs to orrespond to a join, i.e. again only blok strutured models are supported. 5 (simple-m) + Diretly supported as indiated before. However, there has to be a one-to-one orrespondene between splits and joins. 6 (m-hoie) Not supported. Although there are three onstruts to model hoies, it is not possible to selet multiple exits for a hoie (other than the fork). Hene a multihoie requires a ombination of fork and ondition onstruts. 7 (s-syn-m) Not supported for two reasons. First of all, it is not possible to reate optional parallel branhes other than expliitly skipping the branhes that are not seleted. Seond, the join onstrut of a fork is unaware of the number of truly ative branhes. Therefore, any synhronizing merge needs to be rewritten as a mix of forks and onditions. 107

108 Pattern Sore Motivation 8 (multi-m) Not supported beause the blok struture of SAP Workflow fores the model to be safe (in Petri-net terms), i.e. it is not possible to enable or ativate an ativity in parallel with itself. 9 (s-dis) +/ This is supported by the fork onstrut whih allows for the speifiation of the number of branhes that needs to be omplete or some other end ondition, i.e. a fork an start 10 branhes and terminate 9 branhes upon ompletion of the first branh. Note that all remaining branhes are anelled hene this onstrut only ahieves partial support. 10 (arb-) SAP workflow models are inherently blok strutured, i.e. any split orresponds to a join and only strutured loops (while/until loops) are possible using the loop step type. 11 (impl-t) Not supported beause proesses are blok strutured with a single start and end node. 12 (mi-no-s) +/ The pattern is partially supported through data objets and events triggering workflows, i.e. a state hange of an objet may trigger a workflow. By hanging states in a loop it is possible to trigger multiple instanes. Note that the newly reated instanes run in a distint proess instanes that has no relation to the instane of the ativity ativating them. Hene only partial support is given. 13 (mi-dt) + This pattern is supported in two ways: (1) indiretly via the use of loop onstrut together with a ounter variable indiating how many instanes are to be synhronized by the subsequent join and (2) via dynami proessing with a multi-line ontainer element. Based on a multi-line data element (i.e., a table), an ativity or sub-proess is exeuted as many times as there are lines in the multi-line data element (i.e. the number of rows). There is a maximum of 99 instanes. Through this dynami proessing with a multi-line ontainer element dynami support is ahieved. 14 (mi-rt) + Supported diretly via the dynami proessing with a multi-line ontainer element as indiated for the previous pattern. The number of rows is only relevant at the moment of ativation and does not need to be fixed before. 108

109 Pattern Sore Motivation 15 (mi-no) Not supported. The only way to realize this is through the use of loop onstrut together with a ounter variable indiating how many instanes are to be synhronized by the subsequent join. This number an be modified at run-time. However, the designer has to do the book-keeping to link events to ativities. 16 (def-) Not supported. It an only be realized by starting multiple branhes in parallel using the fork onstrut and then ommening eah branh with a wait for event step. One the first event ompletes and the subsequent ativity ompletes, the other branhes an be anelled by setting the required number of omplete branhes to 1 in the join node of the fork. However, when using this approah it is still possible that multiple ativities run in parallel. Clearly, this is not suffiient support for this pattern. 17 (int-par) Not supported, the onept of a state is ompletely missing and there seems no way to influene the fork onstrut to only allow for interleavings (and not true onurreny). 18 (milest) Not supported, beause the onept of a state is ompletely missing. 19 (an-a) + Supported through the use of the proess ontrol step. A proess ontrol step an be onfigured suh that it fores another work item of the same workflow into the status logially deleted, i.e. another ativity is anelled. This ompletes this other work item and subsequent steps of this work item are not exeuted. To indiate the ativity to be anelled, you speify the node number of the orresponding step. 20 (an-) + Also supported through the use of the proess ontrol step. A proess ontrol step an be set to terminate workflow whih fores all work items of the same workflow into the status logially deleted and terminates the urrent proess instane by setting it to status ompleted. If the terminated workflow was a sub-workflow of a superior workflow, the system exeutes the binding between the ontainer of the subworkflow and the ontainer of the superior workflow in aordane with the definition, and ontinues the superior workflow. 109

110 Pattern Sore Motivation 21 (str-l) + This pattern is supported through the loop onstrut. There are two types of loops: (1) the until loop and (2) the while loop. The until loop has a body that is first exeuted. After exeuting the body a Boolean ondition is evaluated. If it evaluates to true, the proess ontinues with the next step. Otherwise, the proess the loopbak body is exeuted and then the proess is repeated from the beginning. The while loop is similar to the until loop, however, the body is always empty. Therefore, the loopbak body is the only part inside the loop and this part is exeuted zero or more times. 22 (reur) + A multistep task (i.e. an ativity that is deomposed into a sub-workflow) ontains a referene to a workflow definition hene a workflow ould be deomposed into itself. 23 (t-trig) + SAP offer a wait for event step that an be used to wait for an event. This step has different settings. The standard mehanism is that events are not queued. There is an event queue but this is just there for performane reasons. 24 (p-trig) + It is possible to use the wait for event step with the setting event via workflow. When waiting for an event via the workflow, the event is initially reeived and temporarily saved by the workflow. One the wait step has been ativated, the event is forwarded to the wait step. 25 (an-r) The proess ontrol step an terminate/anel a speifi ativity of the whole proess instane. It is not possible to anel everything in a region other than by enumerating the region using a sequene of proess ontrol steps. 26 (an-mi) + Via dynami proessing with a multi-line ontainer element it is possible to reate an instane for eah row in a table. The termination of the parent ativity an be passed on to the hild objets. 27 (omp-mi) Not supported. An ativity set to logially deleted is reursively sanned for items that do not yet have the status ompleted. These work items are then also set to the status logially deleted. Hene it is not possible to omplete the multiple instanes still running. 28 (b-dis) The blok strutured nature of SAP workflow does not allow for onurrent exeution treads within the same instane. Hene a disriminator annot be ativated multiple times. 110

111 Pattern Sore Motivation 29 (-dis) + This pattern is supported by the fork onstrut whih allows for the speifiation of the number of branhes that needs to omplete. This an be set 1 one thus resulting in a disriminator. When ompleting the first branh all remaining branhes are anelled. 30 (s-pjoin) +/ SAP workflow only supports strutured workflows. In the ase of the partial join, this is supported by a fork that an start M branhes in parallel and the fork ompletes after the ompletion of the first N branhes. The remaining branhes are anelled hene this onstrut only ahieves partial support. 31 (b-pjoin) Not supported beause of the strutured/safe nature of SAP workflow. 32 (-pjoin) + SAP workflow only supports strutured workflows. In the ase of the partial join, this is supported by a fork that an start M branhes in parallel and the fork ompletes after the ompletion of N of these branhes. The remaining branhes are anelled. 33 (g-and-join) Not supported beause of the strutured/safe nature of SAP workflow. 34 (st-pjoin-mi) Not supported. Via dynami proessing with a multiline ontainer element it is possible to reate an instane for eah row in a table. However, these instanes are supposed to omplete and there is no setting for a threshold value. 35 (st-pjoin-mi-f) Not supported. Via dynami proessing with a multiline ontainer element it is possible to reate an instane for eah row in a table. However, these instanes are supposed to omplete. 36 (dyn-pjoin-mi) Not supported. Note that dynami proessing with a multi-line ontainer element does not allow for dynami hanges of the number of instanes. 37 (a-syn-m) Not supported for two reasons. First of all, it is not possible to reate optional parallel branhes other than expliitly skipping the branhes that are not seleted. Seond, the join onstrut of a fork is unaware of the number of truly ative branhes. Therefore, any synhronizing merge needs to be rewritten as a mix of forks and onditions. 38 (g-syn-m) As indiated above none of the variants of the synhronizing merge are supported. 39 (rit-se) Not supported. There are no mehanisms other than events and anellations to support interations between parallel branhes. 111

112 Pattern Sore Motivation 40 (int-rout) Not supported. There are no mehanisms other than events and anellations to support interations between parallel branhes. 41 (tm) Not supported beause of the strutured/safe nature of SAP workflow. 42 (ts) Not supported beause of the strutured/safe nature of SAP workflow. 43 (expl-t) + Diretly supported. Proesses are blok strutured with a single start and end node. 112

113 G FileNet This evaluation is based on FileNet P8 BPM Suite version 3.5. Pattern Sore Motivation 1 (seq) + Diretly supported by means of steps onneted with unonditional routes. 2 (par-spl) + Diretly supported by a step where all outgoing routes are unonditional. 3 (synh) + Diretly supported by a omponent the inoming routing info of whih is set to olletor step. 4 (ex-h) + Diretly supported by a step with multiple outgoing routes (take route of the first true ondition). Eah of the routes must have a ondition assoiated with it, all defined onditions must be exlusive. If several onditions are satisfied, the first speified in the lexial order is seleted. 5 (simple-m) + Diretly supported by a step (whih is not a olletor step). 6 (m-hoie) + Diretly supported by a step, whih takes routes of all true onditions. Requires struture followed by a olletor step. 7 (s-syn-m) + Diretly supported by a olletor step used a join in the struture. 8 (multi-m) + Diretly supported, workflow waits for all ative steps to finish. 9 (s-dis) Not supported: no means for resetting are available. 10 (arb-) + Diretly supported: allows to speify yles with multiple entry and exit points. 11 (impl-t) + Diretly supported. Allows for multiple end-points, however workflow terminates after all steps have finished. 12 (mi-no-s) + Supported via invoke in the loop. 13 (mi-dt) Not supported. 14 (mi-rt) Not supported. 15 (mi-no) Not supported. 16 (def-) +/ Partially supported. It is possible to withdraw a timer, but not possible to withdraw an ativity. 17 (int-par) Not supported. 113

114 Pattern Sore Motivation 18 (milest) Not supported: although Filenet has a onept of milestone, it refers to the following: To trak the progress of a workflow, the workflow author an define key points (milestones) in the workflow. On the workflow map, a milestone an be plaed either before or after a General step, or after the Launh step. When the running workflow reahes a milestone, an authorspeified message is written to a log file and, depending on its author-speified level (1 to 99), the milestone displays for workflow partiipants, trakers, and the user who launhed the workflow. The Milestones page displays a list of milestones that have been reahed for a workflow. You an only aess this page from the message sent to the workflow originator when the milestone is reahed. 19 (an-a) + Diretly supported via <Terminate Branh> step. 20 (an-) + Diretly supported via <Terminate Proess> step. Furthermore, if none of the onditions ould be satisfied, the workflow terminates. 21 (str-l) + Diretly supported. 22 (reur) Not supported. 23 (t-trig) Not supported. 24 (p-trig) + Diretly supported via <WaitForCondition> and <Reeive> steps. 25 (an-r) Not supported. 26 (an-mi) No inherent support for multiple instane ativities. 27 (an-mi) No inherent support for multiple instane ativities. 28 (b-dis) Not supported. 29 (-dis) Not supported. 30 (s-pjoin) Not supported. 31 (b-pjoin) Not supported. 32 (-pjoin) Not supported. 33 (g-and-join) + Supported by a olletor step. 34 (st-pjoin-mi) Not supported. 35 (-pjoin-mi) Not supported. 36 (dyn-pjoin-mi) Not supported. 37 (a-syn-m) Not supported. 38 (g-syn-m) + Supported by a olletor step. 39 (rit-se) Not supported. 40 (int-rout) Not supported. 41 (tm) Not supported. 42 (ts) Not supported. 43 (exp-t) Not supported. Workflow terminates after all steps have finished. 114

115 H BPEL This evaluation is based on BPEL4WS version 1.1. Pattern Sore Motivation 1 (seq) + Supported by <sequene> or links within the <flow> onstrut. 2 (par-spl) + Supported by <flow> onstrut. 3 (synh) + Supported by <flow> onstrut. 4 (ex-h) + Supported by <swith> or links within the <flow> onstrut. 5 (simple-m) + Supported by <swith> or links within the <flow> onstrut. 6 (m-hoie) + Supported by links within the <flow> onstrut. 7 (s-syn-m) + Supported by links within the <flow> onstrut. 8 (multi-m) Not supported. The language is blok strutured and it is not possible for two threads of exeution to run through the same path in a single proess instane. 9 (s-dis) Not supported. There is no dediated language onstrut and links annot be used in onjuntion with an OR joincondition as the join requires the status of all inoming links to be known before evaluation, not just the identifiation of the first positive link. 10 (arb-) Not supported. The language is blok strutured and annot apture unstrutured yles. 11 (impl-t) + Diretly supported for the <flow> onstrut. For other onstrut, eah branh must be ended with an end event node. 12 (mi-no-s) + Supported by <invoke> statement within <while> loop. 13 (mi-dt) Not supported. No diret means of denoting multiple ativity instanes are required. 14 (mi-rt) Not supported. No diret means of denoting multiple ativity instanes are required. 15 (mi-no) Not supported. No diret means of denoting multiple ativity instanes are required. 16 (def-) + Supported by the <pik> onstrut 17 (int-par) +/ Indiretly supported via serializable sopes but limited to ativities within the same sope. 18 (milest) Indiretly ahievable by using a <pik> onstrut within a <while> loop whih an only be exeuted one but solution is overly omplex. 19 (an-a) + Supported through fault and ompensation handlers. 20 (an-) + Supported by <terminate> onstrut. 21 (str-l) + While loops are diretly supported. 22 (reur) Not supported. Reursive omposition is possible on an external basis using the <invoke> onstrut against web servies but there is no internal support. 115

116 Pattern Sore Motivation 23 (t-trig) Not supported. Messages are durable in form. 24 (p-trig) + Supported by <pik> onstrut waiting on speifi message type. 25 (an-r) +/ No means of anelling arbitrary groups of ativities although ativities within the same sope an be anelled. 26 (an-mi) No support for multiple ativity instanes. 27 (omp-mi) No support for multiple ativity instanes. 28 (b-dis) Not supported. There is no dediated language onstrut and links annot be used in onjuntion with an OR joincondition as the join requires the status of all inoming links to be known before evaluation, not just the identifiation of the first positive link. 29 (-dis) Not supported. As for WCP (s-pjoin) Not supported. Similar to the disriminator, there is no dediated language onstrut and links annot be used in onjuntion with an OR joincondition as the join requires the status of all inoming links to be known before evaluation, not just the identifiation of the first N positive links. 31 (b-pjoin) Not supported. As for WCP (-pjoin) Not supported. As for WCP (g-and-join) Not supported. There is no notion of multiple exeution threads through a single path in a proess instane. 34 (st-pjoin-mi) No support for multiple ativity instanes. 35 (st-pjoin-mi-f) No support for multiple ativity instanes. 36 (dyn-pjoin-mi) No support for multiple ativity instanes. 37 (a-syn-m) + Supported by links within a <flow> onstrut. 38 (g-syn-m) Not supported. Proess models are always blok strutured and OR-joins always operate within a <flow> onstrut. 39 (rit-se) + Supported by serializable sopes. 40 (int-rout) + Supported by serializable sopes. 41 (tm) +/ The orrelation faility for invoked ativities provides the basis for oalesing distint threads of ontrol but programmati extensions are neessary to keep trak of when the merge should our. 42 (ts) +/ Ahievable through the use of the <invoke> onstrut in onjuntion with the orrelation faility but programmati extensions are neessary if subsequent thread merges are required. 43 (exp-t) Proess instanes omplete when no ativity instanes remain to omplete. 116

117 I WebSphere BPEL This evaluation is based on WebSphere Integration Developer v6.0, whih is the development environment for the Business Proess Choreographer (BPC) part of WebSphere Proess Server v Throughout this doument, we informally refer to this offering as WebSphere BPEL. Pattern Sore Motivation 1 (seq) + Supported by the <sequene> ativity. 2 (par-spl) + Supported by the <flow> ativity. 3 (synh) + Supported by the <flow> ativity. 4 (ex-h) + Supported by the <swith> ativity or links within a <flow> ativity. 5 (simple-m) + Supported by the <swith> ativity or links within a <flow> ativity. 6 (m-hoie) + Supported by the <swith> ativity or links within a <flow> ativity. 7 (s-syn-m) + Supported by links within the <flow> ativity. 8 (multi-m) Not supported. The language is blok strutured and it is not possible for two threads of exeution to run through the same path in a single proess instane. 9 (s-dis) Not supported. There is no dediated language onstrut and links annot be used in onjuntion with an OR joincondition as the join requires the status of all inoming links to be known before evaluation, not just the identifiation of the first positive link. 10 (arb-) Not supported. The language is blok strutured and annot apture unstrutured yles. 11 (impl-t) + Diretly supported for the <flow> ativity. For other onstruts, eah branh must be ended with a <terminate> ativity. 12 (mi-no-s) + Supported by the <invoke> ativity within a <while> loop. 13 (mi-dt) Not supported. No diret means of denoting multiple ativity instanes are required. 14 (mi-rt) Not supported. No diret means of denoting multiple ativity instanes are required. 15 (mi-no) Not supported. No diret means of denoting multiple ativity instanes are required. 16 (def-) + Supported by the <pik> ativity. 17 (int-par) +/ Indiretly ahievable via serializable sopes but this limits the ativities to those within the same sope. 18 (milest) Indiretly ahievable by using a <pik> ativity within a <while> loop whih an only be exeuted one but solution is overly omplex. 19 (an-a) + Supported through fault and ompensation handlers. 20 (an-) + Supported by the <terminate> ativity. 117

118 Pattern Sore Motivation 21 (str-l) + While loops are diretly supported. 22 (reur) Not supported. Reursive omposition is possible on an external basis using the <invoke> onstrut against web servies but there is no internal support. 23 (t-trig) Not supported. Messages are durable in form. 24 (p-trig) + Supported by the <pik> ativity waiting on speifi message type. 25 (an-r) +/ No means of anelling arbitrary groups of ativities although ativities within the same sope an be anelled. 26 (an-mi) No support for multiple ativity instanes. 27 (omp-mi) No support for multiple ativity instanes. 28 (b-dis) Not supported. There is no dediated language onstrut and links annot be used in onjuntion with an OR joincondition as the join requires the status of all inoming links to be known before evaluation, not just the identifiation of the first positive link. 29 (-dis) Not supported. As for WCP (s-pjoin) Not supported. Similar to the disriminator, there is no dediated language onstrut and links annot be used in onjuntion with an OR joincondition as the join requires the status of all inoming links to be known before evaluation, not just the identifiation of the first N positive links. 31 (b-pjoin) Not supported. As for WCP (-pjoin) Not supported. As for WCP (g-and-join) Not supported. There is no notion of multiple exeution threads through a single path in a proess instane. 34 (st-pjoin-mi) No support for multiple ativity instanes. 35 (st-pjoin-mi-f) No support for multiple ativity instanes. 36 (dyn-pjoin-mi) No support for multiple ativity instanes. 37 (a-syn-m) + Supported by links within a <flow> onstrut. 38 (g-syn-m) Not supported. Proess models are always blok strutured and OR-joins always operate within a <flow> onstrut. 39 (rit-se) + Supported by serializable sopes. 40 (int-rout) + Supported by serializable sopes. 41 (tm) +/ The orrelation faility for invoked ativities provides the basis for oalesing distint threads of ontrol but programmati extensions are neessary to keep trak of when the merge should our. 42 (ts) +/ Ahievable through the use of the <invoke> onstrut in onjuntion with the orrelation faility but programmati extensions are neessary if subsequent thread merges are required. 118

119 Pattern Sore Motivation 43 (exp-t) Proess instanes omplete when no ativity instanes remain to omplete. 119

120 J Orale BPEL This evaluation is based on Orale BPEL v Pattern Sore Motivation 1 (seq) + Supported by the <sequene> onstrut or links within the <flow> onstrut. 2 (par-spl) + Supported by the <flow> onstrut. 3 (synh) + Supported by the <flow> onstrut. 4 (ex-h) + Supported by the <swith> onstrut or links within a <flow> onstrut. 5 (simple-m) + Supported by the <swith> onstrut or links within a <flow> onstrut. 6 (m-hoie) + Supported by links within a <flow> onstrut. 7 (s-syn-m) + Supported by links within a <flow> onstrut. 8 (multi-m) Not supported. The language is blok strutured and it is not possible for two threads of exeution to run through the same path in a single proess instane. 9 (s-dis) Not supported. There is no dediated language onstrut and links annot be used in onjuntion with an OR joincondition as the join requires the status of all inoming links to be known before evaluation, not just the identifiation of the first positive link. 10 (arb-) Not supported. The language is blok strutured and annot apture unstrutured yles. 11 (impl-t) + Diretly supported for the <flow> onstrut. For other onstruts, eah branh must be ended with a <terminate> onstrut. 12 (mi-no-s) + Supported by the <invoke> onstrut within a <while> loop. 13 (mi-dt) + Supported through the use of the <flown> onstrut whih allows multiple onurrent instanes of an ativity to be reated. 14 (mi-rt) + Supported through the use of the <flown> onstrut whih allows multiple onurrent instanes of an ativity to be reated. 15 (mi-no) Not supported. No diret means of initiating additional instanes of a multiple ativity (e.g. as reated by the <flown> onstrut) is available. 16 (def-) + Supported by the <pik> onstrut. 17 (int-par) Supported by the BPEL spe but not implementable in Orale BPEL. 18 (milest) Indiretly ahievable by using a <pik> ativity within a <while> loop whih an only be exeuted one but solution is overly omplex. 19 (an-a) + Supported by assoiating a fault or ompensation handler with an ativity. 20 (an-) + Supported by the <terminate> ativity. 120

121 Pattern Sore Motivation 21 (str-l) + While loops are diretly supported. 22 (reur) Not supported. Reursive omposition is possible on an external basis using the <invoke> onstrut against web servies but there is no internal support. 23 (t-trig) Not supported. Messages are durable in form. 24 (p-trig) + Supported by the <pik> ativity waiting on speifi message type. 25 (an-r) +/ No means of anelling arbitrary groups of ativities although ativities within the same sope an be anelled. 26 (an-mi) + Supported for multiple ativity instanes in a <flown> onstrut by assoiating it with a fault or ompensation handler. 27 (omp-mi) No support for multiple ativity instanes. 28 (b-dis) Not supported. There is no dediated language onstrut and links annot be used in onjuntion with an OR joincondition as the join requires the status of all inoming links to be known before evaluation, not just the identifiation of the first positive link. 29 (-dis) Not supported. As for WCP (s-pjoin) Not supported. Similar to the disriminator, there is no dediated language onstrut and links annot be used in onjuntion with an OR joincondition as the join requires the status of all inoming links to be known before evaluation, not just the identifiation of the first N positive links. 31 (b-pjoin) Not supported. As for WCP (-pjoin) Not supported. As for WCP (g-and-join) Not supported. There is no notion of multiple exeution threads through a single path in a proess instane. 34 (st-pjoin-mi) No means of. 35 (st-pjoin-mi-f) No support for multiple ativity instanes. 36 (dyn-pjoin-mi) No support for multiple ativity instanes. 37 (a-syn-m) + Supported by links within a <flow> onstrut. 38 (g-syn-m) Not supported. Proess models are always blok strutured and OR-joins always operate within a <flow> ativity. 39 (rit-se) + Supported by serializable sopes. 40 (int-rout) Supported by the BPEL spe but not implementable in Orale BPEL. 41 (tm) +/ The orrelation faility for invoked ativities provides the basis for oalesing distint threads of ontrol but programmati extensions are neessary to keep trak of when the merge should our. 121

122 Pattern Sore Motivation 42 (ts) +/ Ahievable through the use of the <invoke> onstrut in onjuntion with the orrelation faility but programmati extensions are neessary if subsequent thread merges are required. 43 (exp-t) Proess instanes omplete when no ativity instanes remain to omplete. 122

123 K BPMN The evaluation is based on BPMN version 1.0. Pattern Sore Motivation 1 (seq) + Diretly supported by linking ativities with sequene flow ars. 2 (par-spl) + Supported by AND-split gateway. 3 (synh) + Supported by AND-join gateway. 4 (ex-h) + Supported by XOR-split gateway. 5 (simple-m) + Supported by XOR-join gateway. 6 (m-hoie) + Supported in three distint ways: via an impliit split with onditions on the ars, an OR-split or a omplex gateway. 7 (s-syn-m) + Supported through the OR-join gateway. 8 (multi-m) + Supported by XOR-join gateway. 9 (s-dis) +/ Although support for this pattern is referred to in the BPMN 1.0 speifiation, it is unlear how the InomingCondition expression on the COMPLEX-join gateway is speified. 10 (arb-) + Unstrutured repetition an be diretly supported. 11 (impl-t) + Supported by ending every thread with an End Event. When the last token generated by the Start Event is onsumed, the proess instane terminates. 12 (mi-no-s) + Supported via multiple instane task with MI Flow Condition attribute set to none. 13 (mi-dt) + Supported via multiple instane task with MI Flow Condition attribute set to all. 14 (mi-rt) + Supported via multiple instane task with MI Condition attribute set at runtime to the atual number of instanes required. 15 (mi-no) Not supported. There is no means of adding further instanes to a multiple instane task one started. 16 (def-) + Supported via an event-based exlusive gateway followed by either intermediate events using messagebased triggers or reeive tasks. 17 (int-par) Supported for simple tasks via an ad-ho proess but no support for interleaving groups or sequenes of tasks. 18 (milest) Not supported. No support for states. 19 (an-a) + Supported via an error type intermediate event trigger attahed to the boundary of the ativity to be anelled. 20 (an-) + Diretly supported by inluding the entire proess in a transation. Triggering the anel end event assoiated with the transation will effetively terminate all ativities assoiated with a proess instane. 123

124 Pattern Sore Motivation 21 (str-l) + Both while and repeat loops are diretly supported by ativity looping. 22 (reur) Not supported. No means of speifying reursive omposition with a proess model. 23 (t-trig) Not supported. Triggers are supported through durable messages. 24 (p-trig) + Supported through the use of message events. 25 (an-r) +/ Partially supported by enlosing the anellation region in a sub-proess and assoiating an error event with the sub-proess to enable anellation, however the anellation region is restrited to a onneted subgraph of the overall proess model. 26 (an-mi) + Ahievable via a MI task whih has an error type intermediate event trigger at the boundary. When the MI ativity is to be withdrawn, a anel event is triggered to terminate any remaining MI ativities. 27 (omp-mi) Not supported. No means of anelling remaining MI ativity instanes. 28 (b-dis) +/ Although support for this pattern is referred to in the BPMN 1.0 speifiation, it is unlear how the InomingCondition expression on the COMPLEX-join gateway is speified. 29 (-dis) + Supported by inluding the inoming branhes and the OR-join in a subproess that passes ontrol to the following ativity one the first branh has ompleted as well as anelling the remaining ativities in the subproess using an error type intermediate event. 30 (s-pjoin) +/ Although support for this pattern is referred to in the BPMN 1.0 speifiation, it is unlear how the InomingCondition expression on the COMPLEX-join gateway is speified. 31 (b-pjoin) +/ Although support for this pattern is referred to in the BPMN 1.0 speifiation, it is unlear how the InomingCondition expression on the COMPLEX-join gateway is speified. 32 (-pjoin) +/ Although support for this pattern is referred to in the BPMN 1.0 speifiation, it is unlear how the InomingCondition expression on the COMPLEX-join gateway is speified. 33 (g-and-join) + Supported by the AND-join gateway. 124

125 Pattern Sore Motivation 34 (st-pjoin-mi) +/ Notionally supported via multiple instane task with MI Flow Condition attribute set to omplex where ComplexMI FlowCondition is an expression that evaluates to true when exatly M instanes have ompleted and passes on a single token to the following ativity. However, it is unlear exatly how the ComplexMI FlowCondition should be speified. 35 (-pjoin-mi) +/ Notionally ahievable via a MI task (as for WCP-34) whih has an error type intermediate event trigger at the boundary. Immediately after the MI task is an ativity that issues a anel event to terminate any remaining MI ativities. However the same issue arises as for WCP-34 in that it is unlear how the ComplexMI FlowCondition should be speified. 36 (dyn-pjoin-mi) There is no ability to dynamially add instanes to a multiple instane ativity. 37 (a-syn-m) The OR-join gateway assumes it will be used in a strutured ontext. 38 (g-syn-m) Not supported. No means of assessing whether an OR-join gateway should fire based on a omplete state analysis of the proess instane. 39 (rit-se) Not supported. No means of limiting onurrent exeution of a set of ativities. 40 (int-rout) +/ Indiretly supported via an ad-ho proess ontaining all of the ativities to be interleaved with AdHoOrdering set to sequential however it is unlear what the required AdHoCompletionCondition should be to ensure eah ativity is exeuted preisely one. 41 (tm) + Diretly supported by setting the StartQuantity attribute on ativities immediately following the MI ativity. 42 (ts) + Diretly supported by setting the Quantity attribute on the outgoing sequene flow from an ativity. 43 (exp-t) + Supported via a terminate end event. 125

126 L XPDL This evaluation is based on XPDL version 2.0. Pattern Sore Motivation 1 (seq) + Supported by the transition onstrut. 2 (par-spl) + Supported by the AND-split onstrut. 3 (synh) + Supported by the AND-join onstrut. 4 (ex-h) + Supported by the XOR-split onstrut. 5 (simple-m) + Supported by the XOR-join onstrut. 6 (m-hoie) + Supported by the AND-split onstrut together with onditions on the outgoing transitions. 7 (s-syn-m) + Supported by the OR-join onstrut. 8 (multi-m) + Supported by the XOR-join onstrut. 9 (s-dis) +/ Although the COMPLEX-join gateway appears to offer support for this pattern, it is unlear how the InomingCondition expression is speified. 10 (arb-) + Unstrutured repetition an be diretly supported. 11 (impl-t) + Supported by ending every thread with an End Event. When the last token generated by the Start Event is onsumed, the proess instane terminates. 12 (mi-no-s) + Supported by spawning off ativity instanes in a loop. 13 (mi-dt) + Supported by the multi-instane loop onstrut. 14 (mi-rt) + Supported by the multi-instane loop onstrut where MI Ordering = parallel. 15 (mi-no) Not supported. There is no means of adding further instanes to a multi-instane loop one started. 16 (def-) + Supported by the XOREVENT-split onstrut. 17 (int-par) Supported for single ativities (but not sequenes) by grouping them using the AtivitySet onstrut with the AdHo attribute set. 18 (milest) Not supported. No onept of state. 19 (an-a) + Supported via an error type trigger attahed to the boundary of the ativity to be anelled. 20 (an-) + Diretly supported by inluding the entire proess in a transation. Triggering the anel end event assoiated with the transation will effetively terminate all ativities assoiated with a proess instane. 21 (str-l) + Both while and repeat loops are supported for individual ativities and sub-proesses. 22 (reur) Not supported. No means of speifying reursive omposition with a proess model. 23 (t-trig) Not supported. Triggers are supported through durable message events. 24 (p-trig) + Supported via message events. 126

127 Pattern Sore Motivation 25 (an-r) +/ Partially supported by denoting the anellation region as an ativity set in a blok ativity and assoiating an error event with the blok ativity to enable anellation, however the anellation region is restrited to a onneted subgraph of the overall proess model. 26 (an-mi) + Ahievable via a MI task whih has an error type intermediate event trigger at the boundary. When the MI ativity is to be withdrawn, a anel event is triggered to terminate any remaining MI ativities. 27 (omp-mi) Not supported. No means of anelling remaining MI ativity instanes. 28 (b-dis) +/ Although the COMPLEX-join gateway appears to offer support for this pattern, it is unlear how the InomingCondition expression is speified. 29 (-dis) + Supported by inluding the inoming branhes and the OR-join in a subproess that passes ontrol to the following ativity one the first branh has ompleted as well as anelling the remaining ativities in the subproess using an error event. 30 (s-pjoin) +/ Although the COMPLEX-join gateway appears to offer support for this pattern, it is unlear how the InomingCondition expression is speified. 31 (b-pjoin) +/ Although the COMPLEX-join gateway appears to offer support for this pattern, it is unlear how the InomingCondition expression is speified. 32 (-pjoin) +/ Although the COMPLEX-join gateway appears to offer support for this pattern, it is unlear how the InomingCondition expression is speified. 33 (g-and-join) + Supported by the AND-join onstrut. 34 (st-pjoin-mi) +/ Notionally supported via the multi-instane onstrut where the MI Flow Condition attribute is set to omplex and ComplexMI FlowCondition is an expression that evaluates to true when exatly M instanes have ompleted and passes on a single token to the following ativity. However it is unlear how the ComplexMI FlowCondition is atually speified. 35 (-pjoin-mi) +/ Notionally Ahievable via a MI task whih has an error type intermediate event trigger at the boundary. Immediately after the MI ativity is an ativity that issues a anel event to terminate any remaining MI ativities. However as for WCP-34, it is unlear how the ComplexMI FlowCondition is atually speified. 36 (dyn-pjoin-mi) Not supported. There is no means of adding further instanes to a multi-instane task one started. 127

128 Pattern Sore Motivation 37 (a-syn-m) The OR-join gateway assumes it will be used in a strutured ontext. 38 (g-syn-m) Not supported. No means of assessing whether an OR-join gateway should fire based on a omplete state analysis of the proess instane. 39 (rit-se) Not supported. No means of limiting onurrent exeution of a set of ativities. 40 (int-rout) +/ Indiretly supported via an AdHo proess ontaining all of the ativities to be interleaved with AdHoOrdering set to sequential however it is unlear what the required AdHoCompletionCondition should be to ensure eah ativity is exeuted preisely one. 41 (tm) + Diretly supported by setting the StartQuantity attribute on ativities immediately following the MI ativity. 42 (ts) + Diretly supported by setting the Quantity attribute on the outgoing sequene flow from an ativity. 43 (exp-t) + Supported via a terminate end event. 128

129 M UML 2.0 Ativity Diagrams This evaluation is based on UML 2.0 Ativity Diagrams. Pattern Sore Motivation 1 (seq) + Diretly supported by direted ars between nodes. 2 (par-spl) + Supported by the ForkNode onstrut. It may also be represented impliitly by joining an ation or ativity to several subsequent ations or ativities. 3 (synh) + Supported by the JoinNode onstrut. It an also be be impliitly represented. 4 (ex-h) + Supported by the DeisionNode onstrut where the guard onditions on the outgoing edges are exlusive. 5 (simple-m) + Supported by the MergeNode onstrut. 6 (m-hoie) + Supported by the ForkNode onstrut with guard onditions on the outgoing edges. 7 (s-syn-m) Not supported. The speifi onfiguration of the Join- Spe ondition to ahieve this is unlear. 8 (multi-m) + Supported by the MergeNode onstrut. 9 (s-dis) +/ The speifi onfiguration of the JoinSpe ondition to ahieve this is unlear. 10 (arb-) + Unstrutured yles an be aptured in UML 2.0 ADs. 11 (impl-t) + Supported via the FlowFinalNode onstrut. 12 (mi-no-s) + Supported by spawning off new ativity instanes in a loop. 13 (mi-dt) + Supported through the use of the ExpansionRegion onstrut. 14 (mi-rt) + Supported through the use of the ExpansionRegion onstrut. 15 (mi-no) Not supported. No means of adding additional ativity instanes after ommenement. 16 (def-) + Supported through a ForkNode and a set of AeptSignal ations, one preeding eah ation in the hoie. 17 (int-par) Not supported. No notion of state within UML 2.0 ADs. 18 (milest) Not supported. No notion of state within UML 2.0 ADs. 19 (an-a) + Supported by inorporating the ativity in an interruptible region triggered either by a signal or exeution of another ativity. 20 (an-) + Supported by inorporating all of the ativities in the proess in an interruptible region triggered either by a signal or exeution of another ativity. 21 (str-l) + Supported via the LoopNode onstrut. 22 (reur) Not supported. No means of speifying reursive omposition with a proess model. 129

130 Pattern Sore Motivation 23 (t-trig) + Supported using the AeptEventAtion onstrut for signal proessing with expliit enablement. 24 (p-trig) + Supported via signals. 25 (an-r) + Supported by the InterruptibleAtivityRegion onstrut. 26 (an-mi) + Supported by inluding the ativity in an interruptible region. 27 (omp-mi) No means of anelling remaining ativity instanes one a multiple instane ativity has ommened. 28 (b-dis) +/ The speifi onfiguration of the JoinSpe ondition to ahieve this is unlear. 29 (-dis) + Supported by inorporating the inoming branhes to the join in an interruptible region. The join has an outgoing weight of 1 from the interruptible region to the subsequent ativity effetively anelling all other branhes when the first branh reahes the join. 30 (s-pjoin) +/ The speifi onfiguration of the JoinSpe ondition to ahieve this is unlear. 31 (b-pjoin) +/ The speifi onfiguration of the JoinSpe ondition to ahieve this is unlear. 32 (-pjoin) + Supported by inorporating the inoming branhes to the join in an interruptible region. The join has an outgoing weight of N from the interruptible region to the subsequent ativity effetively anelling all other branhes when the Nth branh reahes the join. 33 (g-and-join) Not supported. JoinNode semantis prevent this situation from arising. 34 (st-pjoin-mi) Not supported. A MI ativity an only omplete when all N instanes speified in the ExpansionRegion have ompleted. 35 (-pjoin-mi) Not supported. A MI ativity an only omplete when all N instanes speified in the ExpansionRegion have ompleted. 36 (dyn-pjoin-mi) Not supported. A MI ativity an only omplete when all N instanes speified in the ExpansionRegion have ompleted. 37 (a-syn-m) +/ The speifi onfiguration of the JoinSpe ondition to ahieve this is unlear. 38 (g-syn-m) Not supported. No means of determining when a join should fire based on evaluation of the overall state of the proess instane. 39 (rit-se) Not supported. No means of preventing onurrent exeution of a set of ativities. 40 (int-rout) Not supported. No notion of state within UML 2.0 ADs. 130

131 Pattern Sore Motivation 41 (tm) + Supported by inluding a weighted edge after the MI ativity to any subsequent ativity. 42 (ts) + Supported by linking multiple outgoing ars from an ativity (one for eah exeution thread required) to a MergeNode whih then direts the various initiated threads of ontrol down the same branh. 43 (exp-t) + Supported via the AtivityFinalNode onstrut. 131

132 N EPCs In this evaluation we use the semantis suggested by the ARIS Toolset 6.2 (e.g., the simulator). Pattern Sore Motivation 1 (seq) + Diretly supported, i.e., events an be used to onnet funtions in a sequene. 2 (par-spl) + Supported by the AND-split onnetor. 3 (synh) + Supported by the AND-join onnetor. 4 (ex-h) + Supported by the OR-split onnetor. However, no language is given to desribe the onditions for taking a branh. 5 (simple-m) + Supported by the XOR-join onnetor. 6 (m-hoie) + Supported by the OR-split onnetor. 7 (s-syn-m) + Supported by the OR-join onnetor. However, as desribed in [Kin06], the OR-join onnetor reates a paradox when ombined with loops (i.e. the viious irle ). The desirable semantis would be to wait until no new folder an reah the OR-join. However, one onnetor may depend on the other and vie versa. The ARIS simulator uses a rather odd solution for this dilemma: the OR-join onnetor has a time-out mehanism attahed to it. The join waits for a prespeified time and then onsumes all folders that are there. 8 (multi-m) Not supported. When using an XOR-join onnetor only one inoming folder is expeted. Most papers and books on EPCs state that the XOR-join should blok if multiple folders arrive. However, the ARIS simulator implements this in a slightly different way. If multiple folder arrive at exatly the same time, they are ignored. Otherwise, eah folder is passed on. 9 (s-dis) Not supported as there is no notion of ignoring subsequent folders and then resetting. 10 (arb-) + Diretly supported as there are no limitations on the graph struture. 11 (impl-t) + Diretly supported. Note that there may be many end events and only if no element is enabled for a given instane does the instane terminate. 12 (mi-no-s) This is not supported. There is no expliit notion of instanes and there is no notation for inter-proess onnetions. 13 (mi-dt) Not supported. The only way to realize this is by making opies and putting them in parallel. 14 (mi-rt) Not supported. 15 (mi-no) Not supported. 132

133 Pattern Sore Motivation 16 (def-) Not supported. The split and join onnetors are exeuted when they beome enabled. Therefore, an XORsplit makes an immediate deision and this hoie annot be deferred. 17 (int-par) Not supported. 18 (milest) Not supported. Although EPCs ontain events, it is not possible to hek states and at aordingly. 19 (an-a) Not supported. There is no anellation feature. 20 (an-) Not supported. 21 (str-l) Not supported. There are only arbitrary yles. 22 (reur) Not supported. 23 (t-trig) Not supported. 24 (p-trig) +/ EPCs allow for multiple input events and these ould be interpreted as persistent triggers. However, sine it is not possible to differentiate between the reation of an instanes and subsequent events and there is no implementation of this onept, we rate this as partial support. 25 (an-r) Not supported. There is no anellation feature. 26 (an-mi) Not supported. 27 (omp-mi) Not supported. 28 (b-dis) Not supported. 29 (-dis) Not supported. 30 (s-pjoin) Not supported. 31 (b-pjoin) Not supported. 32 (-pjoin) Not supported. 33 (g-and-join) +/ Most papers and books on EPCs assume that joins blok if multiple folders arrive. However, the ARIS simulator implements this more like in a Petri net. 34 (st-pjoin-mi) Not supported. 35 (-pjoin-mi) Not supported. 36 (dyn-pjoin-mi) Not supported. 37 (a-syn-m) + See pattern 7. The language allows for this. However, we know of no workflow management systems that implement this. Note that the ARIS simulator uses a rather odd solution: the OR-join onnetor has a time-out mehanism attahed to OR-joins, i.e., the join waits for a pre-speified time and then onsumes all folders that are pending. 38 (g-syn-m) See pattern 7. The language allows for this. However, we know of no workflow management systems that implement this. Note that the ARIS simulator uses a rather odd solution: the OR-join onnetor has a time-out mehanism attahed to OR-joins, i.e., the join waits for a pre-speified time and then onsumes all folders that are pending. 133

134 Pattern Sore Motivation 39 (rit-se) Not supported. There is no way to reate a kind of mutual exlusion state. 40 (int-rout) Not supported. 41 (tm) Not supported. It is impossible to merge a speified number of threads into one. 42 (ts) Not supported. It is impossible to merge a speified number of threads into one. 43 (exp-t) Proess instanes omplete only when no remaining element are enabled. 134