It does help ! I'm indeed actually trying both apache's CXF and sun's "jaxws-rt + jax-rs-ri" and it looks like what i want to do isn't finally so simple.
Thanks for pointing out that AsyncProvider is sun-specific. I misunderstood and thought that it was some newer feature of jax-ws that wasn't implemented yet in CXF. Does that mean that there is no "official" way to do an asynchronous implementation of a web-service (unlike for jax-rs 2.0) ? I was about to "prefer" sun's impl because i thought that i would be building over a standardized API (portability for the future). I thought that the whole point of the asynchronous impl would be to use transport based on NIO (non-blocking input / output), to be thread-efficient. So it's interesting to notice that it's not always the case ! I would probably had discovered that later... In a less gentle way ^_^ The asynchronous jax-rs client isn't a heavy requirement because the rest client would be a browser. However the (true) asynchronous soap-server, soap-client, rest-server are important points in order to have a scalable app. Looks like CXF have them all. 2012/11/12 Daniel Kulp <[email protected]>: > > On Nov 11, 2012, at 7:38 AM, Gege <[email protected]> wrote: > >> Hi, >> >> I'm using CXF between two endpoints (both are AS) in SOAP and/or REST over >> HTTP. >> >> I want network callflows to be as simple as possible (no callbacks, plain >> simple request/answer) and i want to be resources-efficient because some >> requests might be long (and i'll have long-polling for events). >> >> So, I need to have asynchronous implementations (in java) of both client >> and servers. >> >> Here is where i stand: >> >> SOAP (jax-ws) : >> - asynchronous client : OK (wsimport + binding.xml) > > Kind of. With 2.6.x and old as well as the reference impl of JAX-WS, the > async clients still consume a thread per request as the underlying > HTTPUrlConnection would require that. Thus, it may not meet your > "resource-efficent" requirements. > > If you use CXF 2.7.0, you can add the Async based http transport which would > allow thousands of outstanding calls with a limited thread pool. > > http://cxf.apache.org/docs/asynchronous-client-http-transport.html > > >> - asynchronous server : not supported yet by CXF (AsyncProvider is >> specified in jax-ws 2.2, it's not the most simple to implement (handle the >> XML myself...) but it should be able to do the job, might be supported in >> jax-ws-ri by sun). > > The AsyncProvider thing is specific to Sun/Oracles JAX-WS implementation. > CXF does not "really" support it. I'm not sure if the @UseAsyncMethod > annotation would work with CXF's provider thing. I'd have to test that. > Interesting thought. > > In general, the UseAsyncMethod thing that CXF supports or direct use of the > continuations is much more flexible. > > > >> REST (jax-rs) : >> - asynchronous client (cxf-wadl2java) : ? i did find anything about >> asynchronous client and I really hope someone can give me a pointer > > 2.7.0 does add SOME of the JAX-RS async client API's, but I don't think on > the wadl2java stuff. The WebClient now has methods that take an > InvocationCallback object that can be used to asynchronously get the > response. However, same limitations as soap. By default, it would be on a > background thread. With the async http transport, we can do more without > the 1:1 request:thread relationship. As the JAX-RS 2.0 spec matures, more > of this will be updated to support the new asynch features in the spec. > > > Hope all that helps! > Dan > > > >> - asynchronous server : OK using AsyncResponse (jax-rs 2.0) and some fixes >> that i'll post once i've tested a bit more >> >> For now, I feel like there are some pieces missing. >> Of course i could implement a REST client myself, but i feel it's a waste. >> There are libraries and utilities everywhere and what I want to do seems >> pretty much in the scope of jax-rs and jax-ws). >> >> Thanks in advance. > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com >
