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?
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.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
I want my playground back. Here, I'll give you this tiny ad for it: