Service Composition - Guide to Cloud Computing for Business and Technology Managers - page 221

BPEL can also be extended to provide other important composition language
properties such as support for Web Service policies and security and reli-
able messaging requirements. In this section, we summarize the most salient
BPEL features and constructs.
10.5.1 Background of WSDL
BPEL's composition model makes extensive use of Web Services Description
Language, WSDL. It is therefore necessary to provide an overview of WSDL
before going into the details of BPEL itself. A WSDL description consists of
two parts: an abstract part defining the offered functionality and a concrete
part defining how and where this functionality may be accessed. By sepa-
rating the abstract from the concrete, WSDL enables an abstract component
to be implemented by multiple code artifacts and deployed using different
communication protocols and programming models.
The abstract part of a WSDL definition consists of one or more interfaces,
called portTypes in WSDL. PortTypes specify the operations provided by
the service and their input and/or output message structures. Each mes-
sage consists of a set of parts; the types of these parts are usually defined
using XML schema. The concrete part of a WSDL definition consists of
three parts. It binds the portType to available transport protocol and data
encoding formats in a set of one or more bindings. It provides the location
of endpoints that offer the functionality specified in a portType over an
available binding in one or more ports. Finally, it provides a collection of
ports as services.
10.5.2 BPEL4WS
BPEL4WS is a workflow-based composition language geared toward
service-oriented computing and layered as part of the Web Service technol-
ogy stack. BPEL composes services by defining control semantics around
a set of interactions with the services being composed. The composition
is recursive; a BPEL process itself is naturally exposed as a Web Service,
with incoming messages and their optional replies mapped to calls to
WSDL operations offered by the process. Offering processes as services
enables interwork flow interaction, higher levels of reuse, and additional
scalability.
Processes in BPEL are defined using only the abstract definitions of the
composed services, that is, the abstract part (portType/operations/messages)
of their WSDL definitions. The binding to actual physical endpoints and the
mapping of data to the representation required by these endpoints is inten-
tionally left out of the process definition, allowing the choice to be made at
deployment time, at design time, or during execution. Added to the use of
open XML specifications and standards, this enables two main goals: flex-
ibility of integration and portability of processes.