Asynchronous Message Exchange

Introduction

Two of the advantages offered by SOA and WSDL-defined web services over proprietary, custom-coded communication designs are standardization and loose coupling. Standardization allows applications to communicate without developing, testing and maintaining custom interface code for each new requirement. Loose coupling reduces the brittleness and maintenance headaches that are characteristic of evolving, proprietary interface mechanisms by making the interface itself more generic and also by easing some of the constraints required for successful communication. One important item in the SOA toolbox used to achieve loose coupling is asynchronous message exchange.

This sample provides an exhaustive discussion of asynchronous message exchange and the use of ActiveVOS to design, implement, deploy and troubleshoot a composite application--all from within a single IDE.

Tip:	Numerous steps are involved in working through this comprehensive sample, so active checkboxes are provided to help you keep track of your progress. Check these off as you work through the sample to record which steps you've completed.

Objectives

• Understand the difference between synchronous and asynchronous message exchange patterns and how they relate to WSDL-defined web service operations.
• Understand how asynchronous messaging can be used to implement request-response style communication.
• Create a composite application that uses both synchronous and asynchronous web service operations.
• Decouple response messages from hard-coded endpoint references by specifying a SOAP ReplyTo header during process deployment.
• Add a correlation set to ensure that response messages are routed to the correct requester in a multi-threaded, enterprise environment.
• Become familiar with all phases of composite application development using the ActiveVOS Designer IDE and associated Eclipse plug-ins.

Understanding Synchronous vs. Asynchronous Communication

WSDL-defined web service operations can be designed to use either just an input message or both an input and an output message. In the context of the canonical programming lexicon, these two forms of a web service operation roughly correlate to the difference between a method (or procedure) and a function, respectively, although this distinction has lost some of its rigor as software development conventions have drifted away from their roots in mathematics. A method performs some operation - optionally using some incoming data argument(s) - but doesn't necessarily return a value. A function, on the other hand, performs some operation and always returns a value, i.e., "the function, f, of the argument" or f(x) in algebraic notation.

For web services, an operation defined with both an input and an output message acts like a function, and is considered a two-way or synchronous operation. That is, whenever it is invoked, a synchronous operation is guaranteed to return a value (or a fault) to the caller as a part of its execution. The calling entity must, therefore, suspend its execution until that return value arrives. This type of message exchange is used to implement most request-response web service communication.

Conversely, an operation defined with only an input message is a one-way or asynchronous operation. This type of operation is more like a method, and is guaranteed not to return a value. So an entity invoking such an operation need not suspend execution after the invocation. This type of invocation is sometimes referred to as "fire and forget".

Asynchronous Request-Response

Conveniently, two asynchronous operations can be used together to create the same request-response pattern that is achieved by defining a synchronous, two-way operation (i.e., with both an input and an output message). The advantage here is that when two asynchronous operations are used, the request and the response are implemented by separate operations and, effectively, decoupled.

Asynchronous operations can be used to create a more robust interface by performing two one-way message exchanges (and associated fault handling, etc.) at points in the execution where it's most convenient to do so. This is as opposed to synchronous operation, which constrain (or are constrained by) the associated business logic, i.e., execution must be suspended while waiting for a response. Thus, in addition to loosely coupling the request and response actions, we are also loosely coupling the business logic and the message exchange itself.

The advantages provided by asynchronous message exchange are not without some cost, however.

In an enterprise environment where many requests are being processed simultaneously, some means of correlating message exchanges is needed so that responses are routed back to the appropriate requester instance. BPEL recognizes this, and provides a built-in mechanism to handle it called a correlation set. A BPEL4WS 1.1 or WS-BPEL 2.0 compliant BPEL engine handles run-time correlation automatically. The BPEL process designer's only responsibilities are to define the correlation set and specify where it is initiated and applied in the process at run-time.

In addition to message correlation, it's also a good idea to add error handling logic in the context of one-way messaging at both 'ends'. This includes not only gracefully handling web service operation faults defined as part of the WSDL, but also dealing with cases where a response never arrives due to some platform or environment issue.

This sample discusses all of these issues in the course of creating and debugging an asynchronous communication interface between two BPEL processes.

Getting Set Up

To begin, extract the Zip or Tar archive associated with this sample to a convenient location in your file system. If you're viewing this sample document on-line, the links at the bottom of the menu to the left provide access to the archive (if viewing the off-line version of this document included in the archive, these links will not appear). You'll be importing a project in this archive into ActiveVOS Designer's Project Explorer, so be sure to extract it somewhere accessible to that application.

Once you've extracted the archive...

	...run ActiveVOS Designer and select File / New / Orchestration Project from the main menu.
	In the New Project Orchestration Project dialog, enter a value of AsynchMessageExchange for the project name and click Finish. A new orchestration project appears in the Project Explorer view.

Tip:	The instructions will walk you through creating the sample step by step. The completed project can be found in the support folder included with the sample distribution.

Use Case and Implementation Details

The use case implemented in this sample is kept intentionally simple so as to concentrate on the various BPEL design and deployment issues related to asynchronous message exchange. The three participants are the Initiator, Requester and Responder. The Initiator will invoke the Requestor with a simple message that identifies it as the message originator. The Requester will then communicate that data to the Responder using the asynchronous request-response pattern discussed above. The Responder echoes back the data with some additional identification information and it's then returned by the Requester, which also appends some tracking data, to the Initiator.

In terms of implementation, the Initiator is a Java application that invokes a synchronous operation exposed by the Requester. The Requester is a web service implemented as a BPEL process. The Requester, in turn, invokes an asynchronous (one-way) web service operation exposed by the Responder, which is also implemented using BPEL. The Responder modifies the request data by appending its process ID and then responds by invoking an asynchronous, one-way callback operation exposed by the Requester. The result is passed back to the Initiator, which has suspended its execution, waiting for a synchronous response.

It's important to note a few things about this sample implementation before looking at the code.

First, while the communication between the Initiator and the Requester will be synchronous (i.e., uses a web service operation having both an input and an output message), the dependent communication between Requester and Responder is asynchronous. Whether or not this sort of dependency is practical in a production environment depends on the architecture and timing / resource constraints of a given system and the amount of time required for the Responder to process the request and send its response. In this case it's used purely for demonstration purposes and to keep the Initiator's Java implementation and deployment simple.

Second, because the Responder will be depending upon the Requester (or any other asynch client) to implement a specific operation - or callback - that callback operation is defined in the Responder's WSDL namespace.

Third, because BPEL uses the data in the request messages themselves to perform correlation, and because the string message data in our scenario will be modified during the course of processing, we'll find that we need to specifically define additional data elements to be used for correlation.

 

 

 

 

Copyright © 2004–2008 Active Endpoints, Inc.