Formal BPEL standard set for approval

Without further adieu, an industry-wide specification for orchestrating Web services in business processes appears set to be formally adopted by OASIS next week, nearly five years after the proposal first debuted.

Voting on WS-BPEL (Web Services Business Process Execution Language) 2.0, or BPEL, by OASIS members concludes this Saturday and the organization expects it to be formally approved. An announcement is anticipated on Monday.

BPEL is an XML language that uses Web services to describe services interactions, said John Evdemon, co-chairman of the BPEL technical committee at OASIS and a member of the architecture strategy team at Microsoft. It is considered crucial to SOA and functions with the WS-* (pronounced as “ws star”) Web services standards.

“If you think about the overall goals of SOA, the ability to compose the services into [a] business process that solves a real business problem is critical, and that’s what BPEL gives us,” said Diane Jordan, program director for software standards at IBM and also a co-chairperson of the BPEL technical committee at OASIS.

BPEL can enable services to be sequenced or run in parallel; Web services can be used in a business flow. Some technology vendors that have implemented the 1.1 specification in their products are likely to incorporate the 2.0 version. Users also can employ business processes with BPEL, make them part of their SOA, and feel more confident about a formally adopted version of BPEL, Jordan said.

BPEL was first published in August 2002 by a list of vendors that included BEA Systems, IBM, and Microsoft. Since then, vendors such as Oracle have endorsed it as well.

BPEL was submitted for consideration by OASIS in May 2003. A 1.1 version of the specification has been in use but was never formally adopted by the organization as an OASIS standard.

“The language is a fairly complex thing to produce,” Jordan said in explaining why it has taken this long to get a ratification-worthy version of BPEL. Potential problems with the specification have had to be addressed and that has taken a long time, she said.

“BPEL is really creating a new capability for Web services to be orchestrated,” Jordan said.

Version 2.0 of BPEL features improvements in a number of areas. Activity types, which are akin to constructs that describe process flows, have improved with the addition of if-then-else statements replacing the switch statement used previously. “It’s basically making the language friendlier for developers,” Evdemon said.

Also featured in the new version is the capability to extend BPEL to add vendor-specific capabilities in areas such as security.

A variable initialization capability specifies how a variable, such as one holding a specific value that can referenced later, can be initialized. An example of where this would be used is with a product identifier.

Also featured is the use of XSLT (Extensible Style Sheets) to provide a standard, Web-based mechanism for transforming variable data. A BPEL process might, for example, receive data in one format that needs to be transformed.

“What BPEL does is effectively aggregating [of] services,” Evdemon said.

XPath is featured in BPEL 2.0 for accessing variable data. Also included in the specification is use of XML schema to describe variables used by a service activity.

Better descriptions of abstraction and executable processes also are included, for use in applications such as B-to-B commerce. A retailer might have an abstract template to explain service interactions and note possible exceptions.

BPEL has its pros and cons, according to one analyst.

“There are some significant changes from the prior version 1.1, including removal of the ‘partner’ concept to facilitate B-to-B interactions and definitions of programmatic flows across organizations,” said analyst Ronald Schmelzer, senior analyst at ZapThink, in an e-mail. “BPEL 2.0 introduces a number of new ways to compose services together programmatically as well as greater XPath and XSLT support for XML as-is, without having to involve C# or Java to interpret things.”

“The problems with the BPEL spec is that it still doesn’t support the human aspects of workflow well and it approaches composition of services from a programmatic perspective, leading some to believe that BPEL is simply another way of coding processes using XML rather than a programming language,” Schmelzer said. “More work will need to be done to make BPEL more declarative in nature to support ad-hoc processes that include human interaction and support choreographies that are more abstract.”

BEA reaffirmed its support in an issued statement on Thursday.

“BEA sees WS-BPEL 2.0 as a very important milestone in the ongoing effort to align the industry behind a common technology for orchestrating services within an SOA,” said Michael Rowley, BEA director of standards architecture, in a statement released by the company. “This supports our efforts to serve our customers through aggressive support of open standards.”