An Event-Driven Workflow Engine for Service-based Business Systems

An Event-Driven Workflow Engine for Service-based Business Systems Julian Jang1, 2, Alan Fekete2, Paul Greenfield2, Surya Nepal1 1 ICT Centre PO Box 76 Epping NSW 1710 Australia {julian.jang, surya.nepal}@csiro.au 2 School of Information Technologies University of Sydney NSW 2006 Australia [email protected], [email protected] Abstract

This paper discusses a novel implementation of a workflow engine that supports service-based applications. The applications are defined according to the GAT model, which is an event-based programming model using conditional guards to determine when both normal and exception-handling activities are to be executed. We propose implementation techniques for key features of GAT. These include implementing control flow based on the evaluation of guards, the management and distribution of events, and enforcing atomicity across the evaluation of guards and the execution of the corresponding activities. We have built an engine following this approach which uses available technologies to support translating GAT models into executable applications.

1. Introduction Organisations typically define procedures that represent their internal business processes and their interactions with their partners. Each of these processes is usually made up of many smaller steps, such as filling in forms, getting these approved and recording critical information in various places. The term ‘business process’ is used to refer to the whole collection of such steps that make up a larger purposeful task. The rules that govern what steps must be done in what order have to be documented, and providing support for automating as many of these processing steps as possible is desirable. The term ‘workflow’ is used to refer to the structure of the business process. As well as simply documenting what steps should occur and in what order, there is a need for software tools that support the controlled execution of these workflow processes. These tools typically provide support for routing forms to the appropriate people, reminding them of what they need to do, and keeping track of the forms

and associated system state in a persistent way that survives system failures. The term ‘workflow engine’ is used for tools that control the execution of such a workflow-based business process. Typical commercial engines include Microsoft BizTalk Server, IBM MQ Workflow and Oracle Workflow. Traditional workflows were limited to steps that took place entirely within a single organisation. For example, the workflow for approving travel did not include finding appropriate flights, since these steps involve interactions with external providers who could not be required to use compatible tools. The economic benefits that come from integrating supplychains across business and organisational boundaries are driving the development of workflow tools, protocols and standards that can include all the steps associated with a task, no matter which organisation is undertaking them. This has led to a need for workflow models and engines that can orchestrate business processes that span autonomous interacting organisations. In recent work [10], we proposed a new approach for describing the orchestration of a long-running business process involving several interacting parties. This new approach is called GAT (Guard-Action-Trigger) and was inspired by weaknesses we identified in existing approaches to business process orchestration [8]. The primary contribution of this paper is to define and solve the critical challenges that have to be addressed when designing a workflow engine to support the GAT model. These include implementing control flow based on the evaluation of guards, the management and distribution of events, and enforcing atomicity constraints across the evaluation of guards and the execution of the corresponding activity. We have implemented a GAT workflow engine which is based on these design concepts and principles and is built on widely-available distributed computing infrastructure. We present and evaluate key aspects of this implementation and show how we can

generate executable code from a workflow expressed in a GAT-based syntax. In Section 2, we summarise the GAT approach to workflow [10]. We identify the critical challenges in building a GAT workflow engine in section 3. In Section 4, we describe the architecture of the GAT engine and the translation process. In Section 5, we discuss the nature of the generated code and how it corresponds to the GAT model and the principles described in Section 3. Related work is discussed in Section 6 and our conclusions are presented in Section 7.

handle the incoming event under the precise circumstances determined by the guards. if (a and b) { perform some action when a and b are both true } if (x) { raise events X1} if (not x) { raise events X2 } if if if if

(a & b) { raise events … } ((not a) & b) { raise events … } ((a & (not b)) {raise events … } ((not a) & (not b)) {raise events …}

Guard Action Group

Group

Trigger groups

2. Review of the GAT Model 2.1. GAT programming model The GAT model [10] defines a Process as a set of Activity Groups. Each activity group consists of an Event (a newly arriving message) and a set of related Activities, as shown in Figure 1. Process Event 1 Activity 1.1 Activity 1.2

Activity Group 1

… Event 2 Activity 2.1 Activity 2.2

Activity Group 2

… …. Event n

A trigger consists of a condition and a set of zero or more events (outgoing messages). After the action has completed, each trigger condition expression in a trigger group is evaluated in turn to determine what follow-on events need to be raised to further the handling of the initial event. Trigger events can be raised immediately or can be deferred for a specified period of time. The trigger expressions in each trigger group are also closed, meaning that exactly one trigger expression must evaluate to true, and only the events corresponding to that trigger expression will be raised. Activities can have multiple independent trigger groups, each corresponding to a different and parallel possible course of action.

2.2. Key features

Activity n.1 Activity n.2

Figure 2. GAT activity structure

Activity Group n

….

Figure 1. GAT process structure Each activity represents one possible response to its associated event and consists of a Guard, an Action and a set of Trigger groups. Each trigger group consists of a set of triggers. The structure of an activity is shown in Figure 2. Guards are Boolean expressions that can refer to both event parameters (message fields) and the current system state, and control whether or not their corresponding action should execute as part of the response to the event. The set of guard expressions in any one activity group are closed, meaning that when an event is received, the Boolean expression of exactly one of the activities in the activity group must be true and all the other Boolean expressions must be false. This property ensures that we will always take exactly one action from an activity every time a related event is received. The action part of an activity is conventional code written to correctly

The GAT programming model offers several features that can help software developers avoid a number of common mistakes. These include: • Uniform processing: there is no separation of the ‘normal’ case from ‘exceptions’. All arriving messages, whether they correspond to ‘normal’ or ‘exceptional’ processing cases, are treated equally. • Resumption: business processes can continue to execute normal actions after executing actions corresponding to ‘exceptional’ cases. • Access to state: there is no hidden or implicit state. The equivalent of the implicit ‘current position’ state in a graph-based workflow is replaced with normal state that can be examined by guards and updated from within actions. • Uniform outcome: there is no inbuilt notion of returning to an initial state or of compensation for the business process as a whole. Individual actions may act as atomic transactions, and abort and rollback, but the whole GAT process merely continues executing actions as they become enabled until the process completes.

• Coverage: alternate actions for the same event are grouped together and guard conditions specify which of these actions should be executed. Simple ‘closure’ tests on these conditions can guarantee that at least one action will be executed whenever any event is raised. • Protected actions: each action has a guard that is sufficient to ensure its code runs without errors. No other concurrent process can cause this guard to become false while the action is executing. This support for isolation means that an action can assume a property (such as the existence of a customer) that was checked earlier in the process, cannot have subsequently been modified by concurrent processes. • Response to non-occurrence of events: the trigger mechanism used to raise events that drive business processes forward can also be used to detect the expiry of a time-out, so actions can be taken when expected messages fail to arrive. • Integration: The raising of new events is separated from the action code that modifies state, allowing legacy code to be used as actions. This provides the same uncoupling of control flow and processing steps that is found in ECA graph-based models.

2.3. Case Study One of our previous papers [10] used an example based on an e-procurement application to show how the GAT model could be used to address some common design problems. This paper uses just the Payment section of that larger example to illustrate how an application written according to the GAT programming model can be translated into executable code through the use of a GAT ‘engine’. The ReceivePayment activity group in our example represents that part of the e-procurement process where the merchant processes customer payments. The merchant’s process receives incoming payment messages and checks the amount being paid against the amount owed. There are then three possible business scenarios that can be triggered in response: • Full payment has been received: the payment received is equal to the amount owed. The rest of the merchant’s application is notified that this phase of the procurement cycle has completed successfully. • Under-payment has been received: the payment received is less than the amount owed. In this case we calculate the amount still owing and send an additional invoice to the customer. • Over-payment has been received: the payment received is for more than the amount owed. In this case, there are two further actions to be taken, each expressed as a separate trigger group. One is to

calculate the over-payment and refund it. The other action notifies the rest of the merchant’s application that the customer has paid in full. Figure 3 shows how the ReceivePayment Activity Group could be programmed using GAT programming model. Group: ReceivePayment Event Payment Activity: process the full payment Guard Full payment has been received Action Record full payment has been received Construct a PaidInFull event. Trigger (true) raise the PaidInFull event to notify other parts of the merchant’s system that full payment has been received. Activity: process the under payment Guard Payment is less than amount owing Action Record payment amount Calculate residual amount Construct ResidualInvoice event Trigger (true) send ResidualInvoice to the customer Activity: process over payment Guard Payment is more than amount owing Action Record full payment has been received Calculate the refund amount Construct Refund event Construct a PaidInFull event Trigger (true) send Refund to the customer Trigger (true) raise the PaidInFull event to notify other parts of the merchant’s system that full payment has been received. Figure 3. ReceivePayment using GAT model

3. GAT Design Considerations The major contribution of this paper is to show how the features of the GAT programming model can be effectively implemented within a workflow engine constructed using off-the-shelf system infrastructure technologies such as C# and the .NET framework. We identify a number of key aspects of the GAT model that have an impact on the design of the GAT engine in this section, and then discuss their implementation in more detail in Section 5.

3.1. Defining GAT Syntax The GAT model describes each participating application within a distributed business activity in terms of Activity Groups. An Activity Group is a set

of actions invoked in response to an event (incoming message) and consists of a number of separate Activities represented as Guard-Action-Trigger triplets. The GAT presentation form shown in Figure 3 is unsuitable for machine translation and instead we use the more concrete GAT syntax shown in Figure 4. ACTIVTYGROUP: ReceivePayment

EVENT Payment ACTIVITY: processFullPayment GUARD Invoice.amt = payment.amt ACTION FullPaymentAction(payment) TRIGGER (true)[INT] PaidInFull ACTIVITY: processUnderpayment GUARD Invoice.amt > payment.amt ACTION UnderpaymentAction(payment) TRIGGER (true) [EXT]ResidueInvoice; ACTIVITY: processOverpayment GUARD Invoice.amt < payment.amt ACTION OverpaymentAction(payment) TRIGGER (true) [EXT]Refund TRIGGER (true)[INT]PaidInFull Figure 4. ReceivePayment in GAT syntax The notation such as [INT] and [EXT] is used to distinguish between internal and external events. One could envision sophisticated support for syntax checking, automatic generation of GAT syntax from diagrams and other such development tools; however our current prototype simply asks the system developer to produce text such as that shown in Figure 4.

3.2. Control Flow of Business Activities In conventional graph-based or block-structured workflow languages, control flow between stages of the workflow is defined in the syntax or its graphical representation. Control flow in GAT is determined dynamically as events are raised and corresponding activities are invoked. A key issue for a GAT engine is how to manage the control flow: how to pick the appropriate action to perform in response to an event. Our current implementation makes use of the .NET Event mechanism which allows code to subscribe to events and be invoked whenever these events are raised, but does not support the concept of conditional guards that are used in GAT to choose the one appropriate action from an activity group. In Section 5 we describe the way each GAT activity group is represented in our engine by a method which contains code to successively evaluate the guards of the contained actions.

A further complexity for our engine comes from our decision to allow guard expressions to refer to any aspect of state. GAT guards can refer to both Business Process State (which has variables reflecting what actions have occurred) and Abstract State (a computer-based representation of the domain, typically stored in databases or in variables used by the code of particular actions). In contrast, conventional workflow languages use only Business Process State (often implicit) when deciding control flow, and allow references to Abstract State only from inside the individual actions. The GAT model defines in detail how execution must take place when multiple activity groups are dealing with the same event. This is especially significant because the guard conditions may refer to state that can be changed inside actions. The GAT model defines that when an event occurs, all the activity groups related to this event will be selected; one of these activity groups will be chosen and its guards evaluated to determine which of its activities is to be executed. This activity is then executed, and this may (through the triggers) raise further events. Another of the originally selected activity groups is then processed in the same way, until all selected activity groups have been considered. After this, if additional events have been raised, each is processed in the same way in turn. The GAT engine implements this required behaviour using multiple subscribers to .NET events.

3.3. Atomicity Concerns In the GAT model, it is essential that the choice of which action to perform from an activity group (by evaluation of guards), the execution of the chosen action, and the evaluation of its trigger conditions and raising any further events, must all form an isolated unit. That is, no other concurrent actions can alter any aspect of the state referenced by the activity group, between evaluations of the guards, execution of the selected action, evaluation of the trigger, and raising of subsequent events. Our engine implementation uses locking mechanisms provided by the .NET framework to achieve this.

3.4. Management and Distribution of Events As noted above, events play a vital role in driving the GAT programming model. While the underlying .NET event publish/subscribe mechanism can be used to implement the basic control flow mechanism, the GAT event concept is somewhat more complex and the workflow engine needs to have special mechanisms for the various types of GAT events.

• Internal events are used to control flow among Activity Groups within the same business process. In our engine implementation, these are mapped directly to .NET Events, and Section 5 discusses the various classes and methods which we define to make this work. • In the GAT model, external events control the communication between interacting peer business processes. In a service-based model, communication between parties is handled solely by exchanging messages, using technologies such as SOAP or .NET Remoting. The GAT engine needs to convert between messages and events and we did this by representing each external GAT event twice in our engine: both as a message and as an internal .NET event. In Section 5 we show how our engine can convert between these two forms as external events are received or raised. • GAT deferred events are used to provide a way of initiating activities whenever other events and activities do not occur before the expiration of a deadline. Our engine implements deferred events through a combination of .NET events (which are raised and processed immediately) and .NET timers.

3.5. Correctness Properties One of the motivations for the GAT model is to help prevent some common errors, such as race conditions and unhandled failures/exceptions. It does this by enforcing relationships between the parts of the GAT specification. The GAT compilation mechanism checks the following conditions, as well as converting GAT descriptions into executable code. • Completeness: There must be an activity group to handle every possible event that is raised anywhere or that can arrive from outside the process. • Guard Closure: Exactly one activity in each group can be invoked in response to an event. This guarantees that always exactly one action is executed every time an event is received. • Trigger Closure: Exactly one trigger condition must fire within a trigger group. This guarantees that there will always be an outcome of an activity. The compilation process can easily check for completeness syntactically, however, the closure properties require semantic analysis as the different guards can involve arbitrary logical expressions referring to all aspects of the state. For simplicity, our implementation deals with the restricted case where each guard is a disjunction of conjunctions of Boolean attributes. This restriction means that we can check closure by a matrix-based coverage test, as described in Section 5.

4. Architecture of GAT Engine In this section, we describe a prototype engine we built to convert from GAT syntax to C# applications running on the .NET platform. This GAT workflow engine generates running code from GAT specifications. Business analysts can define their intended workflow following the GAT model and using GAT syntax. The GAT engine reads these specifications, translates them into corresponding C# classes, and then compiles and executes the resulting .NET code. This separation of specification from implementation is similar to the approach taken by MDA (Model driven Architecture) [31]. The GAT engine has two major stages: translation and generation. The translating stage reads specifications written in GAT syntax and translates them to corresponding C# code. As each line of GAT syntax is read, the engine creates an ‘analyser’ table representing the C# components corresponding to the GAT specification. It also creates a ‘mapper’ table that contains enough information to define the specific .NET mechanisms needed for each C# components. The generation stage is based on the mapper table and uses CodeDOM [30] to create C# classes with matching methods and variables. These C# files are compiled into executable DLL files by the engine. GAT specification

Analyser

CodeDOM

C#

DLL

Mapper

Translation Stage

Generation Stage

Figure 5. Inside GAT engine Figure 5 shows the major steps the engine goes through to produce tables of structures, classes, and files. These steps are: 1) Analyser: This reads a GAT specification file and parses GAT syntax into the corresponding table structures. For example, activity groups, complete with their events and activities, are parsed and stored in the activity group table. Information about activities are held in the activity table, each entry referring to a guard table entry with its conditional expression, a method name for the code that implements the action (normally pre-written legacy code) and a reference to a trigger table entry. 2) Mapper: The role of the Mapper is to map GAT structures into the corresponding C#. For example, an Activity Group is converted into a method call

containing as ‘if-then-else’ blocks representing each Activity statement within the group. GAT events are translated directly into .NET events and code is generated to subscribe Activity Groups to these events. 3) CodeDOM: The core of the GAT engine generates the source code needed to run the business process corresponding to the given GAT specification. Our engine makes use of the CodeDOM source code generation tool from .NET framework. This tool generates source code from a ‘language-neutral’ defined set of statements and the GAT engine builds CodeDOM structures from information held in the mapper table, including class names, member variables and member methods. 4) Generating C#: The end result of the CodeDOM builder is a fully populated CodeDOM tree. Developers can then generate source code in any .NET languages such as VBScript, J#, or C# from these CodeDOM trees. Our implementation generates C# source code files. 5) Compiler: The GAT engine then uses the CodeDOM Compiler API to generate executables from these C# source files. We used this GAT engine to translate and run parts of the merchant, customer and shipper applications from our e-procurement case study. We tested the GAT engine on a DELL Optiplex GX270SMT with a 3 GHz Intel Pentium IV processor and 1GByte RAM, running on Windows XP Professional SP2 and the NET framework v2.0. The test used 5 GAT specification files representing the customer process (quoting-request, sendingpurchase-order, sending-payment, receiving-goods, cancellation), 5 GAT specification files for the merchant (quoting, processing-purchase-order, processing-payment, arranging-delivery), and 1 GAT specification for the shipper (processing-delivery). Additionally, each party had one pre-defined GUI form to interact with users and one user library that contained their legacy code and the definition of messages and events types. The GAT engine took these 11 specifications produced 11 class files corresponding to specifications, 14 class files representing messages and events, and an additional 16 files for Remoting and action code (legacy code). We also measured the time it took for each major stage of the engine. It took an average of 32 seconds for engine to produce executable files from specifications. 70% of this time was spent in the translating stage and the other 30% of the time was used to generate and compile the source code. When running these executable files as business processes, it took an average 13.5 seconds to go through one phase of ordering process from the customer sending

a purchase order to the customer receiving their goods, not including the time taken for user interactions.

5. Implementation of GAT engine In this section, we discuss details of the implementation of each of the key features of GAT that were covered in Section 3. We first explain how each business process, represented in GAT as a set of activity groups, can be expressed as a collection of C# classes and their methods. We then discuss the event-handling and message-passing infrastructure which provides the equivalent of conventional control flow mechanisms for GAT. Finally we describe the way the GAT engine enforces correctness properties such as closure of the guards and triggers among the activities within a single Activity Group.

5.1. Defining Activity Group and Execution of Activities A business process is defined in the GAT model as a set of activity groups, where each activity group consists of an event and a set of related activities to handle that event in different situations. Each Activity Group is translated into a single C# method within a class that corresponds to the business process. Each activity within the group is represented as one if-then-else block inside this method. An activity group is run as an isolated unit by using Mutex locking mechanisms. The Guard condition of the Activity is, naturally, the Boolean condition that is tested by the ‘if’ clause. The action part of each Activity in GAT typically contains the piece of code that fulfils a business step, such as buying a book or reserving a stock amount. For simplicity, in our notation we require the GAT specification to directly contain the C# code for the Action, so no conversion is needed to produce the body of the ‘then’ clause. Each execution of an activity is followed by further ‘if’ statements that represent the triggers which generate new events. The result of this translation process is shown in the following code fragment corresponding to the example from Figure 4. This code is executed whenever the engine is notified that the corresponding .NET Event ePayment has occurred. There are three different activities in this example for handling payments as discussed previously, allowing the application to respond appropriately to the payment amount received. The GAT specification selects from amongst these alternatives using Guard expressions, that are translated into the conditions for each of the top-level ‘if’ expressions. Once an

activity is chosen, the engine runs its Action code and then falls into the series of ‘if’ statements that represent this activity’s Trigger expressions that will send out any follow-on events. public virtual void ReceivePayment(object sender, PaymentEvent e) { mutex.WaitOne(); if ((mp.FullPayment(e.payment))) { mp.FullPaymentAction (e.payment); if ((true)) mrs.PaidInFull(e.payment); } if ((mp.UnderPayment(e.payment))) { mp.UnderpaymentAction(e.payment); if ((true)) mrs.ResideInvoice(e.payment); } if ((mp.OverPayment(e.payment))) { mp.OverpaymentAction(e.payment); if ((true)) mrs.Refund(e.payment); if ((true)) mrs.PaidInFull(e.payment); } mutex.ReleaseMutex(); }

5.2. Supporting Events There are three types of events in the GAT model: internal events, external events, and deferred events. These are all expressed using the .NET Event mechanism, but there are significant differences in the way they are handled. 1) Internal Events: Internal events are used to communicate between activities within a single business process. New Events are published by Trigger Groups after the execution of Action code. These Events will be consumed by any Activity Groups whose subscriptions match its event type. Both the GAT event concept and its .NET implementation follow the publish/subscribe model. There are four classes involved in the implementation of event communication. The class that raises the event is called the event sender. The class that consumes the event and responds to it is called the event receiver. The event sender does not know which object will receive the events it raises. An intermediary class called a delegate connects the event sender and the event receiver, and an additional class is used as an event argument to pass data between the event sender and the event receiver. In our GAT implementation, the Triggers which raise events are mapped into event senders in .NET, while Activity Groups are mapped into event receivers. Delegates are automatically created by the engine when Events are raised, and an event argument class is created based on the information provided by the GAT specification. The next code excerpt illustrates the creation of a new event ‘Payment’ from a payment message sent by a

customer, and also shows how this event is received by the Activity Group ReceivePayment. // Converts a Payment msg to an event public static event PaymentEventHandler peh; public virtual void Payment (Payment v_Payment){ peh(this, new PaymentEvent(v_Payment)); } public delegate void PaymentEventHandler (object sender, PaymentEvent e); // ReceivePayment receives PaymentEvent MerchantRemoteService.peh += new MerchantRemoteService.PaymentEventHandler (this.ReceivePayment); public virtual void ReceivePayment(object sender, PaymentEvent e) { … }

2) External Events: External Events are used to communicate between activities in different business processes. The GAT Engine represents participating services as .NET Remote objects and messages are passed between services by passing them as parameters on remote calls. These message objects are converted to local events when they arrive at the receiving system. This mechanism is discussed in detail in Section 5.3 below. 3) Deferred Events: Deferred Events are used when a process needs to trigger corrective actions if anticipated events have not happened by some deadline. In our GAT example, a deferred event eOverduePayment is raised as soon as an invoice is sent. This event may be received later on by the Activity Group that handles the overdue payment process - but only if the anticipated payment was not received within the due period. The next code sample shows how the SendInvoice Activity sets a timer that waits until payment due period has expired and then raises the Elapsed event. The timer is turned off if the payment is received within the payment due period but this code is not shown. The Elapsed event is received by the Activity Group overduePayment that then sends a reminder to the customer. // Setting a timer to check out overdue public void SendInvoice(){ Timer aTimer = new Timer (); aTimer.Elapsed += new ElapsedEventHandler(OverduePayment); aTimer.Interval = returnPaymentDueDuration(); ... } // OverduePayment receives event OverduePayment to send a reminder to customer eOverduePayment += new

OverduePaymentEventHandler(OverduePayment);

normal form and makes sure that all combinations are covered.

public void OverduePayment(...) ... }

6. Related Work

{

5.3. Inter-process communication The GAT engine produces executables that communicate with one another by transferring objects using .NET Remoting. This use of .NET Remoting means that business processes can be location-transparent; they may be on the same computer, on different computers on the same network, or on computers across separate networks. In this section we show how this works. As mentioned above, external events in the GAT model are implemented as object parameters passed using .NET Remoting. The underlying Remoting mechanism also supports different transport and communication protocols. Currently, our GAT engine allows code to be produced which uses either of two transport protocols, TCP and HTTP. The engine implements a remote service class for each business process. A service method in each of these classes receives incoming messages as a parameter and raises local ordinary .NET Events according to what type of messages was received. Local activity groups will then consume these events, possibly sending out messages in response as parameters to calls on other remote objects.

5.4. Correctness Checking Mechanisms Our GAT implementation demonstrates that it is possible to check at compile time that specifications meet several important correctness properties. ‘Completeness’ checking ensures that no messages can be left unprocessed at termination. The compiler checks for completeness by ensuring that for every event sender there is at least one event receiver that subscribes to (and could consume) the events being raised. If there is a mismatch between event senders and event receivers, the engine reports a compilation error so that the problem can be resolved at design time rather than much later on when the problem appears in production as an application hang or an unprocessed message. ‘Closure’ checking over Guards ensures that there is always at least one action executed to deal with an incoming event and checking Trigger Groups ensures that at least one trigger can raise an outgoing event. In our prototype implementation, we check for the simple case where the guards or trigger conditions are defined by Boolean combinations of simple attributes. Our compiler expands each condition into disjunctive

There is a large literature on notations for describing business processes for Web Services applications. Many of these have been created as part of workflow-management [5], [9], [12] or business process offerings [10] by both commercial vendors and open source community. The dominant approach represents a workflow as a graph that controls the flow of control between business steps. IBM Websphere MQ Workflow [14] and Oracle Workflow [15] are graph-based commercial products that provide graphical drag and drop Process Designers that allow users to define their business activities. Open source offerings in this category, such as Shark [16], Bonita [17], OBE [18], and WfMOpen [19], all provide graphical user interfaces and graph-based control for business activities based on the WfMC specification using XPDC [20]. These graphical drag and drop tools let users build workflow applications without having to learn underlying complex notations, but their lack of flexibility restricts their ability to meet complex business requirements. New hybrid implementations have learnt from these earlier tools and started providing facilities where the users can not only use the given graphical tools but also can use lower-level facilities to program any extra features that they need to define. Microsoft Windows Workflow Foundation [21] is a programming model, engine, and a set of tools for quickly building workflow enabled workflows in the Windows environment. Windows Workflow provides a way of describing the order of execution and dependent relationships between pieces of short or long running business activities. Windows Workflow provides a graphical programming model but it is also possible to write a workflow completely in code. Once a workflow model has been compiled, it can be executed inside any Windows process including console applications, forms-based applications and Web services. Block structured languages represent a simplified form of control between business steps, providing fork and join constructs as well as sequential flow and conditional branching. BizTalk Server [22] adopts this approach and this is also the model used in standards such as BPEL4WS [1] and WSCI [2]. BPEL4WS especially has become very popular as a result of its strong sponsorship from Microsoft, IBM, and BEA. It has subsequently become a de-facto standard as a business process notation in the Web

Services community, though its weaknesses have been identified by [8]. BPEL is popular with the open source community and several BPEL engines such as Twister [23], ActiveBPEL [24], and PXE [25] have been implemented. Petri Nets have been investigated by some researchers as a potential business process notation, following from its successful use as a mathematical representation of discrete distributed systems [29]. Its ability being able to depict the structure of a system as a directed bipartite graph with annotations appealed to many researchers and scientists [26]. Con:cern [27] is a workflow engine based on an extended case handling approach founded on Petri Nets that has been developed by an open source community backed up by research activities. Bossa [28] is another popular open source workflow engine based on Petri Nets. However, some researchers [28] have argued that the lack of compositionality is a serious limitation of Petri Nets and that this deficiency limits modularity. The workflow engines and business process notations most relevant to GAT are those based on events. The initial event-based workflow models were inspired by research into active databases [13] where triggers are used to respond to situations whenever they occur. The first paper to adopt this idea for managing control flow in a long running activity was Dayal et al. [4] where the ECA (EventCondition-Action) notation was proposed. The idea has proved especially valuable for building prototypes of distributed workflow execution engines such as C2offein[7], IRules[11], and WIDE [3]. Formal semantics for the ECA model have been proposed by Geppert et al. [6]. Two distinctive features implemented by GAT engine but not found in these ECA systems include: (a) the grouping of actions with closure properties on the conditions to ensure coverage (b) the capacity to define events that will occur in the future only if intervening actions have not completed in the meantime.

7. Conclusion We have presented the design of a workflow engine that supports the definition and execution of long-running business processes, including interactions between parties that cross organisational boundaries. The workflows are described in a syntax based on the event-based GAT model [10]. The engine we described takes GAT workflow descriptions and turns them into executable code. We have shown in detail how each GAT construct can be implemented using C# and the.NET platform. Other modern distributed computing technologies, such as

Java, would have been equally suitable as a basis for our implementation. The use of Web service standards for the sending and receiving event messages would even allow these different implementations to be interoperable. We have demonstrated that it is possible to check for closure (which is a correctness property of the specification) at compile time. In future work, we plan to optimise the compilation process, and to extend the engine to support a protocol which checks that consistency conditions are maintained at termination time. We are also considering building a graphical user interface to make it easier for business analysts to define a workflow description following the GAT model. We also plan to include optimisations in the engine to improve the performance of the compilation process itself and of the executable code it produces. Another major problem facing developers of service-oriented computing applications and business processes is the lack of isolation and the subsequent risk that concurrent applications will interfere with each other. We are currently looking into dealing with these issues through application protocols and patterns. We will extend the engine to incorporate such mechanisms as we find useful.

8. References [1] Business Process Execution Language for Web Services (BPEL4WS), Version 1.0. http://www106.ibm.com/developerworks/webservices/library/ws-bpel/ [2] Web Service Choreography Interface (WSCI) 1.0 Specification. http://www.w3.org/TR/wsci/ [3] S. Ceri, P. Grefen, and G. Sanchez, “WIDE – a distributed architecture for workflow management”. Proc RIDE’97, pp 76-81, 1997. [4] U. Dayal, M. Hsu, and R. Ladin, “Organizing LongRunning Activities with Triggers and Transactions”. Proc ACM International Conference on Management of Data (SIGMOD)., pp. 204-214, 1990. [5] G. Dittrich, R. Endl, and M. Pfahrer, “Modeling Processes and Workflows by Business Rules”. In Business Process Management, ed W. van der Aalst, LNCS 1806, pp. 16-29, 2000. [6] A. Geppert, D. Tombros, and K. Dittrich, “Defining the Semantics of Reactive Components in Event-Driven Workflow Execution with Event Histories”. Information Systems 23(3/4):235-252, 1998. [7] A. Koschel, and R. Kramer, “Applying Configurable Event-triggered Services in Heterogeneous, Distributed Information Systems”. Engineering Federated Information Systems, Proceedings of the 2nd Workshop EFIS'99, May 5-7, 1999, Kühlungsborn, Germany,pp. pp. 147-157

[8] P. Greenfield, A. Fekete, J. Jang, and D. Kuo, “Compensation is not enough!”, IEEE Enterprise Distributed Object Computing (EDOC), pp. 232-239, Australia, 2003 [9] F. Leymann, and D. Roller, Production Workflow: Concepts and Techniques. Prentice-Hall, 2000. [10] S. Nepal, A. Fekete, P. Greenfield, J. Jang, D. Kuo, T. Shi, “A Service-oriented Language for Robust Interacting Applications”, Cooperative Information Systems, pp. 1199-1203, Cyprus, 2005 [11] S. D. Urban, S. Kambhampati, S. W. Dietrich, Y. Jin, and A. Sundermier, “An Event Processing System for RuleBased Component Integration”, Proceedings of the International Conference on Enterprise Information Systems, Portugal, April, 2004. pp.312-319 [12] W. Van der Aalst, and K. Van Hee, Workflow Management: Models, Methods and Systems. MIT Press, 2002. [13] J. Widom, and S. Ceri, Active Database Systems: Trigger and Rules For Advanced Database processing. Morgan Kaufmann, 1995 [14] IBM Websphere MQ Workflow. http://www306.ibm.com/software/integration/wmqwf/ [15] Oracle Workflow. http://www.oracle.com/technology/products/integration/wo rkflow/workflow_fov.html [16] Enhydra Shark. http://shark.objectweb.org/ [17] ObjectWeb Bonita. http://bonita.objectweb.org/

[18] Open Business Engine (OBE). http://www.openbusinessengine.org/index.html [19] WfMOpen. http://wfmopen.sourceforge.net/ [20] Workflow Management Coalition. www.wfmc.org [21] Microsoft Windows Workflow Foundation. http://msdn.microsoft.com/winfx/reference/workflow/ [22] Microsoft BizTalk Server. http://www.microsoft.com/biztalk/ [23] Twister. http://www.smartcomps.org/twister/ [24] ActiveBPEL. http://www.activebpel.org/ [25] Process eXecution engine (PXE). http://pxe.fivesight.com/ [26] H. Gou, B. Huang, W. Liu, S. Len, and Y. Li, “Petri net based business process modelling for virtual enterprises” In Proc. IEEE International conference on systems, Man, and Cybernetics (SMC’2000), vol. 4, pp 3183-3188, 2000 [27] Con:cern. http://concern.sourceforge.net/ [28] Bossa. http://www.bigbross.com/bossa/ [29] J. Leifer and R. Miler Transition systems, link graphs Petri nets, University of Cambridge, Technical Report UCAM-CL-TR-598 ISSN 1476-2986 [30] MSDN .NET Framework Developer’s Guide Using CodeDOM http://msdn.microsoft.com/library/default.asp?url=/library/e n-us/cpguide/html/cpconUsingCodeDOM.asp [31] Model Driven Architecture (MDA) homepage. http://www.omg.org/mda/