glassfish_at_javadesktop.org schrieb:
>> 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).
>
That is not possible since (a) it is a stateful SB that has to store
information on the current session (b) 99% of the SB calls need to
return results *synchronously*, while a replacement by MDB will not be
able to store are per-session information or return information
*synchronously*. So this is not a valid solution but imposes more
problems than it solves.
> 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.
>
Exactly. It will be a complete redesign of the application. The much
simpler approach is *not* using temporary queues, but just use a static
JMS topic and filter for self-defined session IDs: In ejbCreate, pass a
GUID that identifies the client, and use that GUID as a JMS header.
Apply a selection criteria in the JMS filter and you're done.
Sad but true, it seems as if temporary queues do not work as soon as
*synchronous* replies are needed or people just do not want to build big
stuff ontop of their current app.
Would be great if future JMS specs would address this issue by defining
a way of passing temporary queues to SBs directly, without the need of
MDBs. :-)
Regards
Markus
> [Message sent by forum member 'whartung' (whartung)]
>
> http://forums.java.net/jive/thread.jspa?messageID=276349
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>