Hi,
I am trying to invoke couple of independent services asychronously to search the records in 8 backend systems.I need to aggregate the all the results of the asynchronously invoked services.I have time limit of 12 secs.I am not able to get the records from 8 systems in 12 secs if i invoke the services sychronously.
Please anybody have a suggetion.
This is a good example of an aggregation pattern. You’ve two primary options in wM, one using messaging, the other using your own thread management.
The thread management approach in wM is to spawn your own service threads and then rejoin once those threads have completed their work. There are examples of thread management Java services in the PSUtilities sample package on Advantage using the ServiceThread class. See [url]http://advantage.webmethods.com/article/?id=1614310672[/url]. This approach gives a multi-threaded synchronous service which will hide some of the service flow inside Java and the threading.
I don’t know if the implementation in PSUtilities is quite complete for you - the spawnThread and spawnThread2 services in the misc folder in the latest v7 version of PSUtilities do return threadHandle in the output for the ServiceThread but there doesn’t appear to be a Java service to get the results. You should be able to write a small Java service to use the threadHandle.getIData() which will (I think) block until the service completes and then return the pipeline.
So in simple terms you could spawn threads for asynch calls, maybe make one synch call to keep things simpler, then get the IData from the returning calls in sequence.
The messaging option allows you to publish all the necessary requests for information, and in this case, use the asynch subscribe to collect the responses. The functions in v7 for pub.jms:sendAndWait and pub.jms:waitForReply can be used to send messages and asynchronously pick the reply up later in the same service. I think v6.5 can do similar but don’t have the manuals to hand. Look in the webMethods IS JMS Client Developer’s Guide for details, or look in the Publish Subscribe Developer’s Guide for the traditional IS-Broker connections not JMS.
This option gives you a single Flow service where the asynchronous communication is hidden behind the Flow by the dispatcher handing the responses back to the Flow service at the appropriate point. You do need to make sure that the relevant connection pools or Extended Server settings will support the level of concurrency you need for responses coming back, so make sure you do the calculations around sizing, timing and number of simultaneous requests.
There is an extra variation for this kind of activity where the data is accumulated in a persistent store, and a separate notification trigger is sent to indicate collation of all the necessary data. This is the same kind of aggregation pattern but it is more appropriate for longer duration collections.
Hope that is of some use.
Regards,
Rob D.[/url]
Rob,
Thanks for your suggestion.
I have tried with spawnThread service.I am able to invoke couple of services asychronously and wrote java service to capture the data from threadHandle returned by the spawnThread service.
I understand that the invoking the services and processing is asynchronous and capturing the outputs from each service is synchronous.
This implementation my be works for me.
I am going to invoke 10 services asynchronously using spwanThread service.Is there any risk regarding threads availability on server.?
or any side effects with this design.?
Thanks,
-VSP
Glad that worked for you.
The doThreadInvoke call should still be using the IS Service Manager to invoke the services, so it will consume service threads in exactly the same way as any other mechanism e.g. triggers or an HTTP call.
Someone else may be able to help you on the second part of your question, as I’m not sure which thread pool the thread is going to come from. So if the initial invocation is through the HTTP port, is the asynchronously invoked thread going to to be taken from that pool or the general service thread pool configured for the entire IS? If you’ve got your test running, it’s probably easy enough to confirm - just create a HTTP port with very few threads available (say 3 or 4) and try to spawn more threads.
If I was guessing (and I am), I’d expect the thread to come out of the general thread pool not the pool for the HTTP port because you are operating below the HTTP processor. I’d expect similar if the top level service was invoked through the trigger (the extra threads would not come out of the trigger thread pool i.e. concurrency level).
In this case, you’ll need to either manage the concurrency yourself, or ensure that the server threads setting is high enough for desired level of concurrency (and by implication, that your HTTP thread pool is small enough that the achieved level of concurrency is acceptable for your JVM and infrastructure). Easy enough - max asynch invocations per thread times the number of threads in the HTTP thread pool is how many threads you could in theory consume at any one time.
Regarding side-effects - you can introduce as many side-effects as you’d like. 
Seriously, working inside the service thread and invoking IS services will offer a certain amount of protection, but exercise the usual care associated with concurrent invocations, including any necessary checks for locking, dead-locking, shared access to data, timing, time-out, error handling, orphaned threads, etc.
Cheers,
Rob.
Thank you very much.
I am working on it. I will let you know once i finish the POC.
Thanks,
-VSP.