Pattern-based Evaluation of IBM WebSphere BPEL

Studienarbeit von Volker Kramberg

Abstract:

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. activities are mostly used as placeholders for comprehensive business logic and if this is not the case, they are explained in detail.

Table of Contents:

1.	Introduction	1
2.	Evaluation of control-flow patterns in IBM WebSphere Integration Developer	2
2.1	Basic Control Flow Patterns	2
	Pattern 1 (Sequence)	2
	Pattern 2 (Parallel Split)	2
	Pattern 3 (Synchronization)	3
	Pattern 4 (Exclusive Choice)	4
	Pattern 5 (Simple Merge)	6
2.2	Advanced Branching and Synchronization Patterns	7
	Pattern 6 (Multi-choice)	7
	Pattern 7 (Synchronizing Merge)	8
	Pattern 8 (Multi-merge)	8
	Pattern 9 (Discriminator)	9
2.3	Structural Patterns	10
	Pattern 10 (Arbitrary Cycles)	10
	Pattern 11 (Implicit Termination)	11
2.4	Patterns involving Multiple Instances	11
	Pattern 12 (Multiple Instances without Synchronization)	11
	Pattern 13 (Multiple Instances with a Priori Design Time Knowledge)	12
	Pattern 14 (Multiple Instances with a Priori Runtime Knowledge)	13
	Pattern 15 (Multiple Instances without a Priori Runtime Knowledge)	14
2.5	State-based Patterns	16
	Pattern 16 (Deferred Choice)	16
	Pattern 17 (Interleaved Parallel Routing)	17
	Pattern 18 (Milestone)	19
2.6	Cancellation Patterns	20
	Pattern 19 (Cancel Activity)	20
	Pattern 20 (Cancel Case)	21
3	Summary	23
	References	26

Text Sample:

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.

Synonyms: Synchronizing join.

Corresponding to pattern 6 (Multi-choice) IBM WebSphere Integration Developer supports this pattern by means of the 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 construct avoids the problem to decide in which case to synchronize and in which one to merge. The 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 activity sets a counter to zero and there are multiple branches inside the construct. Every branch contains an construct which is needed to provide the following activity with a transition condition. The transition conditions do not have to be disjunctive and several activities may be executed concurrently. The activity that represents the workflow is linked with another activity which increases the counter. Finally 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 construct was activated.

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).

Synonyms: - IBM WebSphere Integration Developer supports this pattern. Figure 9 shows an example of a possible implementation. The construct contains multiple activites that are all linked to an 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 is processed for one incoming link but nonrecurring as the workflow engine marks the activity as processed. The construct completes as soon as the activity has finished.