The Case Against BPEL: Why the Language is Less Important Than You Think

Even amid all of the noise around web services, the Business Process Execution Language (BPEL) gets a lot of attention. Now owned by OASIS, the language was originally created by IBM and Microsoft, and it’s supported today in many products. These products are certainly useful, and some organizations are using BPEL successfully. Yet the language gets far more attention than it deserves. Here’s why.

Describing BPEL
According to the BPEL specification, the language’s goal is to provide "a notation for specifying business process behavior based on web services". Defined entirely in XML, BPEL relies most fundamentally on a process element that contains various other elements. One of the most important of these is partnerLink, which allows specifying the roles and message exchanges between communication partners. Other elements, known as activities, can be used to specify a process’s business logic. These activities include:

• sequence: executes one or more activities sequentially.
• flow: executes one or more activities in parallel.
• switch: executes one of several paths based on the value of a condition.
• while: executes a specified activity as long as a condition is true.
• invoke: calls a web service.
• receive: receives an incoming web services call.
• reply: sends a response to a received web services call.
• variables: defines any global variables the process uses.
• assign: allows copying and manipulating data using XPath.

The language also has other useful features, such as the ability to create compensation handlers for failed long-running transactions and a way to define correlation sets for associating responses with earlier requests.

These fundamental abstractions can be applied in two related but distinct ways. One of them, defining business-to-business interactions using what the BPEL specification calls abstract processes, is quite useful. The other, defining what the BPEL spec calls executable processes, is likely to be much less so.

Where BPEL Is Useful: Defining Business Protocols
Think about a firm that sells to a big, powerful customer such as Wal-Mart or Toyota. The customer will certainly define its own process for interacting with its suppliers, requiring those firms to follow that process exactly. If the automated interactions between the customer’s software and the supplier’s software are expressed using web services, it would be useful to have a mechanism to express those interactions in a common way for the customer and all of its suppliers. Defining this kind of interaction, sometimes called a business protocol, is an excellent role for BPEL.

A business protocol can be expressed as a sequence of web services exchanges driven by some underlying logic. Defining this protocol requires specifying the interface exposed by each partner in the communication, then describing the logic—the abstract process—behind the web services exchanges. BPEL meets these requirements well. One or more partnerLink elements can be used to define links with other processes, and elements such as sequence, switch, and while can be used to define the underlying logic.

• The Case Against BPEL: Why the Language is Less Important Than You Think
   
• David Chappell's Fall Speaking Schedule
   

As the figure above suggests, BPEL process definitions can be used to help create the implementation of both the customer and the supplier side of a business protocol, with a separate definition for each role. Each definition’s partnerLink element describes its role and the role its partner plays in this business protocol. Each also has its own activities that define its abstract process.

The purpose of a BPEL specification created for this kind of business-to-business interaction is to make it easier for the parties involved to interact with one another using web services. Given this, it’s possible to view BPEL as a standard focused on interoperability. It’s important to understand, however, that this kind of interoperability is predicated on portability. In other words, a BPEL definition is intended to be readable by diverse software running on different systems. In the scenario described here, for example, the customer must be able to create a BPEL definition that can be used effectively by any of its suppliers, regardless of the system they’re using. This is exactly what portability means, and it’s an essential aspect of BPEL’s value.

Still, it’s worth emphasizing that abstract processes don’t make any assumptions about how the logic behind either side of a business protocol is actually implemented. This means that the most challenging aspects of portability, such as those stemming from differences between the Java and .NET environments, don’t need to be addressed. Abstract processes also have no need to define how interactions with internal software or processes are implemented. This approach lets organizations agree on how to communicate without exposing details of their internal processes, something the company lawyers might insist on.

The BPEL spec refers to this kind of scenario as "a very important, if not the most important, use case" for BPEL. Yet if specifying business protocols were the only intended use for BPEL, there would be far less interest in the language. Having a standard way to define a group of web services interactions between organizations is useful, but the problem it solves is somewhat specialized. In fact, however, BPEL is being pressed into service for a much broader purpose. As described next, this is where things start to fall apart.

Where BPEL is Not Useful: Defining Executable Business Processes
The "L" in BPEL’s name is entirely accurate—it certainly is a language—and the "BP" is also correct: its focus is on automating business processes. It’s the "E’ that gets people most excited, though, because it raises the possibility of defining executable process logic in a standard, portable way. As just described, BPEL is good at defining business protocols, and the language contains enough process logic elements to meet this goal effectively. Yet plenty of people, including some of the language’s creators, also view BPEL as a general-purpose tool for describing not just the abstract processes that define business protocols, but fully executable processes as well. The figure below provides a view of how BPEL can be used to do this.

As the diagram shows, it’s common to use a graphical process design tool to create BPEL definitions. Only masochists want to define a process directly in an XML-based language, and few people are truly comfortable with XPath, XML Schema, and the other XML-related technologies that BPEL uses. Besides, business processes should ideally be defined by business analysts, not software developers, and so creating these processes in a graphical tool makes sense. Once it’s been created, a process’s BPEL definition is then somehow transformed into an executable process. Different products do this differently: some execute the BPEL directly, while others convert it first into another form, then compile and run that. However it’s done, the business process logic can now execute, performing tasks typical of any business process.

And here’s where the problems start to appear. If this BPEL-defined process uses only XML data and communicates with other software only through web services, everything is fine: as described earlier, BPEL is designed for this. But what about all of the other things a real process needs to accomplish? Here, BPEL has a number of limitations, including the following:

• A process defined using BPEL will commonly need to access local objects, since not everything most processes need to do can be described in BPEL. These local objects will most likely be written in Java or a .NET language, such as C#, and so the BPEL process will need some way to access them. The BPEL spec doesn’t define a standard way to do this.
   
• A process often needs to communicate with other software outside its own environment. If that software is accessible via web services, this doesn’t present a problem for a BPEL-defined process. Yet much software today doesn’t support web services, a situation for which BPEL provides no standard solution.
   
• Processes commonly need to access data, such as information stored in a relational database system. BPEL is focused entirely on web services access, and so while it does allow working with XML data, the language doesn’t define a standard way to access relational data or other non-XML information.
   
• Business processes commonly involve people. BPEL was designed for system-to-system interactions, not interactions that involve human beings. Accordingly, it doesn’t define mechanisms focused on interacting with people.

None of these things were a goal of BPEL’s creators, so it’s not correct to criticize their absence. It is important to understand what that absence implies, however. Most fundamentally, it means that implementing a complete process in BPEL generally requires using product-specific extensions. Various BPEL-based technologies provide various solutions for these problems, such as ways to call local Java objects. But once BPEL has been extended in proprietary ways, how much value does it have left? A fundamental benefit of the language, especially for creating executable processes, is portability. Yet the significant extensions required to make BPEL a complete solution for executable processes mean that while it’s possible to specify part of a process in a platform-neutral way, truly complete and portable business logic is out of its reach. The OASIS committee that now owns BPEL could attempt to rectify this, but important aspects of implementing a process are inherently platform-specific. How, for example, can access to local objects be done in a portable way, given the differences in the Java and .NET environments?

When used to define executable business processes rather than just business protocols, BPEL definitions cannot be both complete and completely portable. Given this lack of portability, it’s reasonable to ask why a BPEL-based tool for defining business processes is better than one using a proprietary language. Does the language offer other benefits for creating executable processes?

One possibility is that BPEL might become the standard process language for developers. The notion of a common language for defining process logic, one with support for compensation, correlation, and other useful abstractions for working with long-running processes, is appealing. Yet BPEL is not this language. Like other XML-based notations, BPEL is best suited to be generated and consumed by tools, not people. (In fact, because BPEL usually is generated by tools rather than directly by developers, the people who create BPEL definitions may not even be aware that they’re using BPEL.) The language’s complexity and the general unfriendliness of XML are likely to keep BPEL from ever becoming a widely-used tool for direct use. Hiding it behind tools, as is typically done, is a much better idea.

One more place where BPEL might have value for defining process logic is in composite applications. In a purely web services world, BPEL might be able to provide a complete tool for describing the logic that unites a set of disparate services into a coherent application. Logic that relies solely on web services and XML-defined data could even be quite portable, since BPEL supports these things natively. Once again, however, it’s hard to see how using BPEL is much better than using a proprietary language for this purpose. Unlike the business protocol scenario, there’s no real requirement here for a portable process definition, and even the process logic for a composite app might need to access local objects or do other things that impinge on portability. Once again, a proprietary language would probably be an equally good solution.

Taken together, BPEL’s weaknesses for creating portable executable processes outweigh its strengths. So why do vendors trumpet their BPEL support? For those that address the business protocol scenario, such as business-to-business-oriented products, BPEL certainly can provide real customer value. For products targeting the creation of general business logic, however, BPEL’s practical value is harder to see. What it does do, however, is let a vendor tap into the warm, fuzzy feelings that standards impart. Rather than present potential customers with a proprietary technology for defining process logic, a vendor can instead incorporate BPEL. After all, the language does allow some portability, and more important, it sprinkles the pixie dust of standards on what would otherwise be wholly proprietary products. Yet because of their unavoidable extensions, BPEL-based products provide a significant degree of vendor lock-in. This combination—following standards while still locking in customers—is vendor nirvana. Some users might also find it valuable, but they should make sure they’re walking this path with their eyes wide open.

Summing Up
Using BPEL to define business protocols makes good sense. The requirements for achieving portability are relatively low, since no system-specific behaviors need to be defined, and the benefits of interoperability are considerable. I expect BPEL to become an important technology in this area.

Most of the excitement around BPEL isn’t about solving this important but relatively narrow problem, however. Instead, it’s about BPEL’s potential to become the standard language for defining all kinds of business processes in a portable way. Despite the hype, despite the enthusiasm, and despite the unbridled optimism of some vendors, I don’t believe this is likely to happen. Unless you’re completely focused on those scenarios where the language can shine, BPEL really is less important than you think it is.

David Chappell's Fall Speaking Schedule

September 11:
Tutorial: "Understanding SOA and BPM", Gartner Application Development Summit
Dallas, TX

October 4:
Keynote, Microsoft Business Process Integration and Workflow Conference: "Implementing Business Processes: Services, Workflow, Integration"
Seattle, WA

October 20:
Presentations on web services and SOA
Seoul, South Korea

October 24:
Presentations on web services and SOA
Singapore

October 26, 27, and 28:
Presentations on web services and SOA
Tokyo, Japan

November 2:
Keynote, Architect’s Forum: "Software in a Service-Oriented World"
Zurich, Switzerland

November 22:
Presentations on Windows Communication Foundation and Windows Workflow Foundation
Madrid, Spain

David Chappell is Principal of Chappell & Associates (www.davidchappell.com) in San Francisco, California. Through his speaking, writing, and consulting, David helps information technology professionals around the world understand, use, market, and make better decisions about enterprise software technologies. David has given keynotes at conferences and in-house events in the U.S., Europe, Latin America, and the Middle East, and his seminars have been attended by tens of thousands of developers and decision makers in thirty-five countries. David's books have been translated into ten languages and used in courses at MIT, ETH Zurich, and other universities. His consulting clients have included HP, IBM, Microsoft, Stanford University, and other technology vendors and users.

© Copyright 2005 David Chappell and Associates
All rights Reserved.