Table of contents
1 Introduction
2 Evaluation of control-flow patterns in IBM WebSphere Integration Developer
2.1 Basic Control Flow Patterns
Pattern 1 (Sequence)
Pattern 2 (Parallel Split)
Pattern 3 (Synchronization)
Pattern 4 (Exclusive Choice)
Pattern 5 (Simple Merge)
2.2 Advanced Branching and Synchronization Patterns
Pattern 6 (Multi-choice)
Pattern 7 (Synchronizing Merge)
Pattern 8 (Multi-merge)
Pattern 9 (Discriminator)
2.3 Structural Patterns
Pattern 10 (Arbitrary Cycles)
Pattern 11 (Implicit Termination)
2.4 Patterns involving Multiple Instances
Pattern 12 (Multiple Instances without Synchronization)
Pattern 13 (Multiple Instances with a Priori Design Time Knowledge)
Pattern 14 (Multiple Instances with a Priori Runtime Knowledge)
Pattern 15 (Multiple Instances without a Priori Runtime Knowledge)
2.5 State-based Patterns
Pattern 16 (Deferred Choice)
Pattern 17 (Interleaved Parallel Routing)
Pattern 18 (Milestone)
2.6 Cancellation Patterns
Pattern 19 (Cancel Activity)
Pattern 20 (Cancel Case)
3 Summary
References
List of figures
Figure 1: Sequence
Figure 2: Parallel Split
Figure 3: Synchronization
Figure 4: Exclusive Choice
Figure 5: Exclusive Choice with otherwise condition
Figure 6: Simple Merge
Figure 7: Multi-choice
Figure 8: Multi-merge
Figure 9: Discriminator
Figure 10: Multiple Instances without Synchronization
Figure 11: Multiple Instances with a Priori Design Time Knowledge
Figure 12: Multiple Instances with a Priori Runtime Knowledge
Figure 13: Multiple Instances without a Priori Runtime Knowledge
Figure 14: Deferred Choice
Figure 15: Interleaved Parallel Routing
Figure 16: Milestone
Figure 17: Cancel Activity
Figure 18: Cancel Case
List of tables
Table 1: Support of control-flow patterns in IBM WebSphere Integration Developer
Table 2: Mapping of symbols and terms used in IBM WebSphere Integration Developer to employed BPEL constructs
Appendix: BPEL Code
Pattern 1 (Sequence)
Pattern 2 (Parallel Split)
Pattern 3 (Synchronization)
Pattern 4 (Exclusive Choice)
Pattern 5 (Simple Merge)
Pattern 6 (Multi-choice)
Pattern 7 (Synchronizing Merge)
Pattern 8 (Multi-merge)
Pattern 9 (Discriminator)
Pattern 12 (Multiple Instances without Synchronization)
Pattern 13 (Multiple Instances with a Priori Design Time Knowledge)
Pattern 14 (Multiple Instances with a Priori Runtime Knowledge)
Pattern 15 (Multiple Instances without a Priori Runtime Knowledge)
Pattern 16 (Deferred Choice)
Pattern 17 (Interleaved Parallel Routing)
Pattern 18 (Milestone)
Pattern 19 (Cancel Activity)
Pattern 20 (Cancel Case)
1 Introduction
There are numous Business Process Execution Language (BPEL) modeling tools available on the market today that differ in their power and ability to transform patterns into executable BPEL code. Examples for commercially available tools are ActiveBPEL [5], Oracle-BPEL [12] and IBM WebSphere Integration Developer [3]. Patterns describe business requirements and thus define the needs in workflow languages and their related modeling tools. Patterns are used as a basis to compare these tools.
In this student research paper should be examined to which extend the control-flow patterns presented in [1] are supported by IBM WebSphere Integration Developer V6.0 [3] on IBM WebSphere Process Server for Multiplatforms V6.0 [4]. IBM WebSphere Integration Developer uses the Business Process Execution Language for Web Services version 1.1 (BPEL4WS) [2, 7] as the basis but already implements functionality of WS-BPEL version 2.0. Control-flow patterns include basic control patterns, patterns involving multiple instances, state-based patterns and cancellation patterns. Extensive surveys of control-flow patterns have been made in [10] and [11].
The BPEL and the Web Service Description Language (WSDL) source code of the implementations are listed in the appendix. <Assign> activities are mostly used as placeholders for comprehensive business logic and if this is not the case, they are explained in detail.
2 Evaluation of control-flow patterns in IBM WebSphere Integration Developer
2.1 Basic Control Flow Patterns
Pattern 1 (Sequence)
Description: An activity in a workflow process is enabled after the completion of another activity in the same process [1].
Synonyms: Sequential routing, serial routing.
IBM WebSphere Integration Developer supports this pattern directly because two activities can be connected in succession. A typical implementation involves linking two activities with an unconditional control flow arrow as shown in figure 1.
IBM WebSphere Integration Developer uses the sequence activity provided by BPEL [2]. A sequence activity contains one or more activities that are performed sequentially, in the order in which they are listed within the sequence element, that is, in lexical order. The sequence activity completes when the final activity in the sequence has completed [2].
illustration not visible in this excerpt
Figure 1: Sequence
Pattern 2 (Parallel Split)
Description: A point in the workflow process where a single thread of control splits into multiple threads of control which can be executed in parallel, thus allowing activities to be executed simultaneously or in any order [1].
Synonyms: AND-split, parallel routing, fork.
IBM WebSphere Integration Developer supports this pattern directly by means of the <parallel activities> construct which uses the flow construct provided by BPEL that contains a couple of branches that execute concurrently [2].
An example of implementing this pattern is shown in figure 2. In this example three <assign> activities inside a <parallel activities> construct are started at the same time.
illustration not visible in this excerpt
Figure 2: Parallel Split
Pattern 3 (Synchronization)
Description: A point in the workflow process where multiple parallel subprocesses/activities converge into one single thread of control, thus synchronizing multiple threads. It is an assumption of this pattern that each incoming branch of a synchronizer is executed only once [1].
Synonyms: AND-join, rendezvous, synchronizer.
IBM WebSphere Integration Developer supports this pattern directly by means of the <parallel activities> construct which uses the flow construct provided by BPEL [2]. The flow construct provides synchronization and contains a couple of branches that execute concurrently [2]. The branches inside the <parallel activities> construct get synchronized as soon as the <parallel activities> construct has finished. The <parallel activities> construct completes when every branch has been skipped or processed.
An example of implementing this pattern is shown in figure 3. In this example three <assign> activities inside a <parallel activities> construct are executed in parallel and each of them may be executed only once. The <reply> activity gets started when all braches have completed. The point of synchronization is located where the control flow arrow starts which points to the <reply> activity.
illustration not visible in this excerpt
Figure 3: Synchronization
Pattern 4 (Exclusive Choice)
Description: A point in the workflow process where, based on a decision or workflow control data, one of several branches is chosen [1].
Synonyms: XOR-split, conditional routing, switch, decision.
IBM WebSphere Integration Developer supports this pattern directly by means of the <choice> construct which uses the switch activity available in BPEL [2] and implements the same semantics. The switch construct allows only one branch to be activated and none of the other branches is ever processed in parallel. It uses an ordered list of one or more conditional branches that are configured by case elements and an optional otherwise element. The expressions of the conditions are evaluated in the order in which they appear in the BPEL source code and accordingly from left to right in the visual representation as shown in figure 4 and 5. If more than one condition is fulfilled, only the first one is executed. When the chosen branch has finished, the <choice> activity completes [2].
illustration not visible in this excerpt
Figure 4: Exclusive Choice
In order to ensure that an activity is executed even if all conditions of available <case> branches evaluate to false, you can add an <otherwise> branch as shown in figure 5.
illustration not visible in this excerpt
Figure 5: Exclusive Choice with explicit <otherwise> condition
The Exclusive Choice pattern can also be implemented by using links with transition conditions for every branch inside a <parallel activities> construct. Note that all transition conditions have to be disjunctive to ensure that only one branch at maximum is executed. When the chosen branch has finished, the <parallel activities> construct completes. All activities are skipped if none of the conditions evalutate to true and the <parallel activities> construct finishes too.
Pattern 5 (Simple Merge)
Description: A point in the workflow process where two or more alternative branches come together without synchronization. It is an assumption of this pattern that none of the alternative branches is ever executed in parallel [1].
Synonyms: XOR-join, asynchronous join, merge.
Accoring to pattern 4 (Exclusive Choice) IBM WebSphere Integration Developer supports this pattern directly by means of the <choice> construct and alternatively by using links with disjunctive transition conditions inside a <parallel activities> construct.
As shown in figure 6, either <Assign1> or <Assign2> gets activated but they will never be executed concurrently. When the chosen branch has finished or both have been skipped, the <choice> construct completes and the two alternative branches come together. The point of synchronization is located where the control flow arrow starts which points to the <reply> activity. The point of synchronization is located where the control flow arrow starts which points to the <reply> activity.
illustration not visible in this excerpt
Figure 6: Simple Merge
2.2 Advanced Branching and Synchronization Patterns
Pattern 6 (Multi-choice)
Description: A point in the workflow process where, based on a decision or workflow control data, a number of branches are chosen [1].
Synonyms: Conditional routing, selection, OR-split.
This pattern is supported in IBM WebSphere Integration Developer by using links with transition conditions in every branch inside a <parallel activities> construct. The transition conditions associated with the links are evaluated based on the input provided by the client and do not have to be disjunctive. As a result more than one branch may be chosen at the same time and be executed concurrently. When all chosen branches have completed, the <parallel activities> construct finishes. An example is shown in figure 7 below. If the input data can not be used with any transition condition or every condition evaluates to false, none of the braches is executed.
illustration not visible in this excerpt
Figure 7: Multi-choice by links with transition conditions and Synchronizing Merge with transition conditions
Pattern 7 (Synchronizing Merge)
Description: A point in the workflow process where multiple paths converge into one single thread. If more than one path is taken, synchronization of the active threads needs to take place. If only one path is taken, the alternative branches should reconverge without synchronization. It is an assumption of this pattern that a branch that has already been activated cannot be activated again while the merge is still waiting for other branches to complete [1].
Synonyms: Synchronizing join.
Corresponding to pattern 6 (Multi-choice) IBM WebSphere Integration Developer supports this pattern by means of the <parallel activities> construct that contains a couple of branches as shown in figure 7. Transition conditions are used to determine which branches are to be activated.
The <parallel activities> construct avoids the problem to decide in which case to synchronize and in which one to merge. The <parallel activities> construct ensures executing or skipping of each branch and synchronizes all of them. It will only complete if every branch has been skipped or has been completed and none of the branches can be executed multiple times.
Pattern 8 (Multi-merge)
Description: A point in a workflow process where two or more branches reconverge without synchronization. If more than one branch gets activated, possibly concurrently, the activity following the merge is started for every activation of every incoming branch [1].
Synonyms: -
IBM WebSphere Integration Developer does not support this pattern directly. A possible solution would look like the one shown in figure 8. The first <assign> activity sets a counter to zero and there are multiple branches inside the <parallel activities> construct. Every branch contains an <empty action> construct which is needed to provide the following <assign> activity with a transition condition. The transition conditions do not have to be disjunctive and several activities may be executed concurrently. The <assign> activity that represents the workflow is linked with another <assign> activity which increases the counter. Finally <Assign4> represents the actitiy that follows the merge and it is executed as many times as defined in the counter or rather as many times a branch in the <parallel activities> construct was activated.
illustration not visible in this excerpt
Figure 8: Multi-merge
Pattern 9 (Discriminator)
Description: The discriminator is a point in a workflow process that waits for one of the incoming branches to complete before activating the subsequent activity. From that moment on it waits for all remaining branches to complete and ignores them. Once all incoming branches have been triggered, it resets itself so that it can be triggered again (which is important otherwise it could not really be used in the context of a loop) [1].
Synonyms: -
IBM WebSphere Integration Developer supports this pattern. Figure 9 shows an example of a possible implementation. The <parallel activities> construct contains multiple <assign> activites that are all linked to an <empty action> construct. The join condition of the merging link is not specified whereby it evaluates to the logical OR of all incoming links in IBM WebSphere Integration Developer. Thus <EmptyAction> is processed for one incoming link but nonrecurring as the workflow engine marks the <EmptyAction> activity as processed. The <parallel activities> construct completes as soon as the <empty action> activity has finished.
illustration not visible in this excerpt
Figure 9: Discriminator
2.3 Structural Patterns
Pattern 10 (Arbitrary Cycles)
Description: A point in a workflow process where one or more activities can be done repeatedly [1].
Synonyms: Loop, iteration, cycle.
IBM WebSphere Integration Developer does not support this pattern. It is feasible to create structured cycles but is not possible to jump into another <while loop> construct and build overlapping and nested cycles. The only possibility to create loops is by using the <while loop> construct which allows only one starting and one ending point and does not allow random jumps into a loop. A link must not cross the boundary of a while activity [2].
Pattern 11 (Implicit Termination)
Description: A given subprocess should be terminated when there is nothing else to be done. In other words, there are no active activities in the workflow and no other activity can be made active (and at the same time the workflow is not in deadlock) [1].
Synonyms: -
IBM WebSphere Integration Developer supports this pattern in the way that a process is automatically finished when all activities in the workflow are processed and there are no activities left. The process as a whole completes normally.
In cases where the join condition for an activity turns out to be false, the activity and it´s following activities are not performed (Dead-Path-Elimination). In IBM WebSphere Integration Developer you can use the attribute suppressJoinFailure provided by BPEL [2]. The default value of suppressJoinFailure is “no” in order to avoid unexpected behavior and you can add it to a specific activity or to the whole process.
2.4 Patterns involving Multiple Instances
Pattern 12 (Multiple Instances Without Synchronization)
Description: Within the context of a single case (i.e., workflow instance) multiple instances of an activity can be created, i.e., there is a facility to spawn off new threads of control. Each of these threads of control is independent of other threads. Moreover, there is no need to synchronize these threads [1].
Synonyms: Multi threading without synchronization, Spawn off facility.
IBM WebSphere Integration Developer supports this pattern in the way that an <invoke> construct can be placed inside a <while loop> construct as shown in figure 10 and asynchronously call new instances of a service which are independent of each other and do not respond to the call. Although all instances are created asynchronously, they are all but sequential as they are created in succession by the <while loop> construct.
illustration not visible in this excerpt
Figure 10: Multiple Instances Without Synchronization
Pattern 13 (Multiple Instances With a Priori Design Time Knowledge)
Description: For one process instance an activity is enabled multiple times. The number of instances of a given activity for a given process instance is known at design time. Once all instances are completed some other activity needs to be started [1].
Synonyms: -
IBM WebSphere Integration Developer supports this pattern by adding as much <invoke> constructs as needed into the body of a <parallel activities> construct. Figure 11 shows an example. Each <invoke> construct enables the same activity. In this way, the number of activated process instances is fixed.
All <invoke> activities should be a synchronous (request/response) operation in order to ensure that the <assign> activity is executed after all created instances have completed. Once all <invoke> constructs have been processed, the <parallel activities> construct finishes and the <assign> activity is started.
There is a <for-each> construct available in WS-BPEL that can be used in future releases of IBM WebSphere Integration Developer to implement this pattern.
illustration not visible in this excerpt
Figure 11: Multiple Instances With a Priori Design Time Knowledge
Pattern 14 (Multiple Instances With a Priori Runtime Knowledge)
Description: For one case an activity is enabled multiple times. The number of instances of a given activity for a given case varies and may depend on characteristics of the case or availability of resources, but is known at some stage during runtime, before the instances of that activity have to be created. Once all instances are completed some other activity needs to be started [1] .
Synonyms: -
IBM WebSphere Integration Developer does not support this pattern. The problem is that there is no function available which supports a variable quantity of branches in the body of a <parallel activity> construct.
A possible workaround could be to place an <invoke> construct within the body of a <while loop> as shown in figure 12 which corresponds to a serial execution and consequently is not exactly an implementation of the pattern. In this solution it is not possible to create multiple instances in parallel. The <invoke> activity has to be a synchronous (request/response) operation in order to ensure that the <assign> activity is executed after all created instances have completed.
There is a <for-each> construct available in WS-BPEL that can be used in future releases of IBM WebSphere Integration Developer to implement this pattern.
illustration not visible in this excerpt
Figure 12: Multiple Instances With a Priori Runtime Knowledge
Pattern 15 (Multiple Instances Without a Priori Runtime Knowledge)
Description: For one case an activity is enabled multiple times. The number of instances of a given activity for a given case is not known during design time, nor is it known at any stage during runtime, before the instances of that activity have to be created. Once all instances are completed some other activity needs to be started. The difference with pattern 14 (Multiple Instances With a Priori Runtime Knowledge) is that even while some of the instances are being executed or already completed, new ones can be created [1].
Synonyms: -
IBM WebSphere Integration Developer offers no direct support for this pattern but a possible workaround can be implemented by using the <receive choice> construct and <while loop> activities as shown in figure 13. <Receive choice> uses the pick construct provided by BPEL together with a message handler (onMessage) that waits for messages from a particular partner [2]. <Receive choice> will complete as soon as the message handler´s activity has finished and it is included in a <while loop> construct which repeats the <receive choice> activity until a the variable ‘execute’ evaluates to false. This <while loop> ensures that even while some of the instances have already been started, new messages can arrive and yet other instances can be invoked later on.
The operation in <ReceiveChoice> contains another <while loop> which repeats the <invoke> activity as many times as needed for the given case. The <invoke> activity has to be a synchronous (request/response) operation in order to ensure that <Assign> is executed after all created instances have completed.
As the <invoke> construct is included in a <while loop>, this implementation corresponds to a serial execution and the services get invoked in succession.
There is a <for-each> construct available in WS-BPEL that can be used in future releases of IBM WebSphere Integration Developer to implement this pattern.
illustration not visible in this excerpt
Figure 13: Multiple Instances Without a Priori Runtime Knowledge
2.5 State-based Patterns
Pattern 16 (Deferred Choice)
Description: A point in the workflow process where one of several branches is chosen. In contrast to the XOR-split, the choice is not made explicitly (e.g. based on data or a decision) but several alternatives are offered to the environment. However, in contrast to the AND-split, only one of the alternatives is executed. This means that once the environment activates one of the branches the other alternative branches are withdrawn. It is important to note that the choice is delayed until the processing in one of the alternative branches is actually started, i.e. the moment of choice is as late as possible [1].
Synonyms: -
IBM WebSphere Integration Developer supports this pattern by using the <receive choice> construct as shown in figure 14. <Receive choice> uses the pick construct provided by BPEL together with a message handler (onMessage) that waits for messages from a particular partner [2]. <Receive choice> derives a message and starts the operation <Receive1> which handles the message. <Receive1> contains a <choice> construct with a couple of cases whose branches are executed based on the content of the message received by <ReceiveChoice>. By using the <choice> construct it is guaranteed that only one of the alternatives gets processed. An additional <choice> construct may be needed and is used in this example because the <receive choice> construct distinguishes between the types of the message or rather different variables and is not able to process the content of a message and the value of a variable respectively.
illustration not visible in this excerpt
Figure 14: Deferred Choice
Pattern 17 (Interleaved Parallel Routing)
Description: A set of activities is executed in an arbitrary order: Each activity in the set is executed, the order is decided at run-time, and no two activities are executed at the same moment (i.e. no two activities are active for the same workflow instance at the same time) [1].
Synonyms: Unordered sequence.
IBM WebSphere Integration Developer does not support this pattern. The problem is to process activities in a random order.
A possible workaround to this pattern is to define the order of execution and to create a sequence of activities (Pattern 1). As the activities should be executed in an arbitrary order and may not be executed in parallel, it might be an adoptable solution to use only one of the possible sequences. However this solution is not an accurate implementation of the Interleaved Parallel Routing Pattern.
A possible but very complex solution is to use a sequence for every possible order of the activities as cases in a <choice> construct. Before an execution of a branch one sequence has to be selected due to the value of a variable. This is a combination of the sequence and the exclusive choice pattern.
Alternatively you can use a sequence for every possible order of the activities inside a <parallel activities> construct. Every branch must have a transition condition that is disjunct to the other ones to ensure that only one branch is executed. The problem is to select the appropriate sequence and to choose the values of the variables used in the transition conditions respectively. In addition to that, the implementation might become very complex because every possible sequence of actions has to be available and must be created at design time.
An adequate solution is to pass an array that contains the order of execution and to use a <while loop> which successively processes the activities as shown in figure 15. The <while loop> continues as many times as there are <assign> activities in the <choice> construct. In every cycle of the loop, the <Assign> activity picks a value out of the array and copies it into a variable. After this the corresponding <assign> activity in the <choice> construct is executed.
illustration not visible in this excerpt
Figure 15: Interleaved Parallel Routing
Pattern 18 (Milestone)
Description: The enabling of an activity depends on the case being in a specified state, i.e. the activity is only enabled if a certain milestone has been reached which did not expire yet. Consider three activities named A, B, and C. Activity A is only enabled if activity B has been executed and C has not been executed yet, i.e. A is not enabled before the execution of B and A is not enabled after the execution of C. The state in between B and C is modeled by place m. This place is a milestone for A [1].
Synonyms: Test arc, deadline, state condition, withdraw message.
IBM WebSphere Integration Developer supports this pattern by using the <receive choice> construct inside a <while loop> activity as shown in figure 16. The first <assign> activity corresponds to activity B and sets the value of a boolean variable named ‘milestone’ to true. The <while loop> construct repeats the activities inside of it until the variable ‘milestone’ evaluates to false. In an analogous manner as in pattern 16 (Deferred Choice), <ReceiveChoice> derives a message and starts the operation <Receive> which contains a <choice> construct with two cases whose branches are executed based on the content of the message received by <ReceiveChoice>. If <Case1> is the chosen branch, the <empty action> construct that correspond to activity A is executed and the <while loop> activity continues. If <Case2> is the chosen one, the <assign> activity is executed which sets the value of the variable ‘milestone’ to false and through this stops the loop. After the <while loop> activity has completed, the <assign> activity which corresponds to activity C is executed.
illustration not visible in this excerpt
Figure 16: Milestone
2.6 Cancellation Patterns
Pattern 19 (Cancel Activity)
Description: An enabled activity is disabled, i.e. a thread waiting for the execution of an activity is removed [1].
Synonyms: Withdraw activity.
IBM WebSphere Integration Developer supports this pattern by means of the <terminate> construct in an event handler attached to the activity that should be terminated. The event handler is executed through an external message and the <terminate> activity instantly stops the activity. The process receives the message concurrently with the normal activity of the scope to which the event handler is attached whereby the events can arise at any time.
illustration not visible in this excerpt
Figure 17: Cancel Activity
Pattern 20 (Cancel Case)
Description: A case, i.e. workflow instance, is removed completely (i.e., even if parts of the process are instantiated multiple times, all descendants are removed) [1].
Synonyms: Withdraw case.
IBM WebSphere Integration Developer supports this pattern by means of the <terminate> construct in an event handler attached to the whole process. The event handler is executed through an external message and the <terminate> activity instantly stops the business process instance. The process receives the message concurrently with the normal activity of the scope to which the event handler is attached whereby the events can arise at any time.
The process instance is explicitly terminated by the <terminate> activity. In this case the termination is abnormal in comparison to pattern 11 (Implicit Termination).
illustration not visible in this excerpt
Figure 18: Cancel Case
[...]