The Flesh and Bone of SOA
BPEL & Role Activity Diagrams
By: Michael Havey
Jun. 6, 2007 05:45 PM
Over the years business processes have become automated to the point that the BPM community now considers the SOA language BPEL, designed for the orchestration of Web Services, as the best platform for building contemporary processes. But many processes retain some level of human activity, and BPEL's support for human interaction is problematic. Most attempts to integrate human workflow with BPEL, such as BPEL4People (as well as proprietary task subsystems offered by the major BPM vendors), try to fit human activities into BPEL's execution model. Human tasks are simply special steps in the larger process.
But people don't work that way, argues Keith Harrison-Broninski in his book Human Interactions: The Heart and Soul of Business Process Management. Their work is complex and ad hoc; they interleave their tasks and adapt how they work as business rules change. Harrison-Broninski proposes Role Activity Diagrams (RAD) as the best way to model human workflow, and dismisses BPEL as an impossible fit.
Harrison-Broninski intentionally poses examples (design, sales, marketing, strategy) that are almost exclusively manual, involving little or no system integration, for which the RAD modeling technique is ideal. But what about processes that involve a mixture of human and automated activity, processes whose automation requirements are well served by BPEL? This article makes the bold claim (an anathema for Harrison-Broninski) that BPEL can model these hybrid processes, that it can accommodate complex RAD-style human workflow in a larger orchestration! Our example is the credit card disputes process of fictional ACMEBank. ACME has been sold on BPEL, Web Services, and business rules technology, but needs a RAD-style of human interaction to support its disputes specialists, who, as we'll see below, use the occasion to employ curious upsell techniques.
A Radically Different Example
An impatient BPEL developer who saw the diagram but did not understand its nuances might quickly whip up the process shown in Figure 2, a screen capture from the Oracle JDeveloper graphical BPEL editor for Oracle's BPEL Process Manager engine. The process uses a while activity to model iteration (the cycle symbol just below designComplete), switch for refinement (the question mark symbol below the cycle symbol), sequence for activities that in RAD appear to follow each other in succession (e.g., prepareDesignConcept is followed in sequence by enterDesignBrief), and partner links to show interactions between roles (this process has the perspective of the manager role, and DesignerRole is its partner).
If RAD were really that simple, there wouldn't be much point in talking about it. As it turns out, the naive BPEL process from Figure 2 is completely wrong! Recognizing this is the first step in understanding RAD.
Although the RAD diagram appears to have rigid control structures like loops, branches, and sequences, it's fundamentally adaptive. The person performing a role isn't bound to execute tasks in order, to stay on a particular branch, or to perform iterations of a loop in succession. The control flow implied by the diagram is merely a guide, an archetype. The manager might, for example, approve a design, then change his mind and add it to the rejection list, or prepare the design concept and enter the design brief simultaneously. Furthermore, the manager isn't bound to assess the designs one at a time, but may, for example, examine two similar designs at once, or defer the more complex designs and work on the easier ones first. The initial BPEL process has none of this flexibility.
As a contrast to the rigidity of the BPEL example, consider the ineffectual approach of Business Process Modeling Notation (BPMN), the leading standard process modeling notation, which advertises support for the modeling of ad hoc processes and, moreover, defines an overall mapping to BPEL. Figure 3 depicts how we might model in BPMN the manager role of the design process. The process (whose outer box is marked with a tilde, designating Ad Hoc) has six tasks, but there's no flow connecting them. Execution is up to the manager. The diagram has two shortcomings. First, unlike RAD, it provides no archetypal control flow. There's no explicit notion of iteration or refinement; it doesn't make explicit that there are multiple designs to assess, and that approved designs are treated differently than rejected designs. The second shortcoming is a showstopper: the diagram has no obvious mapping to BPEL; the BPMN specification admits that there can be no general mapping of ad hoc processes. In other words, we can't model the process very effectively, and we can't map it to BPEL anyway.
The BPMN diagram in Error! Reference source not found (see Figure 4) is much more expressive: it conveys archetypal control flow, but, being designated as ad hoc, allows the manager the flexibility to stray from the archetype. Unfortunately, this diagram is not valid BPMN (an ad hoc process may not have explicit sequence flow), and even if it were, the BPMN specification wouldn't provide a BPEL mapping for it. But let's do something audacious and adventurous: let's cheat and allow this enhanced BPMN notation; and let's demonstrate that this sort of notation REALLY CAN be mapped to BPEL!
ACMEBank is no exception. Recently ACME built a straightforward disputes process on BPEL similar to the disputes processes of its competitors. But they're not done! ACME has discovered through analysis of past disputes cases that when "high-value" customers call in to report a dispute and are treated favorably, they are much more likely to accept sales offers. The psychological explanation is that disputable charges make customers feel anxious, and they see their bank as an ally in the battle against the merchant. If the customer has deep pockets, why not seize the opportunity to sell products? But the manner in which the disputes specialist should present offers is extremely subtle, and is difficult to model in vanilla BPEL. ACME gets enough disputes from high-value customers to think there's a business case to build complex RAD-style sales decision logic in BPEL.
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week