Section 5.1. Anatomy of a Process

5.1. Anatomy of a Process

The BPEL specification^[*] is positioned as a business process extension to existing web services standards. In the past, web services were limited to stateless interactions; BPEL and other process and choreography languages show how to build stateful, conversational business processes from web services. BPEL is a rigorous language that builds on and extends web services for interacting processes.

^[*] T. Andrews, M. Curbera, et al., "Business Process Execution Language for Web Services," Version 1.1. http://www.oasis-open.org, May 2004. Available at the following URLs: http://dev2dev.bea.com/technologies/webservices/BPEL4WS.jsp, http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbiz2k2/html/bpel1-1.asp, http://ifr.sap.com/bpel4ws/, http://www.siebel.com/bpel.

A BPEL process definition consists of two types of files:

• Web Services Definition Language (WSDL) files specifying the web service interfacespartner link types, properties, port types and operations, message and partof interest to the process, including services implemented by and called by the process. WSDL is a well-known technology with many uses besides process definition.

• BPEL files, each of which encodes in XML form the definition of a process, including its main activities, partner links, correlation sets, variables, and handlers for compensation, faults, and events.

When combined, the WSDL and the process definition form a business control flow that can act as an interface with external parties through web services. In a sense, the main steps in a processthe ones that drive the floware its service touchpoints, represented by receive, pick, invoke, and reply activities. The most rigid rule of BPEL programming is that a process must begin with a receive or pick activity, implying that a process must start by being called as a service of a particular type. Thereafter, the process's logic is less constrained; it does what is requires to meet its internal business requirements and its public message interchange agreements.

Figure 5-1 depicts a BPEL travel agency process and its surroundings in a typical BPEL architecture.

Figure 5-1. Anatomy of a BPEL travel agency process

The source code is a BPEL XML file and one or more WSDLs. The source is deployed on a BPEL execution engine, which oversees the running of the process logic. The travel agency process starts by receiving a customer's itinerary. It then attempts hotel, flight, and rental car bookings, and finally sends a confirmation to the customer. A corresponding customer process works in concert with the travel agency process; actions in one trigger the other. Interactions with the booking systems of the hotel, airline, and car rental agency are web service-driven, but, transparently to the travel agency application, the booking services are traditionally stateless, not process-oriented. (Chapter 2 develops a comprehensive architectural model featuring a BPEL runtime engine. Chapters 10 and 11 demonstrate the development, deployment, and testing of BPEL processes on the Oracle BPEL Process Manager platform. )

Figure 5-2 shows a UML class diagram of BPEL's object model, and the overall structure of a process.

Figure 5-2. BPEL overall object model

Figure 5-3, another UML diagram, describes the types of process activities.

Table 5-1 summarizes the objects depicted in Figure 5-4.

Figure 5-3. BPEL activity object model

Table 5-1. BPEL objects

Name	Description
Process	A business process containing one or more of the subsequent objects.
Variable	A variable for use in a process or a scope, with a type based on a WSDL message type, an XSD element, or an XSD basic type. A process or scope can have zero or more variables.
Property, Property Alias (from WSDL)	A property is a token of data from a WSDL message. A property alias is an XPath expression to find the value of the property.
CorrelationSet	A set of one or more properties used to correlate message data with the conversational state of the process. A process or scope can have zero or one correlation sets.
Partner Link Type (from WSDL)	A mapping of web service port types to partner roles.
Partner Link	A process' declaration of which partner links it supports and, for each, which role it performs and which role its partner is expected to perform. A process can have one or more partner links.
Partner	Not commonly used; a set of partner links. A process can have zero or more partners.
Compensation Handler	An activity, containing cancellation or rewind logic, to be executed in case a scope or process that has already completed needs to be reverted back to its initial state. A process or scope can have zero or one compensation handlers.
Fault Handler, Catch, CatchAll	A set of handlers to process exceptions, based on fault type, in a process or scope. A process or scope can have zero or one fault handlers; there is no limit on the number of catches within the handler.
EventHandler, onMessage, onAlarm	A set of handles to process unsolicited events, based on event type, in a process or scope. A process or scope can have zero or one event handlers; there is no limit on the number of event detectors within the handler.
Activity	Base type for a BPEL activity. A process or scope has exactly one activity, though that activity can be a structured activity that is broken down into smaller pieces.
Receive	An activity that receives a SOAP message on an inbound web service.
Invoke	An activity that calls a partner's web service, either synchronously or asynchronously.
Reply	An activity that returns a synchronous reply to an inbound web service call triggered by a receive.
Compensate	An activity that triggers the compensation of a given scope or process.
Throw	An activity that generates a fault, triggering the fault handler for the given process or scope.
Assign	An activity that copies data from one variable to another.
Wait	An activity that pauses the process for a specified duration, or until a specified time.
Empty	No-op. Performs no action.
Switch	An exclusive-OR structure. Executes the activity for the conditional case that evaluates to true.
Flow	A distinctive parallel activity execution structure with support for directed graph-based flow.
Sequence	Runs a set of activities sequentially.
Pick	Waits for exactly one of several events (including timeouts) to occur. Executes the activity corresponding to the first event that fires.
While	Runs an activity in a loop for as long as a given XPath-valued expression is true.
Scope	An activity with its own set of handlers, variables, and correlation sets.

EXECUTABLE AND ABSTRACT PROCESSES

A BPEL process can be executable or abstract . An executable process is built to actually run in a process engine. An abstract process is a protocol definition or an account of the publicly observable behavior of a given participant. Though in this book we use BPEL strictly for executable purposes, the motivation for the abstract approach is important to understand. WSDL in isolation describes only the static structure of a partner's interface: its inbound and outbound services. An abstract process, in contrast, is behavioral; it describes the control flow exhibited by the partner as its interfaces with its partners. A BPEL abstract process, in this regard, serves the same purpose as a WSCI interface (described in Chapter 8).

The BPEL code for an abstract process resembles that of an executable process, except that the abstract process contains only activities that model public interaction or drive control flow; an abstract process can use process data but only for the evaluation of conditions that affect control flow.

Abstract processes set the attribute abstractProcess="yes" in their process elements.