Last week, we began taking a look at business processes and their role in constructing web services. This week, we will look at process lifecycles, invoking and providing web services, and more. This article, the third in a series, 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: 672326418).
Process Lifecycles and Web Services - Properties and Correlation Sets (Page 2 of 4 )
The external interface of a BPEL process is described by portTypes; however, WSDL has no notion of a stateful Web service. Every time a new purchase order request arrives at the SkatesTown WSDL port, a new instance of the purchase order process is created. Each process instance may perform an asynchronous interaction with the supplier Web service. Furthermore, a customer can cancel a running purchase order. We need a way to make sure all these operations take place using the same instance of a purchase order.
In order to allow the correlation of messages with process instances, each message must carry an identification of the process instance the request is targeted for. This may be a unique key associated with the process instance when it's initiated, or application data mapped to a unique instance key.
BPEL doesn't require a separate instance key. Fields within the application data are used to identify BPEL process instances. Such fields are called properties. A property is a named, typed data element that is defined as a WSDL extension element. The property value is extracted from an instance of a WSDL message by applying a message-specific XPath expression. A propertyAlias defines the relationship between the property and the data field in the message.
In some cases, a single data field isn't sufficient. For example, if a customer submits a new purchase order before a previous purchase order has been processed, then the customer is associated with two running purchase order instances. Therefore, just using the customer identification isn't sufficient to correlate messages to a single process instance. In addition to the customer ID, you can use an order number: The customer ID and the order number together form a unique process instance key called a correlation set.
The diagram in Figure 12.4 shows the poSubmissionRequest WSDL message. It carries a part purchaseOrder of a complex XML schema type. The part has two key elements identified by the XPath expressions /billTo/id and /id. These elements are associated with the properties customerId and orderNumber via a property alias definition. The two properties together form the correlation set orderCorrelationSet, which is the unique key for one instance of the purchaseOrderProcess. If the customer chooses to cancel the purchase order, the cancellation request must carry the same correlation data.
Figure 12.4 Process with correlation set
The following snippet shows a definition of the properties with their XML schema type.
For each property, a property alias definition must be provided for every WSDL message type that may contain this property. In the following property alias example, each property defined before is mapped to the WSDL message definition for the purchase order request. In addition to the message type, the property alias also names the part of the message and the XPath into the part that allows the extraction of the property value:
How are correlation sets associated with particular values? When a correlation set is first used within a process, the set of properties must be initialized. In a multipartner conversation, the partner starting the message exchange and creating the property values is called the initiator. The other partners are followers of the message exchange.
A correlation set can be used with all types of activities that deal with inbound (received) or outbound (sent) messages. The initialization may happen either when a message is received or when a message is sent. In the first case, the partner that sends a message to the process is setting the correlation data. In the second case, the correlation data is created by the process. The activity that refers to a correlation set explicitly states whether the correlation set is initialized. The following code snippet shows how a correlation set can be referred to from within activities; it is initiated (initialized) when it's used for the first time:
<!-- Receive the purchase order request message -->
After the initialization of a correlation set, it's considered immutable. All other activities referring to this correlation set must not change any of the properties.
In the following snippet, the correlation set isn't initiated. On receipt of a message, it's used to correlate the message with the correct process instance:
<!-- Receive the purchase order cancellation
If a message is sent out and the correlation set isn't initiated, then it's used to verify that the message contains the unchanged property values.