BPEL4WS and WSDL

Some people confuse BPEL4WS and WSDL; in reality they are very different concepts. First, BPEL4WS leverages WSDL, providing a mechanism to create a coordinating process on top of new or existing Web services defined by WSDL (for more information, see Chapter 15).

WSDL messages and XML schema-type definitions provide the data model leveraged by BPEL4WS processes, and the XPath standard provides support for data manipulation. As mentioned above, all external services are exposed as WSDL services, which is the way Web services work.

Again, at its essence, BPEL4WS is a process modeling mechanism layered on top of the service model defined by WSDL and leveraging a peer-to-peer interaction between the services (see Figure 13.1). Thus, both processes and partners are modeled as WSDL services, with the business processes coordinating the interactions between a process instance and its partners. Indeed, BPEL4WS processes leverage many WSDL services, and it provides the description of the behavior and how these processes interact through a standard Web services interface. Moreover, it's the job of BPEL4WS to define the message exchange protocols leveraged by the business process.

Figure 13.1. BPEL4WS leverages a peer-to-peer interaction between remote or local Web services.

BPEL4WS also leverages WSDL model-based separation between the abstract message contents used by the business process and the deployment information. It's the job of the BPEL4WS process to represent all partners and interactions with these partners in terms of abstract WSDL interfaces.

As I alluded to above, BPEL4WS can be described in two ways: executable business processes and business protocols. Let's dive a bit deeper.

An executable business process models the real behavior of a client in an overall business process. This is the meta process that controls the subprocesses, invoking Web services as needed to support the overall process model. No attempt is made to separate externally visible or "public" aspects of a business process for the internals. In short, this is the "meta-application" that sits on top of the subapplications (Web services) invoking services and abstracting their behavior into an overall controller process that looks much like the pattern of a composite application, but without an interface and with characteristics that are consistent with a process.

Business protocols are a bit different, using process descriptions that specify the mutually visible message exchange behavior of each of the parties leveraging the protocol. This is done without revealing internal behavior. The underlying processes that exist in a business protocol are known as abstract processes and are not executable (unlike executable business processes). Abstract process are used to couple Web services interface definitions with behavioral specifications that are leveraged to control the implementation of business roles and define the behavior that each party participating in the protocol can expect from the others.