Home arrow Web Services arrow Page 2 - Process Lifecycles and Web Services
WEB SERVICES

Process Lifecycles and Web Services


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).

Author Info:
By: Sams Publishing
Rating: 5 stars5 stars5 stars5 stars5 stars / 7
August 17, 2006
TABLE OF CONTENTS:
  1. · Process Lifecycles and Web Services
  2. · Properties and Correlation Sets
  3. · Invoking Web Services and Providing Web Services
  4. · Data Handling and Related Activities

print this article
SEARCH DEVARTICLES

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.

<wsbp:property name="customerID" type="xsd:ID"/>
<wsbp:property name="orderNumber"
type="xsd:positiveInteger"/>

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:

<wsbp:propertyAlias propertyName="customerID"
messageType="pos:poSubmissionRequest" 
part="purchaseOrder" 
query="/billTo/id"/>
<wsbp:propertyAlias propertyName="orderNumber"
messageType="pos:poSubmissionRequest" 
part="purchaseOrder" 
query="/id"/>

The two properties defined here are used together in the correlation set orderCorrelationSet. This is the key that identifies a particular instance of the purchase order process:

<correlationSets>
<correlationSet name="orderCorrelationSet"
properties="customerID orderNumber"/> </correlationSets>

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 -->
<correlations>
<correlation set="orderCorrelationSet"
initiate="yes"/> </correlations> ...

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
message --> <correlations> <correlation set="orderCorrelationSet"
initiate="no"/> </correlations> ...

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.


blog comments powered by Disqus
WEB SERVICES ARTICLES

- Dealing with Loose Coupling in a Service-Ori...
- Loose Coupling in a Service-Oriented Archite...
- Safety, Idempotence, and the Resource-Orient...
- The Resource-Oriented Architecture in Action
- Features of the Resource-Oriented Architectu...
- The Resource-Oriented Architecture
- Getting Started with Flex
- Automated Billing and Faxing for the Web
- An Introduction to Web Services
- The Foundations of Web Services: From Novice...
- Web Services Reengineering: Finishing Touches
- Fault Handling with Web Services
- Flow and Web Services
- Process Lifecycles and Web Services
- Business Processes and Web Services

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials