Sergey and I have chatted off and on about some of this, but never really had time to put it to paper or start working on it.
Currently, at the transport level, we support the continuations which, if the transport supports it, allows the service to suspend the processing on the request thread and pick it up later. Thus, for long running processes, the servant can push it onto a workqueue or something and more or less suspend things and resume later. It IS a bit complicated. :-( Also, not all transport support it. Only JMS and HTTP if using the embedded Jetty. HTTPs doesn't work (no continuation support for https with Jetty6, haven't checked jetty 7 yet) and not the servlet version either. (new 3.0 servlet spec would allow it. We haven't updated to the 3.0 version for our servlet yet). We've talked about adding a @UseAyncMethod(timeout = "###") annotation or similar to let the runtime know to use the async method sigs instead of the normal one and layer that on top of the continuations. That would simplify things a lot. Just haven't gotten around to implementing it. That said, if layered on the continuations, it would have the same transport restrictions. If you'd like to help out in this area, I'd be happy to provide pointers. :-) Dan On Sunday 18 April 2010 3:49:19 am Leo Romanoff wrote: > Hi, > > Could someone provide an update of the current status of Server-side > asynchrony for SOAP web services in CXF? Which transports support it? How > it can be done? > > As far as I understand from looking at various descriptions, JMS transport > supports it. > Using WS-Adressing and providing a callback from the client-side that will > be called once server-side is ready should be also a no brainer. > > But what about server-side asynchrony that happens purely on the > server-side, completely transparent for the client? Which transports > support it and how? > > I've found some links about CXF continuations that can be used for that, > but it is not quite clear how to do that and what is the current status: > https://issues.apache.org/jira/browse/CXF-2002 > http://sberyozkin.blogspot.com/2008/12/continuations-in-cxf.html > http://www.mail-archive.com/[email protected]/msg00801.html > > It would be also interesting to see how server-side asynchrony support in > CXF relates to the Sun's Metro SOAP stack support for the same future? > There there are some special interfaces like AsyncProvider and some > alternative proposals: > http://www.docjar.com/docs/api/com/sun/xml/ws/api/server/AsyncProvider.htm > l https://jax-ws.dev.java.net/issues/show_bug.cgi?id=787 (motivation > part is very interesting) > > https://jax-ws.dev.java.net/nonav/issues/showattachment.cgi/266/ResponseDis > patch.html > > Basically, it is very important for many enterprise server-side services to > be able to handle tens and hundreds of thousends requests, where many of > them require a very long time for their completion (due to invoking other > services, doing DBs, etc). Obviously, thread-per-request model would not > work in such situations and would be inefficient anyway. Therefore, > something like continuations in CXF or Fibers/Tubes in Metro are most > likely required to solve the problem. Requests need to be mapped to tasks > representing them and those task should be scheduled in a controlled way > on thread pools with limited number of threads or something similar. > Additionally, some features like timeouts and persistence of such tasks for > long-running operations may be required. Having a common mechanism that is > (mostly) transport independent (HTTP, HTTPs, JMS, etc) and eventually > supports both SOAP and REST services (i.e. JAX-WS and JAX-RS) would be even > better, of course. > > Even if server-side asynchrony is not supported out of the box, it would be > interesting to hear if there are any plans regarding it. In any case, I > would appriciate any advices on implementing scenarios similar to the > described above in a client-transparent scalable way (so, not WS-Addressing > or polling). -- Daniel Kulp [email protected] http://dankulp.com/blog
