Specifying Complex Process Control Aspects in ... - Semantic Scholar

Specifying Complex Process Control Aspects in Work ows for Exception Handling A.H.M. ter Hofstede CIS Research Centre Queensland University of Technology GPO Box 2434 Brisbane Qld 4001, Australia [email protected]

Abstract Contemporary speci cation languages of work ow management systems focus on capturing process execution semantics. Constructs are oered that allow the speci cation of sequential execution, iteration, choice, parallelism and synchronisation. While in work ow modelling it is absolutely imperative that exceptions are dealt with properly, virtually no support for the speci cation of exception handling is oered at the conceptual level. Typically, exceptions and recovery strategies need to be de ned using the programming primitives of the speci c work ow management systems used. In this paper we propose a number of conceptual modelling primitives that can be used for the speci cation of exception handling in work ows. These primitives are illustrated using some real-life examples. A formal semantics is assigned to precisely de ne their meaning and demonstrating how they can be incorporated in a typical process modelling language.

1. Introduction Over the last few years, work ow technology has been maturing in its delivery of business process automation through functions which provide work ow design, scheduling, execution and monitoring. Through constructs which enable process control sequence, choice, iteration, parallelisation and synchronisation, both manual and computerised tasks of business processes can be composed into an execution order such that databases, other sorts of information resources and application functionality are integrated. Since business processing is diverse and complex, improvements to work ow speci cations are inherently

A.P. Barros Distributed Systems Technology Centre The University of Queensland Brisbane Qld 4072, Australia [email protected] on-going. Much of the developments in the expressive power of work ow speci cations have been established mainly through formal reasoning with Petri nets [1, 12], while advanced transaction models [2] have oered insights into the transactionality and, in general, the computation of work ows. However, the suitability of work ow constructs commensurate to business processing semantics, and therefore the validation of work ow models for business requirements, remains an openended issue. One of the relatively recent explorations in work ow research has been the area of exception handling, see e.g. [7, 10]. Exceptions may be described as occurrences which result in the partial or full termination of processing. Examples include customers terminating business services which they previously requested or system crashes. Typically in work ow speci cations, this has been regarded as implementation detail which is captured in the application objects bound to work ow tasks. Through developments in transactional work ows, some provision for work ow recovery such as rollback recovery is now available in some techniques. Of course, exception handling details relate to business requirements and therefore need to be captured at the conceptual level where a clear validation in relation to all other aspects of work ow execution, by stakeholders, is possible. In [8] for instance a conceptual treatment of exception handling is provided through active rule speci cation which detects exceptions and reacts to them. One type of reaction is a compensation which allows task rollback. In this paper, we focus on exception handling within process control structures. In particular, we show how standard triggering, through a technique known as Task Structures, can be used to increase the sophistication of the reactive part of exception handing, thereby

reducing the disparity of work ow speci cations. The concepts we propose are not claimed to be complete, but we will illustrate their relevance in terms of a number of practical examples and show how they can be integrated in a general process control model. One of the strenghts we do claim over current approaches is the applicability to, and promotion of, concurrent work ow execution. As the introduction of such powerful constructs in the face of concurrent work ow execution, particularly the presence of multiple instances of the same type of process and process decompositions, can complicate correct work ow execution, we show how a formal semantics can be assigned for the constructs using a formal language from the Process Algebra family, the Algebra of Communicating Processes (ACP) [4] which has had signi cant applications [3].

2. Essential process control concepts The speci cation of work ows in general is known to be quite complex and many issues are involved. Work ow speci cations should incorporate execution dependencies between tasks, information ow between tasks, access to distributed databases, temporal constraints, exception handling etc. In this paper though, focus is solely on control ow aspects in work ow speci cations. Any conceptual work ow speci cation language should at least be capable of capturing moments of choice, sequential composition, parallel execution, and synchronization. In this section, Task Structures are presented which are capable of modelling these task dependencies. In the next section extensions to Task Structures will then be discussed which allow for the speci cation of exception handling at the conceptual level. Task structures were introduced in [6] to describe and analyze problem solving processes. In [13] they were extended and a formal semantics in terms of Process Algebra was given [4]. In Figure 1, the main concepts of Task Structures are graphically represented. They are discussed subsequently. The central notion in Task Structures is the notion of a task. In a work ow context, tasks are basic work units that collectively achieve a certain goal. A task can be de ned in terms of other tasks, referred to as its subtasks. This decomposition may be performed repeatedly until a desired level of detail has been reached. Tasks with the same name have the same decomposition, e.g. the tasks named B in Figure 1. Performing a task may involve choices between subtasks, decisions represent these moments of choice. Decisions coordi-

decomposition

A task

initial item

B trigger

C

G

non-terminating decision

E

synchroniser

F H

terminating decision

B

Figure 1. Graphical representation of Task Structure concepts

nate the execution of tasks. Two kinds of decisions are distinguished, terminating and non-terminating decisions. A decision that is terminating, may lead to termination of the execution path of that decision. If this execution path is the only active execution path of the supertask, the supertask terminates as well. Triggers, graphically represented as arrows, model sequential order. In Figure 1 the task with name G can start after termination of the top task named B . Initial items are those tasks or decisions, that have to be performed rst as part of the execution of a task that has a decomposition. Due to iterative structures, it may not always be clear which task objects are initial. Therefore, this has to be indicated explicitly. Finally, synchronisers deal with explicit synchronisation. In Figure 1 the task named H can only start when the tasks with names C and G have terminated.

3. Exception handling extensions In this section, we describe informally four extensions to Task Structures which are pertinent to exception handling. 3.1. Aborts

A classical reaction to an exception is an abort of part of a work ow. Tools such as Forte (Forte Software) provide an abort trigger construct which is executed for a task when a particular condition occurs.

The part of the work ow aborted is a task. In practice, a greater part of the wor ow may be needed to be aborted, particularly when several concurrently executing paths may be related to the exception. For example, the validation of an application associated with a business service often requires a number of searches. If their sources are remote or complex, they may be started up in parallel, and if one search yields a particular result, further search processing is not required. For this type of requirement, we extend the aborted part of a work ow to a decomposition, where, when an abort trigger is executed, all execution paths in its decomposition are executed. To complete the speci cation, an abort handler, triggered by the abort, is then executed. To illustrate the application of aborts, consider an example of a home loan service in Figure 2 which is intended for direct customer access via the Web. For brevity the the speci cation for this has been considerably simpli ed from the actual analysis which was conducted for land conveyancing in Queensland1. Home loan

Receive application

Loan application

Finance approved? y

n Finalise application

More checks? n y Loan check

Send check

Loan check response

Receive response

Prepare documentation

Stamp Duty notification

Passed? n

Finalise application

y

Log response

Settlement

Receive payment

Figure 2. Deferred exception handling for home loans using aborts

In the Home Loan decomposition, an initially executing task receives a Loan Application which includes information about the property, the conveyance details and the nancial references of the owners such as pay slips, mortgage repayments and current equity. Based 1 This was conducted in CITEC's Con rm II Value-Added Services project which is intended to provide online services, including those implemented using work ows, on the Web [9].

on this information, a bank determines whether Finance (is) approved?, and if so, proceeds with processing of the application in parallel execution paths. The synchroniser ensures two execution paths initially. One involves performing the conduct of various checks like titles searches, site inspections and owner credit rating. The other involves tasks which will yield nal Settlement where the conveyance information is sent out for Stamp Duty noti cation, the titles are transferred in nal Settlement and the loan fees are paid to the bank. We can see that checks are forked through the cyclic trigger back to More checks?. A check is sent remotely through synchronous messaging, meaning that the source receiving a Loan check should signal the sender of its receipt. A Loan check response is then anticipated which if not Passed?, e.g. the owner's credit rating failed, results in the whole decomposition being aborted (zig-zag) arrow. This means all execution paths, including that leading to Settlement, are terminated. Clearly, the risk of this approach is that Settlement could go ahead while checks are being conducted. Such a strategy, however, is calculated where the bank ascertains con dence in the application in the earlier decision with the understanding that most applications which proceed past this point, do not fail. Another factor is the processing of the checks which progress quite quickly compared with the path to settlement. Other such examples of deferred exception handling include situations where customers are required to con rm acceptance and make payments before further processing can continue. An eciency is introduced by allowing the processing to go ahead on the understanding that customers typically make these provisions, and if the provisions are rejected, processing is aborted. 3.2. Compensations and contingencies

Another part of exception handling which we factor into conceptual work ow speci cations arises from transactional work ow research, particularly that related to failure recovery. While this is often considered an implementation issue, some of these aspects relate to business requirements and should be captured conceptually [7]. Through the adaption of failure recovery, we cater for expected exceptions [11] which require rollback or rollforward of the work ow. Consider rst our adaption of rollback recovery. Through abort triggers, business exceptions are detected and lead to the abort of decomposition, however, all the post-abort processing is contained in the abort handler. By using a processing log, such an abort handler can determine the last task executing in each

execution path, and from there trigger a rollback. A rollback for one of the execution paths in the Home loan task is illustrated in Figure 3. Rollbackward Specification

Rollforward Specification

ROLLBACK? COMPENSATION N

-

Prepare documentation COMMIT

Y

Stamp duty exception notification

Y

Notify parties

Stamp Duty notification

Manual Stamp Duty Delivery

Settlement COMMIT

Y

Payment refund

Receive payment COMMIT

Figure 3. Rollback and rollfoward

Like nested transactions in advanced transaction models, the work ow is partitioned hierarchically into atomic units. In terms of undoing changes, the \longlived" nature of work ows means that committed tasks can be inter-leaved with uncommitted tasks. To rollback committed taks, advanced transaction models use instead compensations. Figure 3 illustrates an execution path and the rollback speci cation which is used to derive the reverse execution (i.e. read the table bottom to top). Note, if a rollback applies, an undo is applied for uncommitted task or a compensation applies for committed tasks. The compensations in the example involve external noti cations. Other types of compensations include logical inverse of database updates or manual tasks. Note also, commit points can extend over more than one task so that an uncommitted grain can be rolled back as a whole. The incorporation of rollforward is relatively straightforward. We apply this for situations of task execution failure, e.g. crashs, where we simply specify a set of contingency tasks which apply to dierent failure consitions of a tasks, which, of course, are executed when the relevant condition, e.g. did not start after ten minutes or did not start after 1 hour, applies. At the implementation level, the WFMS will ensure consistency by performing a physical rollback of the current atomic unit, followed by restart a contingent task. When the contingent task is the same as the task then this is equivalent to a redo. Figure 3 contains a contingency for stamp duty noti cation. 3.3. Exclusive tasks

A variation on aborts is interrupts. As applied in real-time systems, interrupts allow transient, dedicated

processing for particular events after which normal processing continues. Applied to deferred exception handling, what we require is that if an exception arises, then an interrupt, i.e. a task running exclusively, occurs during which other tasks are rendered inactive. The idea of an exclusive task is not novel. Figure 4 shows the processing of data involving a large amount of scanning, speci ed as an exclusive task (double-lined process symbol) so that other tasks do not update the data while the process is running. In other words, an exclusive task allows a whole decomposition's execution to be atomic. Note, exclusive tasks can be nested, i.e. where an exclusive task contains exclusive tasks in its decomposition hierarchy. Print pay-roll

Salary-administration

More employees?

. . .

n y

Print pay-roll Print next employee’s salary

. . .

Figure 4. An exclusive task

Figure 5 extends the checking of the home loan example to allow certain checks which do not pass, to incur to the provision of mortgage insurance rather than outright rejection of the application. Loan check response

Receive response

Passed? y

n Extend risk level? y

Increase mortague insurance level

n

Log response

Finalise application

Figure 5. Deferred exception handling example using interrupts

4. Formal de nition In this section a formal semantics is assigned to work ow structures extended with the concepts for exception handling discussed in the previous section (except for compensations which will not be discussed). This is achieved through the de nition of a mapping

to Process Algebra [4]. Section 4.1 discusses the syntax of work ow structures, section 4.2 discusses some extensions to Process Algebra that facilitate the definition of the formal semantics (the reader is referred to [4] for an in-depth discussion of the basics of Process Algebra), and section 4.3 then formally de nes the mapping. 4.1. Syntax of workflow structures

A work ow structure consists of the following components: 1. A set X of work ow objects. X is the (disjoint) union of a set of synchronisers S , a set of tasks T and a set of decisions D. In D we distinguish a subset Dt consisting of the terminating decisions. In T three subsets are distinguished: the set G of exclusive tasks, the set Z of aborting tasks, and the set Y of contingent tasks. The sets Z and Y are disjoint. 2. A relation Trig  X  X of triggers. 3. A function Name: T ! V yielding the name of a task, where V is a set of names. 4. A partial decomposition function Sup: X V . If Sup(x) = v, this means that work ow object x is part of the decomposition of v. Names in the range of this function are called decomposition names. The set Q  ran(Sup) contains all these names. The complement A  V n Q is the set of atomic actions. 5. A partial function Init  Sup yielding the initial items of a task. 6. A function Abt: Z ! T nY yielding the abort handlers for aborting tasks. These abort handlers are not allowed to be contingent tasks. 7. A function Cont: Y ! TnZ yielding the contingent task for a task possibly requiring a rollforward. Such tasks should not be aborting tasks. Decomposition allows for the modularization of work ow speci cations. Typically, modules should be loosely connected and hence, triggers should not cross decomposition boundaries: x1 Trigx2 ) Sup(x1 ) = Sup(x2 ) This also applies to abort handlers: Abt(z ) = t ) Sup(z ) = Sup(t) and contingent tasks: Cont(y) = t ) Sup(y) = Sup(t)



4.2. Extensions to ACP

In this section some extensions to ACP" are discussed that can be exploited to elegantly express the formal semantics of work ow structures. In [5], Bergstra proposed a mode transfer operator for ACP" . The intuitive meaning of X ! Y is as follows: as long as X has not terminated, be it correct of incorrect termination, it is possible that Y takes over control. The axiomatization is given in table 1.  ! X =  for  2 f";  g (a
X ) ! Y = a
(X ! Y ) + Y (X + Y ) ! Z = (X ! Z ) + (Y ! Z ) Table 1. Mode transfer operator

(M1) (M2) (M3)

Another extension to ACP" concerns aborts. An expression hX i hY i within an abort context  : : :  indicates that X is an aborting process and that Y is its abort handler. All subsequent processes in the abort context need to be ignored. This leads to the axiomatization given in table 2. It should be remarked that hX i hY i should be treated as an atomic action in the context of the normal ACP" axioms. The set of all such expressions is referred to as B .

#

#

" a
X  X + Y   hX i # hY i
Z 

= " = a
 X  if a 2= B = X +Y  = XY

(I1) (I2) (I3) (I4)

Table 2. Aborts

A third and nal extension to ACP" that is needed deals with the atomic execution of complex processes. The expression [X ] expresses that X , which might be a complex process, needs to be executed atomicly, i.e. should not be interleaved with any other processes. For its axiomatization we need to know the monitor context, denoted by : : : that will give us the scope of the monitor, i.e. only processes within this context should not be interleaved with the exclusive process. The axiomatization is given in table 3. In the rest of this paper we refer to ACP" with these extensions as ACPc" .

2 3

4.3. Semantics of workflow structures

In this section work ow structures are provided with a formal semantics by the de nition of a mapping for each work ow structure to a set of ACPc" equations.

2 3 2a
X 3 2X +Y 3 2 [a
Y ]
Z 3

= for 2 f; "g = a
X = X + Y = a
[Y ]
Z [X ]
Y Z = [X ]
(Y k Z ) [X + Y ] = [X ] + [Y ] [a] = a for a 2 A [f; "g [[a
Y ]
Z ] = [a
[Y ]
Z ]

2 3 2 3 2 3 2 3

(O1) (O2) (O3) (O4) (O5) (O6) (O7) (O8)

Table 3. Monitor operator

For each work ow structure object x, a process variable Ex is introduced, which represents the semantics of that object. In addition, as a result of their special behaviour, for each aborting task z a process variable Tz is de ned. The main process variable, representing the semantics of a whole work ow structure, corresponds to the main task t0 and its equation is: Et0 = @H (Name(t0 )) The brackets : : : capture the system context outside of which we know no processing occurs. Encapsulation is needed, as synchronisation is achieved through communication [13]. Every process element x which is to trigger synchroniser s, starts an atomic action x;s after termination. A synchroniser is started when such atomic actions, related to its input process elements, communicate, noting that communication is not necessarily binary since more than two process elements may be input to a synchroniser. The translation for a synchroniser s 2 S is: x;s = Es

2 2 3

3

Trig(x;s)

Hence, the encapsulation set H is de ned by: H = fx;s j s 2 S ^ xTrigsg A synchroniser per se does not do anything other than triggering its ouput work ow objects, hence its corresponding equation is: Es = trigrest(s) The abbreviation trigrest(p) provides the possible triggering paths following the execution of p (irrespective of whether p is a task or a synchroniser). As previously mentioned, the translation of triggering and aborting task elements is distinguished.

trigrest(p) =





x

Ex 2 X n (S [ Z ); Trig(p; x)



p;s



Tz

z

2 Z;

s

2 S;

Trig(p; z) Trig(p; s)

If p does not invoke one of the three possible types of execution paths, the relevant merge will be de ned over the empty set. This exception is dealt with by de ning the merge over the empty set to be the empty action " as this is the neutral element for parallel composition. The translation of a task t, which is not an exclusive task, hence t 2= G , nor a contingent task, hence t 2= Y , is: Et = Name(t)
trigrest(t) This equation states that executing a task is executing the body of the task followed by executing, in parallel, the task objects it triggers. Recall from section 4.1 that the set of atomic actions A is de ned as V n Q, where Q is assumed to be in the set of process variables. To comply with the notational conventions of Process Algebra, we denote the elements of A in lowercase and the elements in Q in uppercase. For names V that have an associated decomposition, i.e. V 2 Q, the corresponding equation states that its execution corresponds to starting all its initial items in parallel. Naturally, the usual distinction between aborting and nonaborting tasks needs to be made, but we also need to add the brackets for the aborting context (it can be proven that their eect is nil if the decomposition of V does not contain any aborting tasks): V

=





Ex



Tx

Init(x) = V Init(x) = V x2 =Z

x2



Z

The corresponding equation for a decision d has to re ect the choice for the possible work ow objects involved: X X X Ed = d;s + Tz + Ex + d dTrigs, s2S

dTrigz , z2Z

dTrigx, x2 = S [Z

where d = " if d 2 Dt (i.e. if d may choose for termination), and d =  otherwise. The translation of an exclusive task g 2 G requires its body to be executed atomicly: Eg = [Name(g )]
trigrest(g )

Example 4.1 In the work ow structure of Figure 6

two tasks are depicted, running in parallel, p1 which is atomic and p2 which has a decomposition and is run exclusively. p2 also runs two tasks in parallel, p3 and p4 . p4 triggers an exclusive task p5 which has a decomposition of p6 triggering p7 . Also p5 triggers p8 . The previous translations applied to the work ow structure yield the following ACPc" equations

M

M N

a p

1

c

b

p

a

p2

b

V p4

d

p3

c

p5

4

p

O

3

d p6

e

p7

p6

p1 p0

e p

5

f

p

8

Figure 7. Aborting processing example p

2

p

0

Figure 6. Exclusive processing example

(omitting abort contexts, as aborts do not play a role): Ep0 Ep1 Ep2 Ep3 Ep4

2 3 3 2

= M = E p1 k E p2 = a = [N ] = [Ep3 k Ep4 ] = b = c
Ep5

E p5 E p6 E p7 E p8

= [O]
Ep8 = [Ep6 ]
Ep8 = d
Ep7 = e = f

The reduction of Ep0 is: Ep0

= = = =

2 a [bc [de] f + c([de] f k b)] 3 + 2 [bc [de] f + c([de] f k b)] a 3 a(2 [bc [de] f ] 3 + c 2 [de] f k b 3) + 2 [bc [de] f ] a 3 + 2 [c([de] f k b)] a 3 a(bc 2 [[de] f ] 3 + c(2 [de] (f b + bf ) 3 + 2 b [de] f 3)) + bc 2 [[de] f ] a 3 + 2 [c([de] (f b + bf ) + b [de] f )] a 3 a(bcdef + c(de(f b + bf ) + bdef )) + bcdef a + c(de(f ba + bf a) + bdef a)

The normalised reduction demonstrates exclusive processing: a occurs either before the actions of N or after, i.e. it is not interleaved with N 's actions. The actions of O are also not interleaved, i.e. e always immediately follows d. 2 An aborting task z 2 Z has a corresponding process variable Tz de ned as follows: Tz

= h Ez i

# EAbt

(z )



Note that every aborting task z also has a corresponding equation for Ez . This process variable is never invoked directly, but only indirectly through Tz as it needs to be treated dierently as far as its continuation is concerned.

Example 4.2 In the work ow structure of Figure 7,

a decomposition V contains two subtasks, p2 and p4 , started in parallel, one of which, p2 , aborts processing, triggering the abort handler p3 in the decomposition. In the translation which follows, we can safely ignore the system context and encapsulation as there are no monitors or synchronizers. The abort context is relevant for V only. Tp2 = hEp2 i hEp3 i Ep0 = M V =  Tp2 k Ep4  M = E p0 Ep2 = a Ep1 = V
Ep6 E p3 = d Ep5 = c Ep4 = b
Ep5 Ep6 = e The abort processing axioms can then be included to reduce the equation for the work ow structure: Ep0 = V
e =  Tp2 k Ep4 
e = hEp2 i hEp3 i k bc 
e = ( hai hdi bc  +  b(c khai hdi) )
e = (ad + b( c hai hdi  + hai hdi c ))
e = ade + b(cade + ade) The resulting expression shows that after executing the abort task p2 the tasks p4 and p5 are not executed anymore. 2 Finally, a contingent task y 2 Y translates to: Ey = (Name(y ) ! ECont(y) )
trigrest(y )

#

# #

#

#

#

Example 4.3 Ep0 Ep1 N Ep3 Ep6

= = = = =

M a
Ep4 E p2 c e
Ep7

M Ep4 Ep2 Ep5 Ep7

= E p1 = (N ! Ep6 )
Ep5 = b
Ep3 = d = f

M

a

p1

b

p2

c

p3 p 4

d

p5

N

e

p

f

p

[2]

6

7

p

0

[3]

Figure 8. Contingent processing example

Rewriting this speci cation yields: Ep0 = a(bc ! ef )d) = a(b(c ! ef ) + ef )d = a(b(c(" ! ef ) + ef ) + ef )d = a(b(c + ef ) + ef )d = a(b(cd + ef d) + ef d) The result shows that after starting task p4 with name N and before its termination, the task sequence ef can take over control. Note that task p5 will be performed in any case. If this is undesirable, then task p6 should be speci ed as aborting.

2

5. Conclusions and further research In this paper, we argued that the speci cation of exception handling in work ows should be supported at the conceptual level. Over and above traditional process control constructs, three extensions were proposed that support exception handling: aborting triggers, compensations and contingencies, and exclusive tasks. Illustrations from an industrial case study showed that such requirements exist in practice despite the shortcomings of existing WFMS products. By combining these advanced work ow constructs with classical work ow constructs it is possible to capture complex but common themes of business processing. To precisely impart the rami cations for work ow execution, we showed how a formal semantics can be assigned. In the short term, we see that it is viable to simulate increasingly complex aspects of business processing. In the longer term, speci c work ow speci cation languages, among others as supported by current work ow tools, can be targeted and augmented with such features. The formal semantics guides such extensions.

References [1] W.M.P. van der Aalst. Veri cation of Work ow Nets. In P. Azema and G. Balbo, editors, Application and

[4] [5] [6] [7] [8]

[9]

[10]

[11]

[12]

[13]

Theory of Petri Nets 1997, volume 1248 of Lecture Notes in Computer Science, pages 407{426, Berlin, Germany, 1997. Springer-Verlag. G. Alonso, D. Agrawal, E. El Abadi, M. Kammath, R. Gunthor, and C. Mohan. Advanced transaction models in work ow concepts. In Proceedings ot the 12th International Conference on Data Engineering, New Orleans, Lousiana, February 1996. J.C.M. Baeten, editor. Applications of Process Algebra. Cambridge University Press, Cambridge, United Kingdom, 1990. J.C.M. Baeten and W.P. Weijland. Process Algebra. Cambridge University Press, Cambridge, United Kingdom, 1990. J.A. Bergstra. A Mode Transfer Operator in Process Algebra. Report P8808b, University of Amsterdam, The Netherlands, 1989. P.W.G. Bots. An Environment to Support Problem Solving. PhD thesis, Delft University of Technology, Delft, The Netherlands, 1989. F. Casati. A Discussion on Approaches to Handling Exceptions in Work ows. In Proceedings of CSCW98 Workshop \Towards Adaptive Work ow Systems", Seattle, Washington, November 1998. F. Casati, S. Ceri, B. Pernici, and G. Pozzi. Conceptual Modeling of Work ows. In M.P. Papazoglou, editor, Proceedings of the OOER'95, 14th International Object-Oriented and Entity-Relationship Modelling Conference, volume 1021 of Lecture Notes in Computer Science, pages 341{354. Springer-Verlag, December 1995. CITEC. Feasibility Assessment of Con rm ValueAdded Services. Technical report, Department of Information Management and Communications, Queensland State Government, Brisbane, Australia, June 1998. W. Deiters, Th. Goesmann, K. Just-Hahn, and R. Rolles. Support for exception handling through work ow management systems. In Proceedings of CSCW-98 Workshop \Towards Adaptive Work ow Systems", Seattle, Washington, November 1998. J. Eder and W. Liebhart. Contributions to Exception Handling in Work ow Management. In O. Bukhres, J. Eder, and S. Salza, editors, Proceedings EDBT Workshop on Work ow Management Systems, pages 3{10, Valencia, Spain, 1998. C.A. Ellis and G.J. Nutt. Modelling and Enactment of Work ow Systems. In M. Ajmone Marsan, editor, Application and Theory of Petri Nets 1993, volume 691 of Lecture Notes in Computer Science, pages 1{ 16, Berlin, Germany, 1993. Springer-Verlag. A.H.M. ter Hofstede and E.R. Nieuwland. Task structure semantics through process algebra. Software Engineering Journal, 8(1):14{20, January 1993.