Asynchronous Business Delegate

Discussions

J2EE patterns: Asynchronous Business Delegate

  1. Asynchronous Business Delegate (11 messages)

    Asynchronous Service Invocation Strategy for Business Delegate

    Asynchronous Completion Command

    Michael Stevens
    mike at mestevens dot com

    Summary

    The asynchronous business delegate strategy allows methods to be called on the business delegate in an asynchronous fashion. This pattern describes an asynchronous completion command object that is passed along with the request to the business delegate. The asynchronous completion command is executed by the business delegate once the request is completed.

    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.

    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.


    Interfaces

    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

    I will also try to put some sequence diagrams there.

    Threaded Messages (11)

  2. I think from design point of view it will be better to have command and execution part of command separated, because command should be is lightweight object which have only command execution releated info.

    Command extends Serializable
    {
       Name getName()
       CommandTask createTask(ExecutionContext context) throws ...

    }


    public abstract class CommandTask implements Runnable
    {
       .........
        
       public final void run()
       {
          try
          {
              execute(context);
              context.completed();
          }
          catch(Exception e)
          {
             context.failed(e);
          }
       }

       public abstract void execute(ExecutionContext context) throws ...
    }

    In my design I named it CommandExecutor which is simple strategy how to execute given command.
    It's possible to have ThreadPerRequestExecutor, QueuedExecutor, ThreadPoolExecutor, RemoteExecutor and so on.
  3. Hi Giedrius,

    I believe that in the pattern, the command and the execution of the command are separate. The command consists of just the code required to update state when the service request completes. It does not have any code for thread creation, etc.

    The command executor you speak of in the pattern is acutally the AsyncBusinessDelegate. I do see some value in having an executor strategy (GOF) used by the AsyncBusinessDelegate to execute service requests and commands in different ways depending on the context.

    Thanks,

    Mike.

  4. Very good source for this pattern is in Douglas C. Schmidt
    book:

    "Asynchronous Completion Token" -http://www.cs.wustl.edu/~schmidt/POSA/
  5. Thanks for the reference. Also, here is a direct link to a PDF version of that pattern:

    http://www.cs.wustl.edu/~schmidt/PDF/ACT.pdf
  6. Asynchronous Business Delegate[ Go to top ]

    This pattern is nothing more than an ejb-adaption of previously published and already well known patterns (s. Book 'Pattern-Oriented Software Architecture / Patterns for Concurrent and Networked Objects', Wiley, 2000)

    Peter
  7. Asynchronous Business Delegate[ Go to top ]

    How does the client know that the request has completed? Does it need to keep checking for a completed state?
  8. Asynchronous Business Delegate[ Go to top ]

    The client could check to see if the task is complete, or the client could pass a command to the business delegate that will notify the client when the command completes.
  9. Asynchronous Business Delegate[ Go to top ]

    You are correct, it is similiar to that pattern. The reference to the PDF file above by Douglas Schmidt is identical to the pattern as it appears in the book you referenced.
  10. Asynchronous Business Delegate[ Go to top ]

    I didnt liked the idea of thread pooling when JMS and Message Driven Beans are there to do all the work . Using threadpooing is more prone for error and maintainence problems . Also, there is a similar pattern already there in existence namely "Message Facade" which is more efficient than this .

    Read the book "EJB Design Patterns".
  11. Asynchronous Business Delegate[ Go to top ]

    xx xx,

    I doesnt really care what you like if you are tied up in an environment without MDBs right.....

    /P

  12. Asynchronous Business Delegate[ Go to top ]

    Another treatment of this design pattern is covered in the Sun Microsystems book "Core J2EE Patterns: Best Practices and Design Strategies" (http://www.phptr.com/corej2eepatterns). Chapter 9 describes the Service Activator pattern for aynchronous EJB activation.

    The Service Activator is a JMS listener and delegation service which receives a client request message, then returns a job token. The Service then executes the appropriate business components and returns either results or an error report to the client.

    A practical implementation needs to have provision for job status and restart capability in the event of business logic errors, or a system crash.