"Can I call you later?" "Development of asynchronous services using SCA

This article, the author of IBM's Mike Edwards, discusses the asynchronous services needed to build applications using SOA. The construction of asynchronous services is complex, but using the Service component Architecture (SCA) builds relatively straightforward. This article describes the steps involved in creating an asynchronous service and an asynchronous service client using SCA. Requirements for business processes and asynchronous services

Although we all thought it would be nice to get things done right away, but so far, in real life things often take time to happen, involving a sequence of steps.

Imagine ordering some books online. First search for the book you want, then you may check the current quantity, specify the shipping date and the alternative delivery method. Once the order is sent and paid, the book will not be immediately received:

First, the book Chamber of Commerce sends an order confirmation, as well as the expected shipping date. You may also get a certain type of order number so that you can check the status of the order.

At a later time, the book Chamber of Commerce sends you a confirmation of the delivery of your order and a tracking number that you can use to check the delivery status of the shipping company.

Finally, if you're lucky, you get the book.

Many types of business processes have these characteristics. When we try to build applications that support these business processes, a typical "call-return" style of service is clearly not working well.

Call-return, also known as synchronous processing, is the client invocation service of a service, then stops working and waits for the service to complete its task before the client code continues to work. If the client code has nothing to do, this adds a burden to the system running the client, because it must keep the code in memory while it stops. This is not a problem if the system has only client-side code-but when the system processes thousands of requests for a single client in a minute, the trouble comes quickly.

Another scenario is that the client code can do something else while waiting for the invoked service to complete. Client code that arranges holidays may need to invoke services to schedule flights, hotels, taxis. It is much quicker to process these requests in parallel than it is to call a service once and wait for each one to complete before continuing the next.

In these cases, they are referred to as asynchronous processing. You can think of this as a client sending a request message to a service and then continuing with some new work. The invoked service begins its work, and when the work is done, it sends back a response message to the client. Or it may send back multiple response messages to the client, as you can see in the book, one of the messages confirms the order, and another message indicates the order is distributed.

Tools for building asynchronous services

If there is a need for asynchronous services, what tools are there to help us build these services-and the clients that build asynchronous services?

Most programming models and frameworks provide a good tool for writing clients that synchronize services. The same is true for writing synchronization services. The "Call-return" model for synchronization is the standard form of code written in most programming languages. As a result, writing a synchronization service or a synchronization service client typically does not extend much to the standard programming model. In Java, for example, this usually means that a service is implemented as a method in a class, and that the client of the service is a call to that class method.

The tools for writing asynchronous services and asynchronous service clients have not been well developed. Java is typical of many programming languages, where asynchronous programming becomes a first-class citizen or a recent event-with the advent of concurrent classes in Java 5.

There are also some asynchronous processing tools that can be used through protocol-related programming models [2]. For example, JAX-WS [5] provides a way to write asynchronous clients for synchronization services, using Web services as a means of communication between clients and services.

In this case, assume that the client code for the synchronization service invocation is as follows: this:

OrderResponse placeOrder( OrderRequest oRequest );

Example 1: A simple synchronous placeorder operation

The equivalent asynchronous service invocation is as follows:

Future placeOrderAsync( OrderRequest oRequest,
AsyncHandler responseHandler );

Example 2:placeorder the asynchronous form of the request

The asynchronous response to the call is sent back to the client by an asynchronous response handler declared as follows:

class OrderResponseHandler implements AsyncHandler {
public void handleResponse( Response theResponse ){
OrderResponse orderResponse = theResponse.get();
}
}

Example 3: The handler method is invoked after the PlaceOrder is complete

JAX_WS does not support writing asynchronous services. It also supports situations where only one particular request responds exactly to one.

A Java framework that supports asynchronous-style client and asynchronous services is the JMS API [6]. The JMS API is available when clients and services communicate with a JMS-enabled messaging system. In the Java EE Framework, JMS can be used via message-driven bean[7]. Although the JMS method supports some asynchronous services, JMS binds the client and service code to the use of certain messaging infrastructures.

Finally, a whole language that supports the asynchronous business process that can be imagined has been developed. This is the business Process Execution Language (BPEL) [8]. BPEL is especially good at coordinating a set of services, both synchronous and asynchronous, but it may not be good at writing services or clients that involve a lot of data manipulation.

SCA and Asynchronous services

SCA provides direct support for creating asynchronous and asynchronous service clients. SCA supports an asynchronous service with a simple interaction pattern (one Response message per request message), also supports asynchronous services with more complex interaction patterns (each requesting 0, one, or more response messages)-Remember, our "simple" book process generates two response messages for each book request.

SCA supports the use of asynchronous services written in a wide range of programming languages, including Java and BPEL, for example. In addition, SCA is able to select the communication method between the client and the provider-it may use the messaging infrastructure, such as that used by JMS, but it may also choose to use the Web services infrastructure. SCA does not bind client or service provider code to any particular communication infrastructure.