Business Processes and Web Services

Having specified the external interface of a BPEL process in the previous section, let's look at the internal structure of a process. The simplified example in Listing 12.1 introduces a business process to handle purchase orders: PurchaseOrderProcess. This process orchestrates the steps that are necessary to deal with the purchase order submitted by a SkatesTown customer. It fulfills the specification and requirements as outlined earlier. We'll use this process definition throughout the chapter as the means to explain the constructs provided by BPEL.

Listing 12.1 Structure of a BPEL Process

<!-- Process definition (1) -->
<process name="purchaseOrderProcess" 
targetNamespace="http://www.skatestown.com/

processes/purchaseOrderProcess" 
xmlns:pos="http://www.skatestown.com/

services/interfaces/poSubmission.wsdl" 
xmlns:skt="http://www.skatestown.com/

services/interfaces/skatestown.wsdl" 
xmlns:sup="http://www.wheelsandboards.com/

services/interfaces/orderSupplies.wsdl"
xmlns:plt="http://www.skatestown.com/

processes/poSubmissionPLT"
xmlns:ppa="http://www.skatestown.com/

processes/poSubmissionPPA"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
xmlns="http://schemas.xmlsoap.org/

ws/2003/03/business-process/">
<!-- Partner link definitions (2) -->
<partnerLinks>
<partnerLink name="buyer" 
partnerLinkType=

"plt:purchaseOrderPartnerLinkType"
myRole="seller"/>
<partnerLink name="supplier" 
partnerLinkType=

"plt:allocateStockPartnerLinkType" 
myRole="seller" 
partnerRole="supplier"/>

...
</partnerLinks>
<!-- Partner definitions (3) -->
<partners>
<partner name="skatestownCustomer">
<partnerLink name="buyer"/>
</partner>
<partner name="skatestownSupplier">
<partnerLink name="supplier"/>
</partner>
...
</partners>
<!-- Variable definitions (4) -->
<variables>
<variable name="poSubmissionRequest"
messageType="pos:poSubmissionRequest"/>
<variable name="poSubmissionResponse"
messageType="pos:poSubmissionResponse"/>
<variable name="poSubmissionFaultInvalidPO"
messageType=

"pos:poSubmissionFaultInvalidPO"/>
...
</variables>
<!-- Correlation set definitions (5) -->
<correlationSets>
<correlationSet name="orderCorrelationSet" 
properties="ppa:customerID

ppa:orderNumber"/>
</correlationSets>
<!-- Fault handler definitions (6) -->
<faultHandlers>
<catch faultName="pos:invalidPO">
...
</catch>
...
</faultHandlers>
<!-- Event handler definitions (7) -->
<eventHandlers>
<onMessage partnerLink="buyer" 
portType="pos:poSubmisssionPortType" 
operation="cancelPurchaseOrder" ...>
...
</onMessage>
</eventHandlers>
<!-- Body of business process (8) -->
<sequence>
<!-- receive purchase order from buyer

(service requester) -->
<!-- process purchase order, involves web

services of supplier -->
<!-- reply invoice to buyer

(service requester) -->
...
</sequence>
</process>

The definition of a BPEL process (at number 1 in the code) starts with process- specific attributes as part of its root element, such as the name of the process and its target namespace or the type of the business process. BPEL distinguishes two types of processes, and hence can be applied to two distinct usage scenarios:

• Implementing executable processes

• Describing nonexecutable abstract processes

Our focus is on the first scenario. We'll discuss abstract processes briefly toward the end of the chapter.

Process PurchaseOrderProcess involves various business partners. The customer (as the buyer) submits a purchase order. SkatesTown (as the seller) responds to the customer when the order is complete. SkatesTown also contacts the supplier when stock needs to be replenished to process the purchase order appropriately. As part of the BPEL process, interactions between partners are expressed through partner links (2). Often the conversation between two business partners involves multiple peer-to-peer interactions. The partners g section (3) is a means to group multiple partner links, and as such expresses the capabilities required from a business partner.

The interaction between business partners is based on exchanging messages: The buyer sends a purchase order to the seller; the seller receives the purchase order and exchanges messages with its supplier. Variables (4) are the construct in BPEL to store such messages. In addition, variables can hold data that isn't exchanged with partners—data that is only needed for the internal processing of the business process.

Multiple interactions between partners might be involved in a specific business process instance that happens over a long period of time—days, months, or even years. This requires a means to identify a particular process instance that deals with, for example, a specific purchase order. BPEL introduces the notion of correlation sets (5) for this purpose.

The next sections of the process definition specify different kinds of handlers for the process:

• Fault handlers to catch process faults at the process level (6)

• Event handlers to deal with unsolicited events that can be received and processed in parallel with overall process execution (7)

Finally, a single activity specifies the implementation of the BPEL process: the body of the process (8). In general, this activity consists of nested activities. In our example, these are all the activities needed to handle a purchase order, and their order of execution. Since a business process is always initiated through the receipt of a message, the first step of a process needs to be an activity that can receive a message from a partner.

To summarize, the overall structure of a BPEL process consists of

• Process-specific, top-level attributes

• Partner-related specifications (partner links and partners)

• Variables

• Correlation sets

• Fault handlers and event handlers

• An activity that specifies the business logic of the overall process