Is BPEL the real deal?

BPEL (Business Process Execution Language) is an XML-based, special purpose language that many hope will provide a standard way for specifying and building sharable business processes.

We could, of course, accomplish this integration using a general-purpose programming language such as Java or C# to build an application that talks SOAP and executes the business process. The problem with that approach is that the business process moves beyond the reach of the very business people who need to guide its maintenance and operation.

BPEL sidesteps that issue. It can be used in two ways: to specify the behavior of a process at an abstract level or to define executable business processes.

Abstract processes specify constraints on message exchange and expose the level of information necessary for a partner to interact with the process. Using BPEL at the abstract level, business- process owners can specify the process from their vantage point. This abstract specification can then be refined to create an executable business process in the same language.

Executable processes contain more detail, including information that would be hidden from partners in the abstract specification. BPEL primitives are called “activities” and represent the actions to be carried out within the business process. These activities are combined using standard programming language control structures to specify the business process.

Because BPEL is XML based, it’s not much to look at. Programming language designers call the features used to make a language readable and pretty “syntactic sugar;” BPEL is syntactic arsenic. There seems to be no compelling reason to base BPEL on XML except that XML is the syntax of the Web.

BPEL’s constructs will be familiar to anyone who has programmed in a language that allows parallel execution flow and asynchronous invocation — good programmers will catch on pretty quickly. And because BPEL is a standard supported by large vendors — it was defined by BEA Systems, IBM, Microsoft, and a handful of other vendors and proposed to OASIS as a technical standard in 2003 — support tools should be plentiful.

Consequently, most people probably won’t write BPEL directly, but rather use a graphical tool that ultimately generates the BPEL. Grand Central’s Business Services Network, for example, provides a convenient engine for executing BPEL. Collaxa sells a BPEL execution engine as well as a BPEL design tool.

While BPEL may be popular, it isn’t the only standard for choreographing Web services. The W3C’s Choreography working group has been trying to create a consensus of support for business process language specifications including WSCI (Web Services Choreography Interface) and WSCL (Web Services Conversation Language). Where BPEL has mostly focused on internal, private business processes, W3C efforts are aimed at describing public, external, and shared processes.

To avoid a showdown, Oracle and other vendors have recently made moves to bring about some coordination between OASIS’s efforts on BPEL and the W3C’s work on WSCI and WSCL. Focusing BPEL on internal processes and WSCL on external processes could eventually make these languages complementary.