BPEL Primer

This week I wrote a BPEL Primer for the PSGroup research service. The Primer answers 4 questions:

• What is BPEL?
• What is it Good For?
• How does it work?
• What does it look like?

I wrote the primer because I think BPEL is an important spec for IT professionals to understand, especially those pursuing SOA and/or integration strategies. For that same reason, I’m excerpting sections (and subsections) here.

In thinking about how to excerpt the report for my blog, I ended up creating a new illustration that shows the whole “A BPEL process is a service orchestration, used to describe/execute a business process (or large grained service), which is implemented as a stateful service” thing. In addition, the picture covers the “A process is comprised of steps, steps have activities AND activities are BPEL language elements, and the basic activity elements are the ones used to interact with the collaborating services <partnerLinks>” thing.

I wish I thought of it earlier, when I was working on the report. But, that goes to show the real-life nature (and power) of the blog…iteration!

If you want the full report, you can get it for free here. Before bailing for the free report, take a look at the new illustration; it ties into the “What is BPEL” section on page 4 of the PDF.

The BPEL Primer Excerpt: What is BPEL, What is it Good For, How does it Work?

Note: The service terminology is consistent with my SOA definitions post.

What is a Business Process? A business process is a flow of work, broken out as a series of steps, or activities, which are required to complete a business transaction. The business process activities may require application and/or human behavior for completion. A business process is typically long-running in nature, involving multiple parties and/or applications within an enterprise or across enterprises.

What is a Business Process in BPEL? In BPEL, a business process is a large-grained stateful service, which executes steps to complete a business goal. That goal can be the completion of a business transaction, or fulfilling the job of a service. The steps in the BPEL process execute activities (represented by BPEL language elements) to accomplish work. Those activities are centered on invoking partner services to perform tasks (their job) and return results back to the process. The aggregate work, the collaboration of all the services, is a service orchestration.

As you can see, BPEL focuses on a very specific (but important) problem: the orchestration of services, into large-grained services and/or processes. The delineation of large-grained service versus process is based on the specific job being performed. That said, let’s go deeper. 

[click ON Picture to enlarge]

What is BPEL?
BPEL, also known as BPEL4WS and WSBPEL, is an XML-based language, built on top of Web Services specifications, which is used to define and manage long-lived service orchestrations or processes. Let’s decompose that in reverse. Orchestrations first, followed by the technical base.

Orchestration. As stated in the SOA terms, in an orchestration, a primary service controls (provides) the collaboration.

When you use BPEL for orchestration, the primary service is a BPEL process, because BPEL processes are implemented as services.

The BPEL process controls the overall sequence and invokes the collaborating services.

To perform the orchestration, the BPEL process contains the logic (sequence, activities, invocations, assignments, and case logic) to invoke other services (collaborators), to complete their combined job.

This BPEL process may be asynchronous or synchronous. In an asynchronous model, the BPEL process is managing a long-lived flow of work; in other words, a process.

In a synchronous mode, the BPEL process is more likely playing the (logical) role of another service type, such as request/reply, worker, agent, or monitor.

Technology Base. BPEL’s technology underpinnings are XML and Web Services. XML, as most people know, is a standard (tags-based) markup language used in document and message definition and processing. In addition, XML serves as the language base (format and syntax) for many special purpose languages such as WSDL (Web Services Description Language), and RSS (Really Simple Syndication).

BPEL follows this same model. The BPEL process description is encoded using XML language constructs. BPEL also incorporates XPATH to write expressions and queries.

Web Services Specifications. Web Services are important to BPEL in two ways. First, BPEL processes follow the WSDL service model—which is why BPEL processes are implemented as services. More specifically, BPEL processes have a WSDL definition, and are implemented as Web Services (WSDL, SOAP, UDDI).

Along with the basic functions of service definition, discovery and invocation, the Web Service implementation allows BPEL execution engines to leverage additional Web Services standards at runtime, such as WS-Addressing and WS-Coordination.

Second, the collaborating services are also Web Services, described in WSDL. So, BPEL processes and collaborators are Web Services, and BPEL execution engines contain (and use) Web Services
runtime components. (Natively, the collaborating services (and the process service) are Web Services.  However, BPELJ, an extension of BPEL, allows for a mix of Java Services and Web Services. 

What Is BPEL Good For?

So far, this has been fairly technical, talking service orchestration, business process services, interaction models and technology bases. Before going much deeper, it is important to understand the best uses (and limitations) of BPEL.

BPEL and Service Orchestration. BPEL offers a nice model to abstract orchestration logic from the participating services, and configuration using BPEL over (hard core) coding of service interactions is enticing. However, there is processing overhead and infrastructure expense, so BPEL might not be the best choice for simple orchestrations. As a rule of thumb, a simple orchestration is comprised of two to five services and has static interaction patterns.

BPEL AND PROCESSES. As a language to develop processes, BPEL is good at executing a series of activities, which occur over time, and interact with internal and external services. These processes may represent IT scenarios, such as integration, or business scenarios, such as information exchange, or flows of work.

As for limitations, BPEL does not account for humans in a process, so BPEL doesn’t provide workflow—there are no concepts for roles, tasks and inboxes. In addition, BPEL does not support really complex business processes, those which evolve during their execution, branching out to incorporate new parties and activities. Lastly, BPEL does not have native support for business activity monitoring (BAM). There isn’t a data model for measurement and monitoring.

Of course, for every limitation there are industrious groups trying to resolve it. In late August 2005, IBM and SAP AG proposed an extension to BPEL (BPEL4People), to incorporate humans (initiators, approvers, managers, and task doers) in BPEL processes. This is an important issue to resolve, and I’ll be watching the BPEL4People proposal closely.

How Does BPEL Work?

[In this excerpt, I only cover the BPEL environment. In the report, I also speak to the Design to Execution Procedure]

[click ON Picture to enlarge]

BPEL Design, Development, and Deployment. At the far left of the diagram is the BPEL design, development, and deployment environment. Here are the tools for business analysts and developers/integrations to describe processes (orchestrations), as a series of steps (activities), associate services, and add any special business or validation logic to the process flow.

These tools vary from plug-ins for drawing tools or integrated development environments, to full-blown standalone environments. Most tools support a toggle between the graphical design view and the BPEL source code view. Changes made in one mode should be reflected in the other.

Supporting the design and development tools should be your service repository.

BPEL Execution. In the center of the diagram is the BPEL execution environment. The BPEL Server contains the executing process instances, a Web Services framework, and the BPEL execution services. The BPEL execution engine services collectively provide the process lifecycle requirements (instantiation, communication, dehydration/hydration, correlation, transaction management, compensation, and termination) as spelled out in the specification. Similar to J2EE containers, the engine implementations need to meet the specification requirements, but how that is accomplished is up to the individual BPEL engine providers.

To the right of the BPEL server, I show the Process DB used to hold information on process instances and state, and the BPEL server’s management console.

I drew the BPEL server simply, in alignment with the specification; however, implementations vary, with vendors adding features for non-Web Service invocations, and business performance reporting. As with any technology, be sure you ascertain which functions are provided as part of the specification, and what are vendor-supplied (proprietary) extensions.

Underneath the BPEL server, I show four different host environment options: J2EE container, .Net container, Java Business Integration (JBI) container, and an enterprise service bus. Example (not endorsements) implementations for each host environment (respectively) are: Oracle’s BPEL Process Manager, Microsoft’s BizTalk Server, FiveSight Technologies’ PXE, and CapeClear’s ESB.

Above the BPEL server, I show the client service that initiates the process, and the collaborating (partner) services.

Bridge To Execution. The hand-off from development to execution contains the BPEL process definition, the WSDL of the BPEL process, and all engine-specific deployment files.

</excerpt>

For more on BPEL, check out the OASIS cover page, play a little – I started with this, or read my full report :)

Comments

[Vivek Kondur]

Another interesting one!. Thanks for the link to the BPEL4People, looks interesting, hope it gets integrated with the upcoming BPEL2.0 version.

BTW the link for your free report refers to this one http://www.psgroup.com/detail.aspx?ID=630 (which is not available for free).

[brenda]

Vivek - thanks for the heads-up on the BPEL report price, it has been corrected on the PSGroup site - it is now (once again) a Free Download. http://www.psgroup.com/detail.aspx?ID=630

[Zachary Huynh]

Correction: "As for limitations, BPEL does not account for humans in a process, so BPEL doesn’t provide workflow"
In WSBPEL 2.0, you can have human task as part of your process. You can see this work by using IBM WebSphere Process Server.

[brenda michelson]

Zachary, The BPEL Primer, written in Sept 2005, is based on BPEL 1.1. As you mention, the human task is part of BPEL 2.0, which is (amazingly) still in draft status: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel

I hope to publish an update to this primer when BPEL 2.0 is approved. -brenda

[John Evdemon]

The BPEL Technical Committee this week approved a vote to go into Public Review. This is the first step towards becoming an approved OASIS standard. Look for an official announcement from OASIS sometime next week. We expect to see the WS-BPEL 2.0 spec become an official OASIS standard by the end of this calendar year (or early next, depending upon the feedback we receive during Public Review).

Nice primer, btw! The BPEL TC is working on a non-normative Primer for BPEL 2.0 - the Primer will be available when the spec is standardized.

[brenda michelson]

John, that's great to know. I'll be watching for the announcement. If you need a reader for the BPEL 2.0 Primer, let me know. -brenda

[Tom Marrs]

Brenda,
This is a great introduction to BPEL. Could you recoomend a good book on BPEL (non-vendor-specific) that would provide a tutorial for those getting started in this space?

Also, if I'm using ServiceMix/FUSE/Mule ESB (which embeds PXE), what are my options for a GUI-based BPEL designer? I'm looking for an Eclipse plug-in that would generate BPEL that I could feed to one of these engines?

[Bruce Snyder]

Tom, the next release of the LogicBlaze FUSE platform's FUSE IDE, which is due out in a couple weeks, contains the Eclipse BPEL Designer (http://www.eclipse.org/bpel/). The Eclise BPEL Designer provides a graphical designer for the definition, authoring, editing, deploying, testing and debugging of BPEL 2.0 flows. And a BPEL 2.0 flow can be deployed to the Apache Ode (http://incubator.apache.org/ode/) BPEL 2.0 service engine.

[Fred Holahan]

Tom, you can download the free ActiveBPEL Designer today at http://www.active-endpoints.com/active-bpel-designer.htm. It is a native Eclipse technology that generates BPEL 1.1 and 2.0 process definitions. It includes some very nice productivity features such as BPEL/WSDL validation, Web references (auto discovery of BPEL-relevant artifacts from WSDL), and visual simulation of process flows. The designer also does automatic migration of BPEL 1.1 process definitions to 2.0, including all syntactic and semantic changes. This is not a feature-crippled designer or a time-bombed promotion ... it's a comprehensive BPEL authoring environment that Active Endpoints makes available to the SOA community for free.

[legolas wood]

Thank you for this blog.
very informative and usefull.

[Arjeh van Oijen]

BPEL4People is the worst that can happen. It is contradictive with the SOA / BPEL approach. The main objective of SOA is the reduction of the impact area of a certain change. When the implementation of a service is changed (e.g. COBOL app. is replaced by a Java app.), but the service interface remains the same, only the concerning service is impacted and not the applications that request the service (such as a BPEL process). The attractiveness of SOA with BPEL is that it clearly separates process managment and control with process execution. The BPEL process invokes a service and doesn't need to know how and where it is executed. When the process logic is changed, the invoked services are not impacted. When the implementaion of a service is changed, but not the interface, the BPEL process is not impacted. It may be possible that the invoked service contains an UI via which an operator needs to perform a certain action (e.g. add data) before the service response is returned to the BPEL process. What operator with which permission can perform the activity via the UI is a resonsibility of the service and NOT of the BPEL process. When the human intercation is replaced by an automated execution (e.g. an automated data enrichment), only the concerning service need to be changed. The BPEL process is not impacted what so ever. With BPEL4People this principle is broken. A change in the implementation of the service also impacts the BPEL process. Vendors on the other hand are always striving to lockins, that prevent users to step over to other vendors.

Advice from my side, don't use human task facilities within BPEL (like role management). These should be handled by the invoked service and can be accomplished already with BPEL 1.1.