coordinate async responses...

[Mark Lybarger]

we have a system where a client can send in a request, possibly for multiple logical jobs to be executed. we do each job in the input request, and assemble the responses, then send them to the client.

let's say the request is to post 3 orders to an order processing system. and each order will need to return some xml to the client giving them acknowledgement of their order. it would seem that the processor (splits up jobs and calls a worker) could work more efficiently if it could send an async message to a worker (mdb?) to handle each job, and then coordinate the results back together. what is a common practice/pattern to handle this type of coordination? if we send an async message, how do we get notified that a job is done and results are ready?

[Stan James]

When you send an async request the response comes back as an event later. And you're right: the first tricky bit in the event handler is to match the response up to the request and figure out what to do with it. Message oriented middleware like MQ-Series and other JMS implementations use a correlation id. When you put a request on queue the software gives you a correlation id. When the response comes in it will have the same id. If your async middleware doesn't do that, you can add your own id to the request and response to match them up. I wrote a bit about solutions I've tried HERE. Let me know if that's useful.

[Kyle Brown]

Sounds like you've discovered the need for the Scatter Gather Pattern. If you buy the book, it contains much more detail on implementation tricks.

Kyle

[Ilja Preuss]

You should also take a look at http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Future.html