Microservices Expo Authors: Liz McMillan, Zakia Bouachraoui, Elizabeth White, Pat Romanski, Yeshim Deniz

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
    The now mainstream platform changes stemming from the first Internet boom brought many changes but didn’t really change the basic relationship between servers and the applications running on them. In fact, that was sort of the point. In his session at 18th Cloud Expo, Gordon Haff, senior cloud strategy marketing and evangelism manager at Red Hat, will discuss how today’s workloads require a new model and a new platform for development and execution. The platform must handle a wide range of rec...
    When building large, cloud-based applications that operate at a high scale, it’s important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. “Fly two mistakes high” is an old adage in the radio control airplane hobby. It means, fly high enough so that if you make a mistake, you can continue flying with room to still make mistakes. In his session at 18th Cloud Expo, Lee A...
    In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
    Lori MacVittie is a subject matter expert on emerging technology responsible for outbound evangelism across F5's entire product suite. MacVittie has extensive development and technical architecture experience in both high-tech and enterprise organizations, in addition to network and systems administration expertise. Prior to joining F5, MacVittie was an award-winning technology editor at Network Computing Magazine where she evaluated and tested application-focused technologies including app secu...
    Containers and Kubernetes allow for code portability across on-premise VMs, bare metal, or multiple cloud provider environments. Yet, despite this portability promise, developers may include configuration and application definitions that constrain or even eliminate application portability. In this session we'll describe best practices for "configuration as code" in a Kubernetes environment. We will demonstrate how a properly constructed containerized app can be deployed to both Amazon and Azure ...
    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...
    Using new techniques of information modeling, indexing, and processing, new cloud-based systems can support cloud-based workloads previously not possible for high-throughput insurance, banking, and case-based applications. In his session at 18th Cloud Expo, John Newton, CTO, Founder and Chairman of Alfresco, described how to scale cloud-based content management repositories to store, manage, and retrieve billions of documents and related information with fast and linear scalability. He addresse...
    SYS-CON Events announced today that DatacenterDynamics has been named “Media Sponsor” of SYS-CON's 18th International Cloud Expo, which will take place on June 7–9, 2016, at the Javits Center in New York City, NY. DatacenterDynamics is a brand of DCD Group, a global B2B media and publishing company that develops products to help senior professionals in the world's most ICT dependent organizations make risk-based infrastructure and capacity decisions.
    Discussions of cloud computing have evolved in recent years from a focus on specific types of cloud, to a world of hybrid cloud, and to a world dominated by the APIs that make today's multi-cloud environments and hybrid clouds possible. In this Power Panel at 17th Cloud Expo, moderated by Conference Chair Roger Strukhoff, panelists addressed the importance of customers being able to use the specific technologies they need, through environments and ecosystems that expose their APIs to make true ...
    In his keynote at 19th Cloud Expo, Sheng Liang, co-founder and CEO of Rancher Labs, discussed the technological advances and new business opportunities created by the rapid adoption of containers. With the success of Amazon Web Services (AWS) and various open source technologies used to build private clouds, cloud computing has become an essential component of IT strategy. However, users continue to face challenges in implementing clouds, as older technologies evolve and newer ones like Docker c...