Primer: Business Process Execution Language

What is it? A language designed to help programmers automate processes that will involve more than one company. Business Process Execution Language for Web Services (BPEL) is designed for Web-services applications, which can mean any function provided by a Web server. But in practice, a “Web service” is typically an application that makes specialized business functions such as transactions available through a Web server using specific standards.

How does it work? BPEL’s role in a Web-services exchange is to define all the steps in a transaction, and make sure they’re executed in the correct order. A BPEL document keeps track of what is supposed to happen when a buyer, for instance, sends a purchase order to a supplier. The BPEL document is sent along with the purchase order, bringing instructions for required procedures, including an acknowledgement of the order, credit approval, receipt for payment and confirmation when goods are delivered.

How good is that? Pretty good, but not as good as some companies are hoping. BPEL is designed to function in the “public space” between companies, so it doesn’t include instructions about how to link a buyer’s Web server to, for example, the supplier’s accounts-payable system. Those comparatively complex, secure processes have to be coded separately, using either Java or .Net, two more-involved Web-services programming languages. Part of the limitation is that BPEL can’t translate a written request from a buyer into data a supplier’s order-management system can understand. So BPEL can automate a sequence of messages, but not actually execute a transaction.

So why should I care? Because automating even the few steps leading up to a transaction can be a big cost-saver compared to more-powerful (but more-difficult) methods like Electronic Data Interchange. And because, by distributing reports in a Web-services format that might otherwise have been faxed, then filed, BPEL delivers data other systems can actually use.

Anything else? Yes. An apparently unintended consequence of BPEL is that it gives a company incentive to formally define its transaction processes in both technical and non-technical language. That makes it much easier to automate or streamline those processes even without BPEL.

Who's doing it? Almost no one. The latest version is still under consideration by the Organization for the Advancement of Structured Information Standards, the Web-services standards body, but hasn’t been finalized yet. Some vendors support it in their application servers and some early adopters are playing with it, but don’t look for commercials about it on TV yet. Learn more about BPEL here.

What's the downside? Other than BPEL’s difficulty trading data with back-end transactional systems, the lack of tools to take advantage of its existing functions and its limited acceptance as a real or accepted standard? It depends on an alphabet soup of other Web-services protocols, few of which have been seriously tested. There are also a host of complementary and competing specifications, though BPEL is generally considered to be the leader in its functional niche. There are also aesthetic drawbacks. For example, rather than use the acronym, advocates frequently pronounce it; and it’s hard to pitch a million-dollar project using the word “bipple.”

Take this quick Quiz ("Compelled to BPEL?") to help gauge your company's readiness for BPEL.

Copyright © 2004 Ziff Davis Media Inc. All Rights Reserved. Originally appearing in Baseline.