Microservices Expo Authors: TJ Randall, Liz McMillan, Elizabeth White, Pat Romanski, AppDynamics Blog

Related Topics: Microservices Expo

Microservices Expo: Article

The Flesh and Bone of SOA

BPEL & Role Activity Diagrams

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
To understand the style of human workflow that RAD offers, consider the design-engineering example shown in Figure 1. In this process, a product manager (for a car maker, let's say) collaborates with designers. The manager documents the basic product design concept (e.g., "I want a car that can transform into a helicopter to escape traffic"), assigns to one or more designers the task of writing a detailed design, and reviews each design, deciding for each whether to accept or reject (e.g., reject the design for the car whose fuel task might explode). The notation is intuitive, even for newcomers to RAD. Manager and Designer, shown as large outer boxes, are roles. There is one manager but there can be multiple designers, shown as a stack of outer boxes. A role can instantiate, or allocate work to, another role; the manager role instantiates a designer in the small box labeled Start Designer Role. Interactions between manager and designer are shown as lines that connect small white boxes in each role. Individual tasks are small shaded boxes within a role (Prepare Design Concept in Manager and Do Design in Designer, for example). Ovals represent state; Have Design Brief, for example, means the manager has now reached the state of having completed the design brief. Iteration is shown with a windmill symbol; the logic coming below Design Received is the manager's review of the designs from each designer. Refinement (a form or conditional or parallel branching) is shown as an inverted triangle; there are acceptance and rejection paths to deal with a design that has been accepted or rejected. (The notation is Harrison-Broninski's enhancement of Martyn Ould's classic RAD notation.)

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!

Radish BPEL
Actually, our goal isn't to build pure conformant RAD in BPEL, but to embrace the spirit of RAD and build a RAD-ish BPEL, as if BPEL were a salad and we decided to toss in a pungent ingredient. There's nothing preposterous about this mixture. Every bank has jumped on the SOA bandwagon; BPEL or some similar BPM technology is in every bank's technology stack. But you'll find many other kinds of components too. Don't assume the architecture is accidental. Complex requirements necessitate curious technology choices. If you see RAD on BPEL, take the architect at face value when she explains: We're an SOA shop, but we need RAD for our most complex human work.

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.

More Stories By Michael Havey

Michael Havey is a Chordiant consultant with 10 years of industry experience, mostly with application integration. Michael's book Essential Business Process Modeling was published by O'Reilly in August 2005.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Microservices Articles
At its core DevOps is all about collaboration. The lines of communication must be opened and it takes some effort to ensure that they stay that way. It’s easy to pay lip service to trends and talk about implementing new methodologies, but without action, real benefits cannot be realized. Success requires planning, advocates empowered to effect change, and, of course, the right tooling. To bring about a cultural shift it’s important to share challenges. In simple terms, ensuring that everyone k...
Is advanced scheduling in Kubernetes achievable?Yes, however, how do you properly accommodate every real-life scenario that a Kubernetes user might encounter? How do you leverage advanced scheduling techniques to shape and describe each scenario in easy-to-use rules and configurations? In his session at @DevOpsSummit at 21st Cloud Expo, Oleg Chunikhin, CTO at Kublr, answered these questions and demonstrated techniques for implementing advanced scheduling. For example, using spot instances and co...
Today most companies are adopting or evaluating container technology - Docker in particular - to speed up application deployment, drive down cost, ease management and make application delivery more flexible overall. As with most new architectures, this dream takes significant work to become a reality. Even when you do get your application componentized enough and packaged properly, there are still challenges for DevOps teams to making the shift to continuous delivery and achieving that reducti...
Skeuomorphism usually means retaining existing design cues in something new that doesn’t actually need them. However, the concept of skeuomorphism can be thought of as relating more broadly to applying existing patterns to new technologies that, in fact, cry out for new approaches. In his session at DevOps Summit, Gordon Haff, Senior Cloud Strategy Marketing and Evangelism Manager at Red Hat, discussed why containers should be paired with new architectural practices such as microservices rathe...
With the rise of Docker, Kubernetes, and other container technologies, the growth of microservices has skyrocketed among dev teams looking to innovate on a faster release cycle. This has enabled teams to finally realize their DevOps goals to ship and iterate quickly in a continuous delivery model. Why containers are growing in popularity is no surprise — they’re extremely easy to spin up or down, but come with an unforeseen issue. However, without the right foresight, DevOps and IT teams may lo...
Kubernetes is a new and revolutionary open-sourced system for managing containers across multiple hosts in a cluster. Ansible is a simple IT automation tool for just about any requirement for reproducible environments. In his session at @DevOpsSummit at 18th Cloud Expo, Patrick Galbraith, a principal engineer at HPE, will discuss how to build a fully functional Kubernetes cluster on a number of virtual machines or bare-metal hosts. Also included will be a brief demonstration of running a Galer...
DevOps is under attack because developers don’t want to mess with infrastructure. They will happily own their code into production, but want to use platforms instead of raw automation. That’s changing the landscape that we understand as DevOps with both architecture concepts (CloudNative) and process redefinition (SRE). Rob Hirschfeld’s recent work in Kubernetes operations has led to the conclusion that containers and related platforms have changed the way we should be thinking about DevOps and...
In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, will discuss how to use Kubernetes to setup a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace....
"There is a huge interest in Kubernetes. People are now starting to use Kubernetes and implement it," stated Sebastian Scheele, co-founder of Loodse, in this SYS-CON.tv interview at DevOps at 19th Cloud Expo, held November 1-3, 2016, at the Santa Clara Convention Center in Santa Clara, CA.
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is foundational - something customers routinely cite as a top pain point. In his session at @DevOpsSummit at 21st Cloud Expo, Bill Borsari, Head of Systems Engineering at Datera, explored how organizations can reap the bene...