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.
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
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
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
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:
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.
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.
October 26, 27, and 28:
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