Process Lifecycles and Web Services - Invoking Web Services and Providing Web Services
(Page 3 of 4 )
Activities that specify interactions with partners are key to the definition of a BPEL process. Next we'll look at how to invoke operations provided by a partner, and we'll introduce activities that let you expose the entire BPEL process as a Web service.
Invoking Web Services Operations
BPEL provides a specific activity, the invoke activity, that allows a process to call Web services provided by a business partner. As part of the specification of an invoke activity, you select the business partner to interact with using a partner link. You also specify the WSDL portType and operation to be invoked from that partner. The operation can either be a request-response operation or a one-way operation. An input variable that provides the request message for the invocation is required for both types of operations. In the case of a request-response operation, you also need to identify an output variable to store the response message of the invocation, its result.
SkatesTown employs supplier services as well as local services to process purchase orders. The following two BPEL snippets show invoke activities from the purchase order process. The first invokes a one-way operation of the supplier's interface to request additional supplies:
<invoke partnerLink="supplier"
portType="sup:orderSuppliesPortType"
operation="orderSupplies"
inputVariable="orderSuppliesRequest">
...
</invoke>
The second invokes a request-response operation of a local service to validate the purchase order request:
<invoke partnerLink="local"
portType="sup:skatestownPortType"
operation="validatePurchaseOrder"
inputVariable="poSubmissionRequest"
outputVariable="validatePurchaseOrderResponse">
...
</invoke>
As we explained earlier, it's sometimes necessary to correlate multiple interactions with the same process instance. For that reason, invoke activities support associating correlation information, correlation sets, with the outbound request message as well as the inbound response message. Correlation sets may also be initialized as a part of the invocation.
In the following example, the correlation set orderCorrelationSet is provided as part of the request message during the invocation of the supplier's service. It allows the supplier to interact with the same process instance again later—for example, to notify that the request for additional supplies could be fulfilled. This particular correlation set has already been initialized prior to this invoke activity. In addition, the sample depicts the usage of a second correlation set anAdditionalCorrelationSet that has not been initialized before. The attribute initiate specifies whether initialization should happen for a correlation set as part of the invocation, and the attribute pattern indicates whether the correlation set is associated with the input (pattern="in") or output (pattern="out") of a request-response operation:
<invoke partnerLink="supplier"
portType="sup:orderSuppliesPortType"
operation="orderSupplies"
inputVariable="orderSuppliesRequest">
<correlations>
<correlation set="orderCorrelationSet"
initiate="no" pattern="out"/>
<correlation set="anAdditionalCorrelationSet"
initiate="yes" pattern="out"/>
</correlations>
</invoke>
Providing Web Services Operations
Having described what activities BPEL offers to invoke Web services operations, we'll now look at how to specify the services that a process provides to its business partners. A process can offer one-way operations as well as request-response operations. Processes implement their Web services operations using receive activities and reply activities.
A receive activity specifies the operation of the process's WSDL interface that a partner has to invoke. The signature of the operation specifies what request message is to be passed to the process and whether the partner should expect a response message from the process. Furthermore, such invocations can result in the creation of a new process instance, or requests can be submitted to already existing process instances.
The sample process PurchaseOrderProcess provides the Web service operation doSubmission—a request-response operation. It implements this operation using a receive activity and a reply activity as shown in the following snippets. In addition, this receive activity needs to create a new process instance for the purchase order specified by the input of operation doSubmission. This is achieved by setting the createInstance attribute of the receive activity to "yes". Also, the correlation set orderCorrelationSet needs to be initialized as part of the receive activity for later use by the process (as shown in the supplier sample in the previous section).
<receive partnerLink="buyer"
portType="pos:poSubmissionPortType"
operation="doSubmission"
createInstance="yes"
variable="poSubmissionRequest">
<correlations>
<correlation set="orderCorrelationSet"
initiate="yes"/>
</correlations>
</receive>
...
<reply partnerLink="buyer"
portType="pos:poSubmissionPortType"
operation="doSubmission"
variable="poSubmissionResponse">
</reply>
As mentioned in this example, the attribute createInstance lets you specify that a receive activity should create a process instance upon receipt of the corresponding message. It acts as an initiating receive. Otherwise, the receive activity happens as part of an existing process instance. If multiple initiating receive activities are specified for a process, only the first message targeted for one of these receive activities creates the instance. All the other receive activities wait for their corresponding messages with the same correlation set to arrive; they behave as if their createInstance attributes were set to "no". Thus you can define processes that require multiple messages to get started, regardless of the order in which these messages arrive.
The following example shows an interaction with an existing process instance. The operation orderSuppliesOK represents such an interaction: It provides the supplier's response to a prior request of the process to order additional supplies. By calling this operation, the supplier indicates that the request has been completed successfully. It requires a specification to uniquely identify the existing process instance using correlation. The correlation set orderCorrelationSet, initialized previously, serves that purpose:
<receive partnerLink="supplier"
portType="sup:orderSuppliesCallbackPortType"
operation="orderSuppliesOK"
createInstance="no"
variable="orderSuppliesResponse">
<correlations>
<correlation set="orderCorrelationSet"
initiate="no"/>
</correlations>
</receive>
The pick activity is a variant of the receive activity. Whereas receive only allows the specification of one message to arrive, pick waits for the receipt of one message out of a set of specified messages or the occurrence of a timeout—whichever happens first. The timeout can be specified either by a duration (specified by a duration-valued XPath expression) or by a point in time (specified by a deadline-valued XPath expression).
Let's extend the previous example with another potential response from the supplier and a timeout specification, using a pick activity instead of the receive activity. If the supplier can't fulfill SkatesTown's request for additional supplies, the supplier comes back with a different message to indicate that the processing of the request wasn't successful. That is, the purchase order process now waits for two potential messages to arrive as the response from the supplier, only one of which might actually happen. In addition, a timeout is specified to avoid waiting forever. If the supplier doesn't respond within the given timeframe, the process continues with the activity specified as part of the onAlarm element:
<pick>
<onMessage partnerLink="supplier"
portType=
"sup:orderSuppliesCallbackPortType"
operation="orderSuppliesOk"
createInstance="no"
variable="orderSuppliesResponse">
<correlations>
<correlation set="orderCorrelationSet"
initiate="no"/>
</correlations>
...
</onMessage>
<onMessage partnerLink="supplier"
portType=
"sup:orderSuppliesCallbackPortType"
operation="orderSuppliesFailed"
createInstance="no"
variable="orderSuppliesFault">
<correlations>
<correlation set="orderCorrelationSet"
initiate="no"/>
</correlations>
...
</onMessage>
<!-- timeout after one month -->
<onAlarm for="P1M">
...
</onAlarm>
</pick>
Next: Data Handling and Related 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.
|
|
