Integration

Digg This!

Page 1 of 2   next page »

Every aircraft can take off, fly straight, and land, but few are capable of the dazzling rolls and loops displayed at air shows. When judged on aerobatics, some airplanes are superior to others.

Every BPM process language, analogously, can implement basic sequential control flow, but most languages struggle to support the most advanced splits, joins, loops, and synchronizations. These process maneuvers are known as patterns; like an aerial maneuver through thin air, a process pattern is a kind of movement through a business process, modeled as a particular arrangement of activities.

The Web site www.workflowpatterns.com, created by computer scientists specializing in BPM, is the foremost source of material on process patterns. The two most distinctive features of this site are a catalog of 20 patterns and ratings of numerous standard and vendor-specific process languages on their support for the catalog. Business Process Execution Language (BPEL), the most popular process language, gets a very high score, supporting 14 of the 20 patterns according to the site's analysts. (If you look at the other scorecards, you will see that 70 percent is a comparatively good grade!)

BPEL's glowing scorecard bodes well for WebLogic Integration (WLI), which, starting with version 8.5, will adopt BPEL as its process language. However, what about the large installed base of processes deployed on WLI 8.1, whose process language, Process Definition for Java (PD4J), is not rated on the site? This article compares the pattern capabilities of BPEL and WLI 8.1. Four patterns are considered in detail:

• Cancel Case, supported by both
• Milestone, supported by neither
• Discriminator, supported only by WLI 8.1
• Interleaved Parallel Routing, supported only by BPEL

This article also presents a complete scorecard for WLI 8.1.

Cancel Case: Supported by Both
The intent of the Cancel Case pattern is to stop a running process, no matter where it is in its execution, on receipt of a cancellation event (e.g., rescind the processing of an insurance claim while it is under investigation). Most BPM vendor implementations offer a system-management function that allows administrators to abort errant processes, but this pattern requires that the cancellation logic, which may well have crucial business significance, be embedded into the process model itself.

For a process language to support Cancel Case, it must have the ability to listen for events in a path that is separate from the mainline path. WLI 8.1 supports this by allowing a message path to be associated with a process or activity. The process shown in Figure 1, for example, is always prepared to respond to a Cancel Event, regardless of how far (Step 1, Step 2, or Step 3) the main logic has progressed. When it receives the cancellation event, the process cleans up (Cleanup) and exits (Finish).

BPEL, which permits an event handler to be associated with a process or a child activity, has a similar implementation.

In Listing 1, the process registers an event handler (lines 2-6) that on receipt of cancelEvent stops the process by terminating it. The handler can interrupt with main logic (lines 7-9) at any time.

(Note: In this article, BPEL samples are shown as XML-based source code, whereas WLI 8.1 examples are shown in the graphical representation adopted by WebLogic Workshop. BPEL does not have a standard graphical representation. WLI 8.1's PD4J does have an XML encoding, but most readers are more familiar and comfortable with Workshop's graphical view.)

Milestone: Supported by Neither
In the Milestone pattern an activity can be performed only when a certain milestone is reached and cannot be performed after the milestone expires. Put differently, an activity can run any number of times between the occurrences of enabling and disabling events. For example, in an auction, a bidder can place a bid any number of times between the start and end of bidding. Few process languages support this distinctive pattern directly. In WLI 8.1, elaborate design is required, demonstrated by the bidding process shown in Figure 2. The process begins with the enabling event Open Bidding, after which it sets a Boolean flag to true (in the Perform node Set Bidding Open) to indicate that bidding is enabled. The heart of the process is a complicated while loop whose condition checks the Boolean flag to determine whether to continue; the loop runs for as long as the flag is set to true. The while loop contains an Event Choice with two event paths: one representing a bid (Bid), the other representing the disabling event Close Bidding. When Close Bidding occurs, the process calls a Perform node (Set Bidding Closed) to clear the flag, which will break the loop before its next iteration.

The logic successfully satisfies the requirement that the Bid event can occur any number of times until the Close Bidding event occurs. However the implementation is far too complicated to get a passing grade on the scorecard; the language lacks features that would make the implementation easy.

BPEL's implementation of this example, described in the paper "Pattern Based Analysis of BPEL4WS" (Reference #5), is nearly identical, using a Boolean flag, a while loop, and a "pick" (BPEL's equivalent of an Event Choice) to model the milestone logic.

Discriminator: Supported by WLI 8.1
In the Discriminator pattern, when multiple parallel branches converge at a given join point, exactly one of the branches is allowed to continue on in the process, based on a condition evaluated at run time; the remaining branches are blocked. Discriminator is a special case of the N-of-M Join pattern, where M parallel branches meet at a point of convergence and only the first N are let through; in Discriminator, N=1.

The need for this pattern arises when only a subset of assigned work in required. For example:

• In order to obtain a security clearance, an applicant must demonstrate two of the following three criteria: good credit, no criminal record, and natural citizenship (2-of-3)
• A complicated Web search is submitted to two search engines; as soon as one engine completes, its results are collected and the other search is ignored (1-of-2, or Discriminator).

Interestingly, WLI 8.1 supports Discriminator out of the box, but has excessive difficulty with the more general N-of-M. The search engine example of Discriminator is shown in Figure 3. In separate branches in a parallel structure, a search is submitted to two engines (Search Engine 1 and Search Engine 2). The parallel structure is set with an OR join condition (shown as parallel bars in the circle at the bottom of the parallel structure), so that as soon as one engine completes, the parallel structure itself completes, and control is passed to the next activity, Present Search Results.

Page 1 of 2   next page »