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.

graphics/13fig01.gif

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.

BPEL4WS Process Syntax

At its essence, the BPEL4WS process itself is a flowchart-like expression of an algorithm. ^[3] Each step is known as an activity, and there are a bunch of primitive activities (subactivities if you will) that actually

^[3] Weerawarana, Sanjiva. August 2002. Understanding BPEL4WS, Part 1 .

Invoke Web services.
The caller waits for a message to operate on the service's interface to be invoked by an external service.
This generates a response of an input/output operation.
Waits for a certain amount of time.
Copies data from one place to another.
Indicates that an error occurred.
Then terminates the service.
Or else does nothing.

The notation looks something like this:

<invoke>
<receive>
<reply>
<wait>
<assign>
<throw>
<terminate>
<empty>

Once we understand how these primitive activities occur, we can create more complex algorithms using structure activities, including:

<sequence> to define the ordered sequence of steps
<switch> to define case statements and thus branching
<while> to define a loop
<pick> to define a program path
<flow> to define a collection of steps

It is the job of BPEL4WS to provide a service aggregation mechanism, and it bunches those services into a single process, but understand that you're creating a new process, as well. To this end, BPEL4WS processes consist of invocations to other services and/or receiving invocations from clients (those that use the service). We do this using the <invoke> activity and then the <receive> and <replay> activities. These are partner processes, and a partner is a service invoked by a process (invoked partners) or a partner that invokes processes (client partners ).

Invoked partners, using the <invoke> activity, determine the partner to invoke and the innate operation of what operation of which of the partner's portTypes to invoke on that particular partner. It is not unheard of, however, that an invoked partner becomes a client, as well. Thus, we can classify partners as one of three types: services that a process invokes only (invoked partner), services that invoke the process only (client partners), or services that the process invokes and that invoke the process (where either may occur first). ^[4]

^[4] Ibid.

It's the third type that gives rise to the notion of service link types ; rather than describe the relationship between the service and the process from the view of one of the participants , the service link types represent the view from a third-party declaration of a link between two or more services. Moreover, a service link type is also a collection of roles containing portTypes, defining how these services interact with one another. We use service link types to define partners, which are given a name and a binding to a service link type, and identify the role that the process and partner will play. We use the notion of the service reference for the partner to work at runtime, resolving it into a real Web service, and providing a reference for a partner.

Going a bit deeper, a service link type characterizes the relationships between two services through the use of the "role" played by each of the services that exist in the relationship. Moreover, we also specify the portTypes provided by each role. A service link looks like this:

<serviceLinkType name="BrokerLink"
    xmlns="http://schemas.xmlsoap.org/ws/2002/07/
      service-link/">
 <role name="Customer">
  <portType name="buy:BuyerPortType"/>
 </role>
 <role name="Broker">
  <portType name="sell:SellerPortType"/>
 </role>
</serviceLinkType>

The portTypes of each role originate from a specific namespace, but in some instances both roles of a service link type can be defined in terms of portTypes from the namespace.

Keep in mind that portTypes define abstract functionality by leveraging abstract messages, and ports facilitate access to actual information, communication endpoints, and other deployment- related information, including encryption. Bindings provide the link between the two.

As we began to address in our discussion above, service references provide a mechanism for dynamic communication of port-specific data for services, making it possible to dynamically select a provider for a particular type of service and invoke their methods . Within BPEL4WS, there is a mechanism for correlating messages to stateful instances of a service. Service references are defined as typed references, including port-specific data for a particular service, as well as additional data regarding instance-identification tokens.

For example, a service reference looks like this:

<sref:serviceReference
xmlns:sref="http://schemas.xmlsoap.org/ws/2002/07/service-reference/">
  <wsdl:definitions>...</wsdl:definitions>?
  <sref:service name="qname"/>
  <sref:referenceProperties>?
    <sref:property name="qname">+
      <! any element content >
    </sref:property>
  </sref:referenceProperties>
</sref:serviceReference>
^[5]