I noticed a posting on this topic at another forum and I'll like to start a discussion here.

You have a model 2 architecture (jsp -> servlet ->ejb). The jsp makes a request to the servlet which passes off to the ejb. Now the backend process needs to send a message through a MOM and wait for the response. I've got several questions that come to mind. How do you handle, or if you can handle, this problem using JMS. Do you make the servlet or ejb wait/block until it gets a response from the MOM? Any problems with having the ejb/servlet wait or block? What other design techniques/patterns can be applied in this situation?

-Dat

What exactly is supposed to be asynchronous in this scenario?
You make a call, then block and wait for a reply. Sounds pretty synchronous to me. As far as this problem goes, a simple method call is appropriate.
You may have other issues that you need to address (strong decoupling, etc.) but a design to solve such an issue is dependent of the issue itself, IMHO.

As a side note, I've never seen a jsp->servlet->ejb workflow. Usually it's servlet->ejb followed by a forward to a jsp... What did you mean?

Gal

I should have clarified. When I meant jsp -> servlet -> ejb, I was describing the one way trip. I had assumed that everyone would understand the trip back was ejb -> servlet -> jsp.

Actually after giving this some more thought, it seems that although the MOM service itself may be able to support an asynchronous model, you basically have to just block and wait.

My concern now is what happens when this blocking takes a significant amount of time and you have thousands of concurrent requests. I imagine at some point, you have a ton of session beans all blocking and waiting for some data...

I still don't get you about the workflow thing... I never go from a jsp page to a servlet, only the opposite.

If you have thousands of concurrent clients and they all require such heavy services, you're bound to having thousands of threads block around.
Such intense applications are very rare, and you will probably need a big cluster for it... but when the application is this big, you will have the budget for it.

One option that you can consider is moving the whole service into MOM, and have the client just post a request and wait for a reply - no session bean included. MOM provides a more natural mechanism for dynamically increasing the number of boxes serving your clients. That is, as long as the service is stateless. If you put the JMS-related code in a session bean, you don't get this advantage.
JMS has a nice, somewhat unknown facility for using the Request/Reply paradigm on top of the existing JMS facilities. It's in the API.

Gal

Thanks for the suggestion. I haven't considered moving the services into MOM but that would definitely be a feasible solution. As for the request/reply paradigm, I'll take another dip into the JMS API and see if there's something I missed.

Thanks again,
Dat

Sounds like an interesting discussion and I guess I am too late to join this conversation. We have similar requirement of to build systems using asynchronous JMS communication, no doubt there would be too many listeners/threads waiting on the web-tier(serlvet), to get a response back from jms layer. Again it depends on the number of request processed and the kind logic that is getting processed. Questions: 1. Does this way of communication improve performace by any means ? If yes, How ? 2. Clustering and high availability concepts are much matured in EJB, compared to Queue/Topic Clustering. Isn't a draw back to this way of communication. Thanks, Senthil Kumar