Workflow Control-Flow Pattern Support

The second part of the benchmark of BPEL engines is formed by the patterns test suite described in Sect. 3.2.3.2. Table 3.9 shows the results of this benchmark

using the trivalent rating of direct support (+), partial support (+/-), and no direct support (-). The second column lists the highest degree of direct support for a pattern that can be achieved in standard BPEL. Patterns that cannot directly be implemented using standard BPEL, as discussed in Sect. 3.2.3.2, are omitted in the table. The last two rows show the percentages of the amount of times the engines achieve the same support rating as the BPEL standard.

Table 3.9.: Workflow Control-Flow Patterns Support By Engine Comm. Eng. Open Source Engines

Pattern BPEL E1 E2 E3 bpel-g ODE Op.ESB Orch. Pet. Basic Control-Flow Patterns

P01 Sequence + + + + + + + + +

P02 Parallel Split + + + + + + + + +

P03 Synchronization + + + + + + + + +

P04 Exlusive Choice + + + + + + + + +

P05 Simple Merge + + + + + + + + +

Advanced Branching and Synchronization Patterns

P06 Multi-Choice + + + + + + +/- + +/- P07 Synchronizing Merge + + + + + + +/- + +/- Structural Patterns

P11 Implicit Termination + + + + + + + + + Patterns with Multiple Instances

P12 MI Without Sync. + + + +/- + + +/- +/- +/- P13 MI W. Design T. Know. + + + - + + +/- +/- +/- P14 MI W. Runtime Know. + + + - + + - - - State-based Patterns

P16 Deferred Choice + + + + + + + + +

P17 Interl. Parallel Routing +/- +/- +/- +/- +/- +/- - - - P18 Milestone +/- +/- +/- +/- +/- +/- +/- - - Cancellation Patterns

P19 Cancel Activity +/- +/- +/- +/- +/- +/- +/- +/- +/-

P20 Cancel Case + + + + + + + + +

Percentage 100% 100% 81% 100% 100% 63% 69% 56% Ø Commerical bpel-g, ODE, OpenESB Open Source

94% 88% 72%

The percentage values are relatively high, i. e., many engines support the pattern implementations we test for. In particular, four engines, two commercial and two open source ones, successfully support all control-flow patterns to the same degree as the BPEL standard. These are E1, E2, bpel-g, and Apache ODE. The remaining engines vary from 56% of pattern support to 81%. As before, several open source engines show a relatively small degree of support when compared to their commercial counterparts. Nevertheless, a lower degree of pattern support could have been expected for all engines, considering the results of the benchmark of standard conformance from the previous section.

All engines provide the same degree of support as BPEL for the basic control- flow patterns (WCP01–WCP05), the Implicit Termination structural pattern (WCP16), and the cancellation patterns (WCP19/20). In three cases, several engines partially support a pattern, which in standard BPEL is fully supported.

Finally, five patterns are not directly supported by at least one engine. The highest amount of differences lies in the category of multi-instance patterns. Here, in only half of the cases, the engines have the same degree of support as BPEL. For two of the patterns in this category, WCP12 and WCP13, three of the open source engines only support a workaround solution that grants partial support, but not a direct solution that is possible in standard BPEL. Moreover, the same engines fail to directly support the Multiple Instances With a Priori Runtime Knowledge pattern (WCP14). The commercial engine E3 also only supports WCP12 partially and fails to support the remaining multi-instance patterns. The three open source engines mentioned before fail the tests for the Interleaved Parallel Routing pattern (WCP17) and two of them do not pass the tests for the Milestone pattern (WCP18). When it comes to advanced branching and synchronization patterns, support is in place for all engines, although two open source engines only support the patterns using a workaround solution. All in all, the least supported pattern is the Multiple Instances With a Priori Runtime Knowledge pattern (WCP14), which is unsupported by half of the engines.

Interestingly, the sets of patterns for which open source and commercial engines achieve a lower degree of support than standard BPEL are almost disjoint. In comparison, commercial engines support more workflow control-flow patterns (94%) than open source engines (72%). Similar to the benchmark for standard conformance, this difference shrinks to an insignificant level (94% vs. 88%) when comparing only commercial and the three highest-ranking open source engines. By looking at the detailed results of the tests, it becomes obvious that failures in pattern support are not caused by added issues that arise through the combination

of language constructs. Reasons

for lack of support Instead, in all cases of failure, a pattern implementation

does not work correctly, because a single language feature is not supported as specified in the BPEL standard. Strictly speaking, all issues have already been discovered by the standard conformance benchmark discussed in the previous section. In six cases of failure, a pattern implementation does not work, because an engine does not fully support links in the flow activity. In three cases, support for the forEach activity is required and in nine cases also parallel execution of the activities contained therein. Finally, in two cases, engines do not provide proper support for required message correlation and in a single case, support for isolated scopes is missing. This demonstrates that standard-conformant implementations of the flow and forEach activities are crucial for pattern support. Put differently, a lack of truly parallel execution in an engine is the biggest obstacle to pattern support. Still, the impact of standard conformance on pattern support is little. For instance, Apache ODE, which passes only two thirds of the conformance tests, supports all workflow patterns that can be directly implemented in BPEL. Even the worst engine in terms of standard conformance, Petals, provides direct or partial support for 13 out of 16 patterns. The results of this section can be summarized as follows: workflow control-flow patterns can be implemented directly with only a moderate degree of standard conformance, but support for concurrent execution of activities is the decisive factor.