Thanks, Ian.
A couple of more questions (I'm very new to EJB so ...):
Since MessageConsumer.receive() has a timeout value (blocks until a message
is received), I was wondering about the tight loop. I assume that you mean
one or both of the following: i) the JMS implementation of
MessageConsumer.receive() may involve polling (although I don't see this
given native platform support for events, etc.) ii) that we will receive
other messages and have to filter them out on the client side (even if we
use a Message Selector for the MessageConsumer the filtering is still done
on the client side).
Thanks again,
Bill
-----Original Message-----
From: Ian McCallion
To: [EMAIL PROTECTED]
Sent: 7/5/01 6:14 AM
Subject: Re: Sync client reqst to bean that uses async (JMS)component
Bill Leonard wrote:
>
> I have a client that sends a synchronous request to my session bean
and
> expects the response to be sent synchronously. In order to fulfill
the
> request, the session bean talks to a component that uses JMS.
Therefore,
> the session bean publishes the request to the JMS-based component.
Now, the
> response from the JMS-based component is received only by subscribing
to a
> topic. In order for my session bean to return the response to the
client in
> the same thread (synchronously), it has to do one of the following:
>
> 1) the session bean can poll the destination using the
> MessageConsumer.receive()methods.
> 2) block on some event (??); Its MessageListener code would then
receive the
> published response (in a thread started by the JMS provider). It
would then
> signal the event on the session_bean. The session bean would become
> unblocked and return the response to the client.
>
> I know (1) can be done. Is (2) possible?
>
> Also, I first thought that Message Driven Beans might be helpful but,
after
> reading about them, I see that in the above scenario, I'm still faced
with
> trying to get a session bean to act synchronously. If I used an MDB
instead
> of a session bean, the client would then have to communicate with the
MDB
> using publish/subscribe (and I wanted the client to communicate
> synchronously)
Bill,
EJBs should not go into a tight loop because it consumes processing
power that
is needed for other clients. This eliminates (1) unless you involve the
client
in the polling.
EJBs should not block because it upsets the server's pooling
arrangements - the
EJB is in-method for a potentially extended period and cannot be
passivated.
This eliminates (2).
Hence, given that the primary application of messaging technology is
legacy
integration, MDB is pretty well brain-dead as a way to integrate EJB and
messaging :-(
What you'd like to be able to do, but can't, is place any EJB into a
passivatable state waiting for a JMS event. Here's one way to extend the
EJB
architecture to achieve this:
- Define a new Exception that EJBs would throw
when they wanted to wait for a JMS event:
package javax.ejb;
public class WaitingFor extends Exception
{
public WaitingFor(Event e){ }
}
- The container's implementation of this would be:
- catch the exception
- set up a listener for the event
- redrive the client method when the event occurred.
- EJBs using this would:
- recognise the redriven method
- consume the message
- complete its processing
- return the answer to the client.
In the absence of any such EJB extension (EJB 3.0 perhaps???) you will
need to
develop a connector that you can call synchronously. Connectors, being
middleware, can block, though of course there's no magic here -
extensive
blocking and/or polling would still upset the server.
========================================
Ian McCallion
Alexis Systems Limited
Romsey, UK
Tel: +44 1794 514883
Fax: +44 1794 501692
========================================
========================================================================
===
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".
===========================================================================
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".
