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

The BPEL language is designed to specify both business proto-
cols and executable processes. A business protocol, called an
abstract process in BPEL, specifies the flow of interactions that a
service may have with other services. For example, one may
accompany a WSDL description with an abstract BPEL process to
inform parties using it in what order and in what situations operations
in the WSDL should be called (e.g., a call to a “request for quote” opera-
tion must precede a call to a “place order” operation). An executable
process is similar to an abstract process, except that it has a slightly
expanded BPEL vocabulary and includes information that enables the
process to be interpreted, such as fully specifying the handling of data
values, and including interactions with private services that one does
not want to expose in the business protocol. For example, when an
order is placed, the executable BPEL process might have to invoke a
number of internal applications wrapped as services (e.g., applications
related to invoicing, customer relationship management, stock control,
and logistics), but these calls should not be visible to the customer and
would be omitted from the abstract process the customer sees. In the
executable variant, the process can be seen as the implementation of a
Web Service. Most work in BPEL has been focused on the executable
variant of the language.
10.5.3 BPEL Process Model
BPEL has its roots in both graph- and calculus-based process models, giv-
ing designers the flexibility to use either or both graph primitives (nodes
and links) and complex control constructs creating implicit control flow. The
two process modeling approaches are integrated through BPEL's exception
handling mechanism. The composition of services results from the use of
predefined interaction activities that can invoke operations on these services
and handle invocations to operations exposed by the process itself. The unit
of composition in BPEL is the activity. Activities are combined through nest-
ing in complex activities with control semantics and/or through the use of
conditional links. In contrast to traditional workflow systems in which data-
flow is explicitly defined using data links, BPEL gives activities the read/
write access to shared, scoped variables. In addition to the main forward
flow, BPEL contains fault handling and rollback capabilities, event handling,
and life-cycle management.
The role of BPEL is to define a new Web Service by composing a set of
existing services through a process-integration-type mechanism with con-
trol language constructs. The entry points correspond to external WSDL cli-
ents invoking either input-only (request) or input/output (request-response)