BPEL4WS Process Syntax | Next Generation Application Integration: From Simple Information to Web Services

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]

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