Business Processes and Web Services - Overall Structure of a Process
(Page 3 of 4 )
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:
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:
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
Next: Basic and Structured Activities >>
More Web Services Articles
More By Sams Publishing
|
 This article is excerpted from chapter 12 of Building Web Services with Java: Making sense of XML, SOAP, WSDL, and UDDI, written by Steve Graham et al. (Sams; ISBN: 0672326418). Check it out today at your favorite bookstore. Buy this book now.
|
|
