An industry-wide specification for orchestrating web services in business processes was set to be formally adopted by OASIS last 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 concluded last Saturday and approval was expected as Computerworld went to press.
BPEL is an XML language that uses web services to describe services interactions, says 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,” says Diane Jordan, programme 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 can also employ business processes with BPEL, make them part of their SOA, and feel more confident about a formally adopted version of BPEL, Jordan says.
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.
“The language is a fairly complex thing to produce,” Jordan says 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 says.
“BPEL is really creating a new capability for web services to be orchestrated,” Jordan says.
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 says.
Also featured in the new version is the capability to extend BPEL to add vendor-specific capabilities in areas such as security.
A variable initialisation capability specifies how a variable, such as one holding a specific value that can referenced later, can be initialised. 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 process might, for example, receive data in one format that needs to be transformed.
“What BPEL does is effectively aggregating [of] services,” Evdemon says.
XPath is featured in BPEL 2.0 for accessing variable data. Also included in the specification is use of the XML schema to describe variables used by a service activity.
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 organisations,” says analyst Ronald Schmelzer, senior analyst at ZapThink, in an email. “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.
“The problem 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 says.