Is BPEL Positioned for the Future?

Integrating disparate systems and applications into end-to-end business processes has always been a challenge. Web services emerged as a means to expose the functionality of these systems across the enterprise, but Web services, by themselves, don't address the need to integrate and coordinate business processes.

Business Process Execution Language, or BPEL, also known as BPEL4WS and WS-BPEL, addresses that weakness by providing a model for how business processes are handled by Web services. Although the BPEL specification has been around for more than five years, the pending WS-BPEL 2.0 specification is more precise; it clarifies and corrects many ambiguities and positions the specification well for future versions.

BPEL has many constructs to deal with the invocation of Web services, including fault handling, correlation and support for conditional logic. The WS-BPEL 2.0 specification improves and adds to these constructs.Despite the improvements, migrating to version 2.0 won't be painless. The syntactic and semantic differences between the two versions are significant. And, unfortunately, WS-BPEL 2.0 is not backward-compatible. Beyond that, key features, such as support for human interaction and subprocesses, are missing.

BPEL Backgrounder

A little background on BPEL: It's a language used to control the way systems or business partners communicate. As a language to describe processes, a BPEL process may represent IT or business scenarios. BPEL processes are typically long-running and can range from performing systems-integration work to coordinating a loan-approval process among business partners.

The original specification, developed by BEA Systems, IBM and Microsoft, gained a lot of support within the industry. As other vendors began to build products around the specification, ambiguities and gaps became apparent. Vendors implementing BPEL engines developed extensions to compensate for the shortcomings. To continue on BPEL's successes, promote its broad adoption and incorporate third-party proprietary extensions as open standards, BEA, IBM and Microsoft donated the specification to OASIS (Organization for the Advancement of Structured Information Standards) in May 2003. To match its naming convention, OASIS then renamed the spec WS-BPEL. WS-BPEL 2.0 is now one step away from being an open standard.

Throughout the industry, expectations for the specification vary. Although WS-BPEL 2.0 will offer new features and improvements over BPEL4WS 1.1, the scope of the specification remains unchanged. The BPEL technical committee chose to make the specification more precise by making clarifications and corrections throughout it.

Continue Reading This Story...

BIntegral To Web Services

The unique constructs behind BPEL situate it atop the OASIS Web Services stack and make it well-suited to dictate the sequencing of services, referred to as service orchestration. BPEL's significance has increased with the widespread adoption of SOA (service-oriented architecture), since orchestration is a necessity with a SOA. Orchestration provides a point of control that lets organizations define and redefine business processes in real time. It provides the flexibility businesses need and is the core value proposition of SOA.

To perform the orchestration, the BPEL process contains constructs (sequence, activities, invocations, assignments and conditional logic) to invoke other services and complete their combined work. One of the ways BPEL supports the conditional logic needed for orchestration is through activities. Activities perform the process logic and are divided into two classes: basic and structured. Basic activities describe elemental steps of the process behavior. Structured activities encode control-flow logic and, therefore, may contain other basic and/or structured activities recursively.

B2.0 Improvements

The WS-BPEL 2.0 specification adds new activities and refines almost every existing activity; it also renames some existing activities. And WS-BPEL 2.0 has positioned itself well for the future by adding and refining several extensibility mechanisms. Proprietary improvements or extensions implemented in one vendor's engine will be ignored when exported to some other BPEL engine. Vendors typically develop extensions to compensate for shortcomings in the specification. Although many of these extensions may make it to the next release, the extensibility mechanisms let vendors implement future functionality today without putting the stability of the standard at risk.It's important to note that though the purity of the specification is not at risk, an implementation using proprietary extensions may be. Even if a proprietary extension becomes a standard, most likely OASIS will refine that extension and it will not make it to the standard verbatim. A migration effort is likely needed to bring the implementation of the extension up to speed with the new standard.

In addition, new standards, such as those for human interaction and subprocesses, can be integrated into BPEL without modification of the core BPEL specification. This is a major advantage, since these new standards will be able to be integrated with BPEL more quickly. WS-BPEL 2.0 improves upon these existing extension mechanisms to make them not only work in theory, but in practice.

Data-manipulation capabilities have also been addressed by WS-BPEL 2.0. The specification introduces a data model to represent BPEL variables and defines rules for mapping different languages, like XPATH 1.0, to the data model.

BMigration Difficulties

Although WS-BPEL 2.0 is more mature than 1.1, there are considerable differences between the two, so the effort to migrate from BPEL4WS 1.1 to WS-BPEL 2.0 isn't trivial. The syntactic and semantic differences will demand an extensive and focused effort to move to the latest specification. And WS-BPEL 2.0 is not backward-compatible.

Also, WS-BPEL 2.0 lacks some key features: It will have no support for modularization, reuse, human interaction and subprocesses. Proposed extensions might emerge to address these issues, but WS-BPEL 2.0 has no support for these concepts. Some will argue that the lack of support for human interaction and subprocesses is a huge shortcoming, as an orchestration language is not complete without support for human interaction and subprocesses. And indeed, such support is critical for BPEL to handle all workflow patterns in a standardized way. This, however, hasn't kept customers from adopting BPEL, since most customers needing human interaction capabilities rely on the proprietary implementations supplied by their vendor.

To address the human-interaction aspect, IBM and SAP have proposed BPEL4People as an extension to BPEL. Human tasks are fundamentally different than services in that human tasks are primarily stateful (ready, in progress, complete, failed, and so on) and can only have one consumer at a time, whereas service invocations are primarily stateless, such that the service doesn't care how many consumers are using it at a given time. Because of this fundamental difference, any implementation of this functionality should be handled as an extension and not as part of the core specification. Unfortunately, most BPEL engines currently handle this functionality as a proprietary extension and will continue to do so under the new specification.

In most cases, leveraging these types of proprietary extensions will make it difficult to migrate from one vendor's BPEL engine to another.Similarly, subprocesses are also a challenge. The BPEL language currently does not support the explicit definition of subprocesses. In both the BPEL4WS 1.1 and the WS-BPEL 2.0 specifications, the only way to simulate this behavior is to define a complete business process as an independent service and invoke it using the invoke activity. This is more or less a workaround, as the subprocess is completely hidden from its parent process and does not have lifecycle coordination with its parent process. To address these issues, IBM and SAP offered a proposal, Extensions for Sub-Processes (BPEL-SPE). The proposal calls for the explicit definition of subprocesses, allowing for the reuse of the subprocess, tight coupling of the subprocess's lifecycle with its parent process, and the ability of the subprocess to access its parent processes data.

It's anticipated that both of these proposals will become draft specifications once WS-BPEL 2.0 has received standards approval.

WS-BPEL 2.0 is evidence that BPEL is still a work in progress. The improvements it brings show what a standards body like OASIS can do for a specification and are a clear demonstration of what has been learned by those using previous versions. Users of the language may benefit from the conveniences that BPEL now offers, but they'll experience difficulties trying to migrate existing BPEL processes to the new specification. The immediate benefits of WS-BPEL 2.0 will be realized by vendors, since they will be sure to take advantage of the extensibility mechanisms that this specification provides.

Erik R. Pieczkowski is an enterprise architect for Synegen, a Chicago-based consultancy. He has architecture experience ranging from the design and development of high-performing message-driven systems to building and deploying scalable SOAs. Write to him at [email protected].