Last week we introduced you to the idea of using existing Web services to build more complex web services. This week, we're going to take a closer look at business processes and their role in constructing Web services. 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).
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.
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 correlationsets (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)
Fault handlers and event handlers
An activity that specifies the business logic of the overall process