Microservices Expo Authors: Pat Romanski, Elizabeth White, Liz McMillan, Stackify Blog, Andreas Grabner

Related Topics: Microservices Expo

Microservices Expo: Article

The Promise of Portable Business Processes

The Promise of Portable Business Processes

The Business Process Execution Language for Web Services (BPEL4WS or BPEL for short) is an XML-based programming language/execution environment intended to enable portable business process definitions for WSDL-based business processes. BPEL's goal is to make it possible to write a business process once in BPEL and then run it everywhere.

As a Turing complete language BPEL can do, well, anything. Although it limits itself to features necessary for business processes this still requires an enormous number of capabilities. BPEL currently provides:

  • Two full programming models (graph and structured)
  • An exception model
  • Three types of storage
  • A threading model
  • A transaction model
  • A process life cycle-management model
  • A message-handling and routing model
That's a lot of functionality. This article provides an overview of BPEL. It will, therefore, be necessary to leave out a number of features and simplify a number of otherwise complex issues.

The Nature of Standards
As a new specification, BPEL has years of work ahead of it before it is sufficiently mature to be used for building portable implementations. In the meantime it is difficult to make categorical statements about BPEL as any one of its numerous open issues could cause significant changes in BPEL's functionality. As such, the reader is reminded that this article only represents the views and opinions of the author and not necessarily those of the other BPEL authors.

BPEL Execution Model:
The Big Picture

The core of BPEL is the process. A BPEL process is just like any other process providing standard facilities such as storage, threads, faults, etc.

Commands given in a BPEL process are called activities and the definition of a BPEL process consists of exactly one activity. Therefore, interesting BPEL processes tend to start with either the Sequence or Flow activities, both of which are containers of other activities.

A Sequence activity contains a list of activities that are to be executed serially. A Flow activity contains a list of activities that are each to be executed in their own threads. Threads may be executed in parallel but this isn't guaranteed; the BPEL implementation may choose to serialize execution. Sequence and Flow can contain any arbitrary set of activities in any order, including other Sequence and Flow activities. The control flow of a BPEL process is specified using an arbitrary combination of two programming models - structured and graph based.

Structured Programming
Structured programs are written using the Switch and While activities. Switch defines an ordered list of Boolean conditions, each associated with an activity. The first condition that evaluates to true has its activity executed. The While activity will loop and execute its associated activity until its Boolean expression evaluates to false. Creative use of the Switch and While activities can create the computational equivalent of common structured constructs such as if-then-else, for-each, until, etc.

Graph-Based Programming
Graph-based programming is typically created with a visual programming tool that displays activities on a screen and allows those activities to be connected via links. Links have Boolean expressions assigned to them called transition conditions. Boolean expressions associated with each activity, called join conditions, decide if an activity should execute based on the value of the transition conditions of the links that point at it.

For example, a join condition on a destination activity could be written to specify that the activity should only execute if all the links that point to it evaluate to false.

BPEL supports the graph paradigm by providing for links on all activities. Any activity can be linked to any other activity. This works across threads, structures, etc.

The combination of links, transition conditions, and join conditions is computationally equivalent to structured programs.

Boolean Expressions
Boolean expressions in BPEL are defined using XPATH 1.0 by default. BPEL provides a number of XPATH extension functions to enable access to information such as the value of a particular incoming link. However, the use of XPATH is a configurable option and can be overridden.

Containers & Assign
Containers are BPEL's answer to variables. They can only be defined at the global level and are globally visible. BPEL supports three types of containers - message containers, partner containers, and service reference containers. Partner containers will be discussed later; service reference containers will not be discussed in this article.

Message containers hold SOAP messages. They can either be created in a container by the BPEL process or they can be used to receive messages sent to the process. A message container's type is defined by a reference to a WSDL message definition.

The Assign activity is used to move XML between containers of the same type. XML fragments are moved between containers through the use of XPATH expressions with the Assign activity. The Assign activity can also move static XML into containers.

BPEL uses scopes to manage faults and compensation handlers. A new scope is declared by using the Scope activity that then contains the various handlers and a single activity.

BPEL faults are a combination of a unique name and an optional container. A BPEL process can throw a number of predefined faults or faults can be thrown by the Throw activity. A scope's fault handlers can catch faults based on the name of the fault, the type of container associated with the fault, or a combination of the two. Otherwise the BPEL fault handler provides typical features such as an optional "catch-all" fault handler, standard scope-based escalation for un-caught faults, and the ability of fault handlers to re-throw faults.

Compensation handlers are a convenience mechanism that associates activities that "undo" the actions in a scope with the scope.

For example, if a scope causes a reservation to be made at a restaurant then the compensation handler could contain activities that would send a message to cancel the reservation.

Compensation handlers are activated by a call to the Compensate activity, which can only be called from inside the fault handler or a compensation handler. When a compensation handler is run it must be shown the state of all containers as they were when the associated scope successfully exited. Any changes the compensation handler makes to the containers will be visible only to the compensation handler and will be discarded when the compensation handler exits.

The compensation handler's potentially unbounded memory requirements and isolated nature are open design issues that will be addressed in future versions of BPEL.

BPEL does not define an explicit subroutine or function call model. Rather, everything in BPEL is a Web service. Reusable functionality is packaged as a BPEL process which is then called as a Web service by other BPEL processes.

Message Processing
Messages are sent and received using the Receive, Reply, Pick, and Invoke activities. Messages are received by executing the Receive activity that takes a number of arguments, including port type, operation, partner container, correlations, and a message container.

Port type and operation refer to the definitions in an associated WSDL file. The partner container holds information about the Web service to which the message will be sent. The definition of partners is outside the scope of this article. Correlations are groups of XPATH expressions that are used to uniquely identify a message as part of a conversation. The message container is used to store the message when it arrives.

When the Receive activity is executed the associated thread will stop executing until the specified message is received. If the operation is a request/response then the Reply activity can be used to send back the response.

The Pick activity is used when one of a number of possible incoming messages may be sent. The Pick activity is the message equivalent of a Switch except that the conditions are Receives instead of Boolean expressions. Unlike the Receive activity, the Pick activity can have a time-out set on it.

The Invoke activity is used to send messages and, in the case of solicit/response, receive back a response. Invoke uses the same arguments as Receive but supports two message containers, one to hold the outgoing message and an optional second message container to handle the response. If Invoke should receive back a SOAP fault, that fault will be thrown as a BPEL fault with the SOAP message in the container.

Programming Language or Execution Environment?
BPEL's multiple programming models, terse syntax, and XML serialization do not lend themselves to direct programming. In other words, BPEL should be compared to the CLR or the JVM rather than to a programming language. It is easy to imagine writing a business process in some language/environment and then "compiling" the resulting program down into BPEL for execution.

BPEL and Java
BPEL is a procedural language for defining a message router that will enforce the choreography of a business process. But BPEL is not intended for generic data processing, UI generation, and so on. Therefore, it needs to be supplemented by Java, which is better suited for providing such behavior. At runtime BPEL will accept incoming messages and then route them to Java-backed Web services that will provide the heavy lifting. Java and BPEL form a team that enables the creation of complicated business processes in a platform-independent manner.

The Future of BPEL
The Web Services Choreography Interface (WSCI) provides a design and functionality that is almost identical to BPEL's. The most significant difference is that WSCI doesn't support graph-based programming.

It doesn't take a great leap of imagination to see WSCI and BPEL combining to form a single standard. I, and my company, believe that any official standard should be available on royalty-free terms through an open standards process.

There has been a great deal of discussion in the W3C Web Services Activity regarding the formation of a choreography working group that would take WSCI, BPEL, and possible other proposals as input. At the time of this writing, nothing final has been decided, though there certainly seems to be momentum toward this as the Web Services Architecture Working Group recommended standardization of choreography.

This article has only touched on the BPEL feature set at the highest possible level of abstraction. It discussed how to:

  • Process activities in sequence or in parallel
  • Program using a structured or graph-based paradigm
  • Store and manipulate XML values in containers
  • Define and nest scopes
  • Define, throw, and catch faults
  • Define and invoke compensation handlers
  • Use Web services as sub-routines and
  • Send and receive messages
I also touched on BPEL's similarity to the CLR/JVM, the relationship between BPL and Java, and BPEL's expected convergence with WSCI to form a single open, royalty-free standard.

Issues I did not discuss included BPEL's WSDL extensions (properties, property aliases, and service link types), properties in containers, serializable scopes, Wait activity, Empty activity, Terminate activity, partner definitions, service references, default compensation and fault handlers, start activities, and abstract processes.

In the years to come, as BPEL is more fully developed and standardized, the Web community can look forward to a robust standard for writing portable business process definitions.


  • BPEL4WS: http://dev2dev.bea.com/techtrack/BPEL4WS.jsp
  • WSCI: www.w3.org/TR/wsci

    Thanks to Bill Cox, David Orchard, and Ed Cobb for their constructive comments.

  • More Stories By Yaron Y. Goland

    Yaron Y. Goland is a senior principal technologist in the Office of the CTO at BEA, with responsibility for BP standards. Yaron is a coauthor on BPEL and BEA’s representative to the W3C Choreography Working Group.

    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
    In his session at 20th Cloud Expo, Scott Davis, CTO of Embotics, discussed how automation can provide the dynamic management required to cost-effectively deliver microservices and container solutions at scale. He also discussed how flexible automation is the key to effectively bridging and seamlessly coordinating both IT and developer needs for component orchestration across disparate clouds – an increasingly important requirement at today’s multi-cloud enterprise.
    While some developers care passionately about how data centers and clouds are architected, for most, it is only the end result that matters. To the majority of companies, technology exists to solve a business problem, and only delivers value when it is solving that problem. 2017 brings the mainstream adoption of containers for production workloads. In his session at 21st Cloud Expo, Ben McCormack, VP of Operations at Evernote, discussed how data centers of the future will be managed, how the p...
    In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, discussed how to use Kubernetes to set up 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. H...
    Most DevOps journeys involve several phases of maturity. Research shows that the inflection point where organizations begin to see maximum value is when they implement tight integration deploying their code to their infrastructure. Success at this level is the last barrier to at-will deployment. Storage, for instance, is more capable than where we read and write data. In his session at @DevOpsSummit at 20th Cloud Expo, Josh Atwell, a Developer Advocate for NetApp, will discuss the role and value...
    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...
    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...
    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...
    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....
    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...
    SYS-CON Events announced today the Kubernetes and Google Container Engine Workshop, being held November 3, 2016, in conjunction with @DevOpsSummit at 19th Cloud Expo at the Santa Clara Convention Center in Santa Clara, CA. This workshop led by Sebastian Scheele introduces participants to Kubernetes and Google Container Engine (GKE). Through a combination of instructor-led presentations, demonstrations, and hands-on labs, students learn the key concepts and practices for deploying and maintainin...