Process Lifecycles and Web Services

Process Lifecycles and Web Services
(Page 1 of 4 )

Process Lifecycle and Related Activities

The process definition as outlined in the section "Overall Structure of a Process" serves as a template from which specific process instances are created. For example, for each purchase order, a specific process instance of type PurchaseOrderProcess is responsible for the correct processing of this particular purchase order. A process instance's lifecycle begins with the creation of the instance. The lifecycle ends either upon successful completion of the business logic that implements the process or upon termination of the process instance (for example, through an unhandled fault).

The creation of a specific process instance always happens implicitly on receipt of a message. Therefore, the business logic of a process has to start with an activity that can receive such an initiating message—either a pick or receive activity. For example, the submission of a purchase order results in the creation of the process instance to handle this order.

A business process instance has completed normally if the business logic of the process could be executed successfully. However, if the process instance is terminated explicitly, or if a fault reaches the overall fault handler of the process, the completion is considered abnormal.

For explicit termination of a process instance, BPEL provides the terminate activity g. You can use this activity as part of your process logic whenever you need to terminate the entire process. The terminate activity forces the immediate termination of the process instance, including all its currently running activities.

Looking at the purchase order sample again, a customer may decide to cancel a purchase order, in which case the entire process that deals with this order is to be terminated. The terminate activity is used to implement this behavior:

<terminate/>

Partner Links

Business processes in BPEL are described as a composition of abstract services. This approach provides a higher degree of reusability for the modeled processes. Instead of referring to concrete services, only a logical name—for example, "customer" or "supplier"—and the service interface are used. The resolution to a concrete endpoint happens at a later point in time (for example, when the process is deployed).

In BPEL, this logical construct is the partner Link. Figure 12.2 shows the relationships between partner Links, partner Link Types, and portTypes. Partner Links are used for operations provided or invoked by a business process.

In the diagram, each process invokes a Web service provided by the other process. The orderSuppliesProcess of the supplier exists only virtually. It may be a BPEL process as well, but the BPEL partner Link Type concept doesn't require this.

Figure 12.2  Partner Links and the associated partner Link Type

The following snippet shows an example of partner Link specifications in the purchase order process. Each partner Link declares the role of the process in the communication with the buyer, SkatesTown local services, and the supplier, respectively:

<process ...>
...
<partnerLinks>
<partnerLink name="buyer" 
partnerLinkType=

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

"plt:localPartnerLinkType" 
partnerRole="sellerLocal"/>
<partnerLink name="supplier" 
partnerLinkType=

"plt:orderSuppliesPartnerLinkType" 
myRole="seller" 
partnerRole="supplier"/>
</partnerLinks>
...
</process>

Partner Link Binding

Partner Link Types point to WSDL portTypes with the abstract interface of a Web service. Before the Web service can be invoked, the associated partnerLink must be resolved to a concrete endpoint. The BPEL specification doesn't address the partnerLink resolution and leaves it to the infrastructure. In other words, when a BPEL process is deployed together with the WSDL portTypes that make up the Web service interfaces consumed or provided by the process, additional information is necessary to establish the relationship between the logical partner Link construct and the physical address of a Web service. In the most simple and static case, this can be a mapping of each partner Link and role to a WSDL port.

In Figure 12.3, the binding of the two roles of a partner Link to Web service endpoint is shown from SkatesTown's purchaseOrderProcess point of view. For the seller role, the WSDL port contains the address where the operations of the process itself are provided. For the supplier role, the WSDL port contains the address of the Web service provided by SkatesTown's business partner.

As an alternative to a static association of partner Link with endpoints, the process deployer can specify that the endpoint is bound to the partner Link at runtime and provide a policy that determines how this dynamic binding is performed.

For the dynamic binding of partner Link, BPEL uses the concept of endpoint references. Endpoint references are defined by the WS-Addressing specification as a mechanism to dynamically identify and describe service endpoints and instances. They contain

• The address of a service endpoint

• Optional reference properties that are used by the service endpoint to dispatch a message to the final destination

• Optional elements that identify the WSDL portType, service, and port of the referenced endpoint

• Optional policies to describe behavior, requirements, or capabilities of a service endpoint
  
       

Figure 12.3  Binding a BPEL partnerLink to Web service endpoints

In BPEL, endpoint references can be dynamically assigned to or from message parts.

As an example for the use of endpoint references, consider the asynchronous interface of the supplier introduced earlier. The supplier doesn't just do business with SkatesTown; from the supplier's point of view, many business partners use its orderSupplies Web service. In order to enable the supplier to asynchronously respond to the correct partner, these partners have to identify themselves. Therefore, the request message of the orderSupplies operation contains an endpoint reference of the requester's callback service. In SkatesTown's purchase order process, this part is filled with the service endpoint address of the purchase order process.

You've seen how addresses of Web service endpoints can be dynamically exchanged with business partners in order to enable asynchronous conversations between them. Our example uses a callback address. In addition, we need to direct the asynchronous response back to the right purchase order. Let's look at how to correlate messages with individual stateful services.

blog comments powered by Disqus