The BPEL4WS Basics

It's the rule of BPEL4WS to define a new Web service by composing a set of existing services through a process integration-type mechanism with common language control. BPEL4WS is basically a language design to implement the compilation of processes that indicate how the services interface abstractions into the overall execution of the process composition. Indeed, it's designed to be a standard language for process integration. The interface is described as a collection of WSDL portTypes, as is any other Web service (for more information on WSDL, see Chapter 15).

BPEL4WS leverages the concept of message properties used to identify relevant data embedded in messages. Using this mechanism, properties may be viewed in two ways: transparent and opaque:

• Transparent data affect the public business protocols (defined below) directly.

• Opaque data are primarily associated with back-end systems (affecting business protocols by creating nondeterminism).

The effect of opaque data appears within nondeterminism in the actual behavior of services involved in the business protocols; for example, when creating a protocol to define the purchase of a stock. The broker has a service that receives an order request and responds with either a confirmation of the transaction or a denial, using any number of criteria (e.g., price, number of shares, or buyer's credit). Indeed, the decision process is opaque, but the fact of the decision must exist as a behavior in the business protocol.

In essence, the protocol acts as a "switch" within the behavior of the broker's service, although the selection of the branch taken is nondeterministic. To this end, the application of nondeterministic behavior can exist by allowing assignment of the nondeterministic or opaque value to a message property. Thus, the property can then be exploited in defining conditional behavior that captures behavioral alternatives without exploiting the decision processes. The end result is the ability to expose a process to the public, while hiding aspects of the service you would rather not expose to the public.^[2]

^[2] Business Process Execution Language for Web Services, Version 1.0. July 31, 2002.

The applications of this should be readily apparent from our discussion of public versus private processes. Using this mechanism you'll be able to expose behaviors, but can hide any aspect of the service from outside users, typically other organizations. Thus, you can expose a service with assurances that private or proprietary information won't fall into the wrong hands, or be invoked erroneously.

BPEL4WS defines a model and grammar for describing the behavior of a process using the interactions between the process and its partners. These interactions with the partners occur through Web services interfaces, and the structure of the relationships at the interface level exists in an entity known as a service link. It's the job of a BPEL4WS process to describe how these services interact with these partners, defining a more holistic business process, including coordinating logic (sequencing, subprocesses, nesting using outside services, etc.). Within this standard we are able to deal with exception processing and define how individual or composite activities within a process are compensated in cases where exceptions occur.

There are two major concepts to remember when considering BPEL4WS in the context of application integration:

• First, a BPEL4WS process can define a business protocol using the concept of an abstract process, providing a mechanism for identifying protocol-relevant data as message properties using nondeterministic data values hiding private properties.

• Second, it is possible to leverage BPEL4WS to define an executable business process including the logic and state of the process. This mechanism deals with fundamental process integration concepts such as sequencing, subprocesses, and hierarchies.

BPEL4WS exists as an extension of many XML specifications, including:

• WSDL 1.1

• XML Schema 1.0

• XPath 1.0