Motivation

The Business Delegate pattern is a local proxy for a ServiceFacade. The Business Delegate allows the service client to call the service without having to worry about looking up a bean instance or other things related to calling remote service methods. The Business Delegate pattern implies that methods will be called in synchronous fashion. That is, the method will be called and control will not return to the client until the service is finished executing the method.

It would be useful to have a Business Delegate interface that supports the ability to call methods in an asynchronous fashion. In an asynchronous method invocation, the method is called and control immediately returns to the calling client. When the client makes a call to the service method, it gives the service method an asynchronous completion command. This command contains the logic that will be executed when the service method completes.

References

This pattern is based on the pattern “Asynchronous Completion Token”, Douglas C. Schmidt, Siemens AG, 1998, 1999.

Applicability

Use this pattern when the client does not have to wait for the response to be complete before processing continues. This pattern can also be used when multiple long transactions must be completed by the client. A single business delegate method may call multiple service methods asynchronously. By executing the multiple transactions in parallel, the time taken for the entire process is only as long as the single longest transaction.

Participants

Command, Business Delegate, Session Façade

Behavior

An asynchronous completion command uses the classic command pattern. The asynchronous completion command implements an interface that contains an execute(ServiceResults) method. The execute(ServiceResults) method on the asynchronous completion command is called by the BusinessDelegate when the command completes. The execute method is passed a ServiceResults object. The ServiceResults object contains the results of the service call. For example, if a customer search is performed, then the ServiceResults object would contain the customer information from the database.

Implementation

This pattern is implemented by creating a business delegate that spawns a calling thread when a service method is called. A robust implementation will use a thread pool so that too many calling threads aren’t spawned so that system performance isn’t compromised. The business delegate gives the calling thread the service request and the asynchronous completion command. The calling thread invokes the service method and waits for a response. In the meantime, control has returned to the client. The service method finishes and the calling thread receives the service results. The calling thread calls the asynchronous completion command with the service results.

Consequences

1) Without using a thread pool, the server could get swamped if many requests are made simultaneously.

2) Reduced execution time by spawning multiple requests to many session facades. The total transaction time is only as long as the longest request.

3) JMS and message driven beans provide a better method for asynchronous requests. If that option is available, it should be explored.

public interface AsyncBusinessDelegate {

public RequestHandle request(ServiceRequest request, CompletionCommand command); // Returns a request id.

public int checkStatus(RequestHandle requestHandle);

}

public interface CompletionCommand {

public void execute();

}

For a current version of this pattern, please see:

http://www.mestevens.com/AsyncBusinessDelegate.htm