I would think that you would want your session bean to create a
publisher and a subscriber in the same session, call publish on the
publisher object and block on the receive() method of the subscriber
object. Thus you can have a synchronous request/reply mechanism. You
just have to remember to commit the session after calling publish if
your session is transactional.
HTH,
Noah
Proneel Guptan wrote:
>
> Hi,
>
> Being a newcomer to EJB (and this mailing list), I may be raising a
> question that has already been threshed out previously. My apologies
> if that is the case. I will re-search the archives for that discussion
> (an initial look does not seem to have thrown up any previous threads
> on this specific aspect of EJB-JMS integration).
>
> The backbone of the application I am working on is essentially
> asynchronous. JMS offers everything that is needed to do the job,
> persistent messages, publish/subscribe model etc. We do however want
> to present a synch interface to our clients in some cases and here
> session beans seems to fit the bill. Our data model also seems to fit
> nicely into the use of Entity beans.
>
> In such a case, we would want our session bean to send out an asynch
> message (on a Topic) and wait for a response. The problem is that we
> have been discouraged (or forbidden?) from implementing the
> MessageListener interface in our session bean, because the session bean
> can be passivated any time and would not be invoked on the onMessage().
> Or restating it as a concepts violation, the session bean in EJB1.1 is
> a component for the "synchronous" domain and should not have
> an asynch/callback nature applied on it.
>
> To get around this restriction, we developed a helper class which
> implements the MessageListener interface. The session bean does the
> following:
> synchronize(helperObject)
> {
> helperObject.start(); // To switch on listening for messages in
> the JMS session in helperObject
> helperObject.wait(); // handle InterruptedException
> helperObject.stop(); // To switch off listening for messages in
> the JMS session in helperObject
> // process the message, which is stored in the helperObject
> }
>
> The helperObject meanwhile, in its onMessage() method:
> synchronize(this)
> {
> // process message received as input to onMessage()
> notifyAll();
> }
>
> Note that we ensure that the message listening is switched on only
> when the session bean is actually waiting for a response.
>
> This appears to work. But I am concerned that I may be missing
> some subtle (or not so subtle) problems with such an implementation.
> There doesn't seem to be much treatment on this topic either in books
> or in the JMS/EJB specification (all they seem to say is that the issue
> will be addressed in EJB2.0).
>
> Are there any holes that I cant see?
>
> Regards and Thanks,
> Proneel.
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
S/MIME Cryptographic Signature
