Help: Best Practices Asynchronous Dispatch

Posted by cwiseman on 11-Nov-2010 10:22

Can someone provide some directions or point me to the best discussions on Asynchronous Dispatch practices?

Here's my use case:

I have a process A containing custom service A which needs to dispatch n messages (driven by the input to process A) to another process/service.  Process A needs to perform the asynchronous dispatches but does not need to wait for any responses from the process/services dispatched to.  However, process A must be able to immediately continue on with its own processing without being held up in any way by the fact that it has been instrumental in spawning other processing.

Thoughts?  Dispatcher Service instance? Asynchronous dispatcher?  What do the experts recommend here.  The kicker is the dispatching process must be able to immediately continue on its thread to complete its service method.

The process/service I am dispatching to (process B through process Z) will perform calls to external web services.  I plan to implement these using SonicConnect services and write the outbound URL destination dynamically.

Thanks in advance.

All Replies

Posted by Bill Wood on 12-Nov-2010 06:54

As long as you don't need to get any of the replies from Processes B....Z you should use the Sonic 8 Dispatch service.

When  you send to B...Z, you should make sure they have a known (non Reply-To) destinatin as their exit (or that they don't exit).   The service listening on the Exit could log or save the messages.

(NOTE: I'm not sure what you mean by Dispatcher Service vs Asynchronous Service.  The 8.0 Dispatch service does a message send, but does not wait for a reply, so it is 'asynchronous' already.)

Posted by mnair on 15-Nov-2010 15:39

If you want to model the dispatch logic in an ESB process then you could use the Dispatch service (provided in 8.0) to perform the asynchronous invocations. While configuring the dispatch service step in the ESB process, you should use one-way mode instead of the Request/Reply mode.

If you would prefer to do this in your custom service then you can use the Async Dispatch API (com.sonicsw.xq.XQDispatch acessible from the XQServiceContext) for the async invocations. When you are using the one-way mode in the dispatch service it also internally uses the same Async Dispatch API.

One thing to keep in mind is that if intracontainer mode is enabled then the Async Dispatch to your process or service will happen in the same thread sequentially for services that are co-located in the ESB container. So for true asynchronous behavior you should do one of the following:

1. In the XQDispatch API, address the message to the entry endpoint of a deployed process or service instead of addressing it directly to the process or service

2. Disable intracontainer messaging.

Thanks

-Mahesh

Posted by cwiseman on 23-Nov-2010 09:34

Thanks guys.

The asynchornous dispatch API in one-way mode was actually going to be my first choice as it is a fire and forget step.  The number of URLs I need to dispatch to and the URLs themselves are driven by the incoming message to the main process.

This thread is closed