> The samples in the JMS Tutorial
> only will work with MDBs since they take the queue
> instance out the JMSReplyTo header field -- but that
> approach is not possible here, since we do not have
> an MDB reacting to a queue, but a SB reacting to a
> remote method call.
>
> So how shall that work?
Simple, don't use a Session Bean call. The MDB, for this case, replaces the Session Bean as the client interface. The MDB can act as a proxy for the SB if you like, or you can simple refactor the code out of the SB in to code that is called by both the SB and the MDB (assuming you still need the SB interface).
Once the MDB has the message, it can pass the message in to SB calls, and they can directly interact with the temporary queues if they like.
If you have several different methods for your SB, you can simply make it a parameter of the message, and then dispatch on that parameter within the MDB to make the proper call (or you can create a queue for each individual method you'd like to call).
You can also use a common queue for all of the various methods, but have different MDBs using filters to get the specific messages that they're interested in. All sorts of different mechanisms and paradigms that could be parleyed here.
But you need to embrace the idiom of the JMS queue and the MDBs, then rethink your problem in those terms. This isn't a "band aid", rather it's a bit of rearchitecting for your application.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=276349