asynchronous operations and Web services, part 3rd: Adding Business Semantics to a Web service

In the first two parts of this series, Holt Adams explains the relevance of the WEB services asynchronous operation and discusses some patterns for building asynchronous services. Now, he's going to start explaining the business Process execution language for three new specifications ―web Services (Business process Execution Language for Web Services), Web Service Coordination (Web services coordination) and Web service transactions (Web services Transaction)--and explain how they provide many possibilities for Web service developers. You will see how these three specifications support asynchronous operations and create a running programming environment that reflects the actual business interaction.

The days are just a little bit easier for IT architects and business analysts who want to use WEB services to integrate their business processes with their partners. In the first article in this series, I mentioned that support for asynchronous operations is simplified as the industry further develops decisions on how to reconcile the flow of Web services and how to describe the dependencies between Web services that implement business processes. "Well, guess what just happened?" August 9, IBM, Microsoft, and BEA released a jointly developed set of specifications for adding business semantics to Web services. These three specifications have been published throughout the industry for further development, along with a number of programs that list the additional features to meet, which are designed to initiate the standardization process required to meet a very important set of customer processes and transaction requirements. These specifications are the business Process Execution language (BPEL4WS or BPEL) of the Web Service, Web Service coordination (ws-coordination or WS-C), and Web service transactions (ws-transaction or WS-T). These three specifications do enable organizations to describe their business processes in a comprehensive model, and also provide an implementation framework for implementing the model, coordinating business activities, and transactional behavior. This article outlines how the BPEL, Ws-c, and WS-T specifications simplify support for asynchronous operations. More importantly, you will also understand how these specifications describe and implement enterprise business interactions that typically carry out a series of point-to-point message exchanges in a long-running stateful interaction involving two or more parties or more.

In earlier articles in this series, I introduced some concepts of asynchronous WEB service operations, as well as the various integration patterns used to implement asynchronous operations between the two parties. These patterns are essentially modeled as stateless, independent interactions. In these patterns, I propose a requirement for participating applications or messaging transmissions to create and manage the correlator when mapping requests to responses. Similarly, the solution Designer also needs to provide a way to provide the service provider with the reply address (the response will be sent to this address), so that when the response is available, it can be sent to the requesting client on separate execution threads (reply-to). All of these requirements, and other more important requirements (such as coordinating a set of stateful interactions and routing requests to stateful process instances) will be met in the new specification. As a result, we can model and directly execute complex, actual enterprise processes within the business process engine (business process engine) (more often immediately on the engine).

Currently, version 1.1 of the Web Service Description Language (Web Services Description LANGUAGE,WSDL) specification supports only stateless interaction models that exchange synchronous messages between two parties or asynchronous messages that are not associated with each other in this model. The release of these three new specifications makes it possible to support such enterprise business processes that involve a point-to-point message exchange sequence (synchronous and asynchronous) interaction model between a stateful and long-running interaction between two or more parties in a state.

Before you go further, you should have a basic understanding of the BPEL, Ws-c, and ws-t specifications, as we will explore many of the concepts from these specifications here. Asynchronous Operational Requirements: review

Supporting actual enterprise business processes involves asynchronous operations in nature, because they last longer. Each activity of each process needs to be separated from the initial request to optimize the use of system resources, and the processing process needs to be decomposed into a set of recoverable transactions. As I mentioned in the first article in this series, there are several tasks that are required to support asynchronous operations:

Define one or a set of correlator and a mechanism for their exchange.

Define a reply-to address that specifies where the response should be sent and ensures that the destination is notified to the service provider.

The process by which a service provider generates a response is separated from the request as a transaction.

The client receives an asynchronous response.

The client and service provider associate the response with the corresponding request.

In addition, because I will discuss asynchronous operations in the context of larger stateful business transactions that may involve many interactions between the process and its partners, messages exchanged during asynchronous operations will need to be routed to the same orchestration instance. Therefore, I also need to present another requirement not included in the first article of this series:

Routing requests to stateful business process instances.

BPEL XML Syntax elements

This article outlines how BPEL simplifies the process of integrating partner business processes for long-running business transactions, where one business transaction consists of multiple interactions between the process and its partners. In the following sections, I will provide examples of specific BPEL XML syntax that can be used to satisfy the asynchronous operational requirements identified above.

The BPEL XML streaming language has syntax to describe the activity and the mechanisms used to control the flow behavior. In my example, I'm going to use a subset of this syntax, which contains the following activity tags (active token) and elements (element):

Basic activity: The receipt of inbound requests and responses, the allocation of data to the global container, and the generation of outbound WEB service requests. Examples of these activities that this article will demonstrate include receive and invoke.

Structured activities (structured activity): The entire process flow that manages the sequence of activities, the parallel processing of activities, and the addition of conditional logic when controlling the flow of a process. Examples of these activities that this article will demonstrate include sequence and flow.

Other BPEL XML elements help define the relationships and dependencies that are required to support asynchronous operations in business transactions. Examples of these elements that this article will demonstrate include the servicelinktypes, the role, link, source, and Target.