1. We use something very similar in the TwoWayCourier, which is there just for a 'synchronous' response model. It actually sets a temporary queue. It is there for you to use, you can look at the Trailblazer where we used it too.
2. Another example you can look it is the splitter/aggregator. Were we also use correlation tags.
If all you communication is with ESB-messages the problem should be pretty straightforward to solve. If you are talking to an non-esb-aware system then you will have to pull out the property, before sending it out, and putting it back on when the message comes back. This is work you would have an 'adapter' do.
I can't really tell what you scenario is, but I hope this helps.
thanks for the fast reply.
Our current implementation deals with non-esb-aware messages, so I guess that we will use the 'adapter' solution.
This is what we are doing now. In our jbossesb.xml we define a composer class for the gateway:
<jms-listener is-gateway="true" name="RollingStockRequestJMS-Gateway" busidref="RollingStockRequestGW" maxThreads="1"> <property name="composer-class" value="actions.CorrelationPacker"/> <property name="composer-process" value="process"/> </jms-listener>
We then have a router action that takes care of setting the correlatation id on the new JMS message.
Is this the sort of solution you had in mind?
Yep looks good to me.
Alternatively you write your own aggregator, to aggregate messages based on other fields in your message. At one time - in the trailblazer- we looked for a social security number, but personally I prefer to solutions that use plumbing rather then message content.
Good luck :), and let us know how things go.