On Nov 12, 2012, at 12:14 PM, Gege <[email protected]> wrote: > 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).
For a while, I kind of thought they may try and push for a 2.3 version of JAX-WS that would include some server side async stuff, but so far, I haven't heard anything in that regard. Thus, all options right now are proprietary to the implementation/vendor. The 2.2 version of JAX-WS more or less predates the Servlet 3 stuff so async server side really wasn't an option. Now that there are Servlet3 based containers available, it would be work looking at, IMO. That said, I'm really not a fan of Sun's provider based solution. The provider stuff is "OK" but, to me, ignores many of the strengths of JAX-WS, primarily the mapping to/from Java classes/interfaces and the easy integration of JAXB types. I wanted something that mapped onto the JAX-WS generated classes a bit easier but would also allow some level of code first capability. > 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 ^_^ LOL. The main issue (for both CXF and the RI) is that there isn't any sort of NIO based HTTP client within the JDK. To keep the dependency requirements to a minimum, we both use the HttpURLConnection that is in the JDK by default. There is also a performance impact as all the NIO based implementations seem to be a bit slower than the blocking HttpURLConnection when using synchronous methods. With CXF, even if the non-blocking http transport is on the classpath, by default we'll use the faster HttpURLConnection based client for sync calls. The async transport is just used for async calls.. (that is controllable via settings though) > 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. Yep. :-) Dan > 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 >> -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
