Page 2 of 2   « previous page

WLI 8.1 cannot easily model the 2-of-3 security clearance example, or any other N-of-M where N>1. The language is limited: the parallel join condition is not sophisticated enough to select, say, two branches. BPEL is no better off, lacking even basic OR join capability that could satisfy Discriminator. (BPEL has an OR join, but it waits for each inbound path to complete, whereas the WLI 8.1 join accepts the first inbound path and discards the others.) The easiest way to implement the search engine example in BPEL is to run the searches in separate processes (Listing 3) that perform the work (line 3) and publish an event to announce when they are done (line 4). The main process (Listing 2) spawns the subprocesses asynchronously (the "invoke" statements in lines 2 and 3) and waits for the first of the completion events to arrive (the "receive" in line 4).

The BPEL implementation of the security clearance example, shown in Listing 4, is similar: spawn (lines 2-5) the three checks as subprocesses, and wait for any two to complete (lines 5-6). WLI 8.1 could follow this approach too, perhaps using Message Broker subscriptions to catch the events.

Interleaved Parallel Routing: Supported by BPEL Only
Interleaved Parallel Routing is an unusual pattern in which several activities are to be performed in an order that is indeterminate at design time. The activities are performed in sequence (not in parallel, as the name of the pattern suggests), but the order of execution is arbitrary. Interleaved Parallel Routing is a type of ad hoc processing, though ad hoc includes cases that are even more monstrous, where there is no clear-cut distinction between parallel and sequential, and execution is determined by the performing actors (e.g., the work of a software developer on a typical project, whose job might be to develop three components, contribute two sections to the architecture document, and set up a stand-alone test environment for the development group).

For a good example of Interleaved Parallel Routing, consider the case in which an applicant to the army must take three tests - dental, medical, and optical - one after the other, but in any order; when the applicant completes one test, the next one to take is determined by the availability of doctors (example suggested in Reference #6, p.10).

The WLI 8.1 implementation is a combinatorial mess! The overall process, shown in Figure 4, starts with an Event Choice with separate paths for Dental, Optical, and Medical. The Dental event means that the applicant has been called in for a dental examination; the applicant responds by attending the examination (Attend Dental), before entering an inner Event Choice (shown collapsed in Figure 4), which models the remaining two appointments. The paths for medical and optical have the same form as dental. Figure 5 shows the expanded Event Choice structures for the three top-level choices. If the first choice had been dental, the next choice is between medical and optical. If called for medical, the applicant attends the medical appointment, and then waits to be called for the optical; if called for optical, the applicant attends the optical and waits for the medical.

In total, six paths are required to model the permutations of dental, medical, and optical. If there had been four activities, 24 paths would have been needed; if five activities, 124 paths. Messy indeed! Alternative implementations should be considered on a case-by-case basis.

BPEL, probably by accident rather than by design, has an elegant, linear solution. The idea is to place the activities in a parallel structure (the "flow" activity in lines 5-27 of Listing 5), but to force each activity to acquire a mutually exclusive, shared variable (defined in line 3) before running. The effect is that the activities run sequentially, but in indeterminate order. The key to this maneuver is the variableAccessSerializable flag in lines 6, 13, and 20, which ensures, in effect, that as soon as one of the scoped activities (optical in lines 6-12, dental in lines 13-19, medical in lines 20-26) accesses the variable, the others are locked out until the activity has completed.

In the BPEL approach the order of activities is effectively random, determined by the proprietary low-level logic of the BPEL engine. This approach is not suitable for cases in which order is to be driven by application logic or external stimuli.

WLI 8.1 Scorecard
Table 1 provides the scorecard for WLI 8.1 on the 20 patterns. Following the style of the workflowpatterns.com authors, the table uses the symbol "+" to indicate that the language fundamentally supports the given pattern, "+-" to indicate that the language supports the pattern with straightforward coding, and "-" to indicate that the pattern is either hard or impossible to implement in the language. Counting both + and +-, both WLI 8.1 and BPEL score 14.

Summary
BPEL and WLI 8.1 score differently on support for the 20 process patterns documented on the renowned site www.workflowpatterns.com. Some patterns are supported by both, some by neither, some by BPEL but not WLI 8.1, and some by WLI 8.1 but not by BPEL.

References

• www.workflowpatterns.com (this site also includes links to several key papers)
• http://e-docs.bea.com/wli/docs81/index.html
• T. Andrews, M. Curbera, et al. "Business Process Execution Language for Web Services," Version 1.1. www.oasis-open.org, May 2004. [Available at the following URLs:
  http://dev2dev.bea.com/technologies/webservices/BPEL4WS.jsp (BEA),
  www-106.ibm.com/developerworks/webservices/library/ws-bpel/ (IBM),
  http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/dnbiz2k2/html/bpel1-1.asp (Microsoft), http://ifr.sap.com/bpel4ws/ (SAP),
  www.siebel.com/bpel (Siebel).]
• Michael Havey, Essential Business Process Modeling, O'Reilly Media, 2005, Cambridge, MA. www.oreilly.com/catalog/essentialpm. Descriptions of the patterns in this article are based on material from this book.
• P. Wohed, W. van der Aalst, M. Dumas, A.H.M. ter Hofstede. "Pattern Based Analysis of BPEL4WS," FIT Technical Report, FIT-TR-2002-04.
• M. Dumas and A.H.M. ter Hofstede, "UML Activity Diagrams as a Workflow Language," in Proceedings of the International Conference on the Unified Modeling Language, Springer-Verlag, Toronto, Canada, October 2001.

Page 2 of 2   « previous page