BPEL4WS and WSDL
Some people confuse BPEL4WS and WSDL; in reality they are very different concepts. First, BPEL4WS
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
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.
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
are a bit different, using process descriptions that specify the
BPEL4WS Process Syntax
At its essence, the BPEL4WS process itself is a flowchart-like expression of an algorithm.  Each step is known as an activity, and there are a bunch of primitive activities (subactivities if you will) that actually
The notation looks something like this:
Once we understand how these primitive activities occur, we can create more complex algorithms using structure activities, including:
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
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). 
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
Going a bit deeper, a service link type characterizes the relationships between two services through the use of the "role"
<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-
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>