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".
