Jax-ws Oneway WebService not behaving as expected

[B Porter]

Hello All,

I am having problems with a web service I have made for an application using Jax-ws and @Oneway annotation.

I am expecting that with the @Oneway annotation I can pass my parameters off to the web service and allow it to process data concurrently with control
returned to my calling thread as soon as parameters are passed off.

Instead it appears that the processing must be finished before control is relinquished to the calling thread.

Am I misunderstanding the way @Oneway works? or is there some subtlety to it I am missing?

Thanks for any help,
-BP

[Peer Reynders]

B Porter wrote:Am I misunderstanding the way @Oneway works?

Yes. The In-Only message exchange pattern merely indicates that there will not be a SOAP response to the originating sender. However as you are working with an HTTP binding (hence the name "web" service) the HTTP response (with its status code) won't be sent until the "WebMethod" returns. To achieve the effect that you desire, you have to offload the processing entirely (e.g. somewhere in another thread) so that the "WebMethod" can return immediately after it initiates the processing (that runs asynchronously somewhere else).

javax.jws.Oneway

Typically, a oneway method returns the thread of control to the calling application prior to executing the actual business method.

e.g. your method places the processing parameters onto a queue and returns - a worker thread removes the processing parameters from the queue and processes them when it is free to do so.

[arulk pillai]

It is not recommended to start new threads inside Web or EJB containers. You can put the request to a JMS queue and a separate process (e.g. MDB) can pick up and process it asynchronously.

[B Porter]

Do you ranchers think that integrating Quartz job scheduler into the solution would work? I am considering a job that is kicked off per request.

Also, what do you think about integrating Quartz with web service calls in general?

Thanks again for the insights,
BP

[Peer Reynders]

arulk pillai wrote:It is not recommended to start new threads inside Web or EJB containers.

The original poster never indicated the actual run-time environment and the "thread" was a generic example. Granted in Java EE environment a Message-Driven Bean would be the way to go. If JAX-WS is hosted on a pure servlet container like Tomcat the capability for asynchronous processing must be made available through other means. If you are already using Spring, MDPs (Message-Driven POJOS) could be used - however a javax.servlet.ServletContextListener managed java.util.concurrent.BlockingQueue<E> and background worker thread (or java.util.concurrent.ThreadPoolExecutor) could also be viable in the absence of other options.

The point is that "asynchronous processing" capability is not really in the scope of a web services framework. JAX-WS does support client side asynchronous invocation through javax.xml.ws.Response and javax.xml.ws.AsyncHandler<T>. However the actual call is still synchronous - it's just that the client's thread isn't blocked by the web service call.

It needs to be understood that web service frameworks like JAX-WS primarily deal with the "message processing logic" but not necessarily the "core service logic".

[Peer Reynders]

B Porter wrote:Do you ranchers think that integrating Quartz job scheduler into the solution would work? I am considering a job that is kicked off per request.

Looks OK. If you are using a servlet container you can initialize Quartz with the org.quartz.ee.servlet.QuartzInitializerListener.
Now it's just a matter of how thread-safe the various Quartz objects and methods are .

[B Porter]

Thanks for the insight and recommendations.

I will post back my resolution to the problem for completeness when I finish my implementation.

-BP

[B Porter]

Hello Everyone,

So, as promised I wanted to post back my resolution to the issue I presented. I ended up using JMS as implemented by JBOSS Messaging on JBOSS AS 5 to solve my issues. I remained concerned about the thread safety and so went with the EE solution.

I ended up creating an object message and a queue and fed into the object my parameters for the web service. Then I picked up the message with an MDB and made the call out to the JAX-WS web service...

Works Great and seems to scale very well!

Thanks again Ranchers,
BP

[Murali Bando]

This has took longer than we expected for it to come out due to .... This week
it was mainly on Apple not including Java SE 6 in Mac OS 10.5 Leopard, ....
Using @HttpSessionScope: One way to bring state to Web Services is to use Http
... For Servlet based WebServices, you can use com.sun.xml.ws.transport.http.