BPEL gets bopped... again
Is BPEL the language of the people? In his latest post, Web services guru David Chappell wonders out loud if BPEL, or business process execution language, is really all it's cranked up to be. BPEL is seen as the glue that will loosely couple Web services components into an SOA. The standard has been submitted to the technical committee of OASIS, but a final specification is not yet in place.
What's David's beef with BPEL? Essentially, that BPEL is fine for developers that are looking to link XML Web services, but may not be as effective for business users within the enterprise at large, who are working with all sorts of local objects, legacy systems and data types. "Business processes commonly involve people," he writes. "BPEL was designed for system-to-system interactions, not interactions that involve human beings. Accordingly, it doesn’t define mechanisms focused on interacting with people."
David observes that BPEL will shine when it comes to defining business protocols, where the "requirements for achieving portability are relatively low, since no system-specific behaviors need to be defined, and the benefits of interoperability are considerable." However, he adds, "Most of the excitement around BPEL isn’t about solving this important but relatively narrow problem. 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... BPEL really is less important than you think it is."
What leads people astray with BPEL is the "E" in the acronym -- execution. Many view BPEL "as a general-purpose tool for describing not just the abstract processes that define business protocols, but fully executable processes as well," David Chappell explains. Software developers using XML may be comfortable with deploying this way, but business analysts using graphical tools may run into a lot of limitations, he notes.
Other industry experts have voiced concerns about pinning too much reliance on BPEL to bring together all the far-flung components of SOA. Earlier this year, I reported on objections raised by PolarLake's Ronan Bradley, would also said that BPEL is far more limited in executing business processes than its name suggests. He warns against relying too much on a high-level solution such as BPEL for complex, down-and-dirty integration projects. "BPEL itself is not the danger, but the belief that BPEL in some way resolves all integration issues most certainly is," Bradley said.
More recently, Britton reported that Oracle's Tod Nielsen also suggested that BPEL capabilities are not up to snuff. BPEL, the specification for orchestration of processes in SOAs, is considered one of the next battle grounds for companies jockeying for position in the SOA arena. "The important thing is [BPEL is] not done yet and while we look at BPEL as a promising development, Oracle users are taking a huge risk by developing on BPEL 1.1 and getting locked into something that they think is standard but isn't," Roth said, noting that the feature set could still change.