On Wednesday 21 April 2010 10:35:12 am Roman Levenstein wrote: > > 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. > > Thanks for the explanation. What bothers me a bit, is that you are > very implementation centric (continuations, Servlets 3.0). > But what about the asynchrony support in the JSR spec? > What about compatibility with other JAX-WS implementations?
Well, that would require updates and enhancements to the JAX-WS spec. :-) More in a sec... > Why I'm wondering about are two things: > 1) Why there is no co-operation into bringing up server-side > asynchrony issues at the JSR level? Well, when producing the JAX-WS spec, everything presented in the spec must be "doable" using the standard technologies and normal deployment environments. In the case of JAX-WS, the "normal" environment is to have the services deployed in a war with some sort of Servlet frontend. (btw: the TCK runs by deploying wars in tomcat) Thus, any requirements of the spec MUST be implementable on that technology. However, the Async stuff you describe is NOT implementable on a Servlet 2.x container. When the servlet container calls the servlet, when the servlet returns, it assumes it has completed and will flush the response (and close the connection if no keep-alive). Thus, there is no way for the servlet container to "wait" for a response via a Future object without consuming the request thread. It's just not possible. That is one main reason it's not addressed as part of the JAX-WS spec as it would not be implementable on current technology. In glassfish, Metro doesn't use a servlet and can hook into the HTTP stack furthur down and thus it works there. However, if you deploy the same Async service as a war into tomcat, the async stuff would no longer work. Basically, for any async stuff to work, there HAS to be support from the underlying transport for it to even be possible. With Servlet 2.x, there isn't support for it. With servlet 3.x, there is some support. Maybe a future version of the spec would add support now that Servlet 3.x is final. I don't really know. > Or at least working on a cross-implementation interoperability or > reuse of "user-space" code developed by JAX-WS users, when they want > to use the server-side asynchrony support. It would be very nice, if > the same code can be run on Metro, CXF, Axis and other JAX-WS > implementations. Today we have to write JAX-WS implementation specific > code. > > 2) Why asynchrony support is so low on the JAX-WS implementors agenda? See above. A spec must be implementable or it's a pretty useless spec. > I discovered massive problems in Metro and CXF when it comes to > this topic (both client-side and server-side). > Does it mean that there are other ways for achieving > high-performance and scalable (e.g. able to support thousands of > simultaneous requests) server-side WS processing? JMS? Seriously, I think a semi-normal way of handling such stuff would involve either using more of a polling method or callback where a client would start a long running process and either pass a reference to receive a callback when complete or get back some sort of process ID that it could then invoke another "getResult(id)" method later to see if it's done and get the result. I guess it requires thinking of it more from a messaging standpoint instead of a request/reply standpoint, even on the client side. > Or does it mean that there is not real interest in scaling WS > processing that high? > Were any JAX-WS frameworks used AT ALL for such kinds of scalable > processing? If so, do you have any references and performance figures? > Or are these frameworks good only for mostly low- or medium-load > scenarios? Or may be I just expect too much from SOAP stacks and something > else should be used instead for really high-performance scenarios, e.g. > JMS, REST, ESBs (non SOAP based ;-) etc? Well, REST in Java would have much of the same problems. If it's implemented via a servlet type thing, same issue. Likewise for ESB if only dealing with HTTP. JMS is possibly the right solution or using a ESB along with JMS. -- Daniel Kulp [email protected] http://dankulp.com/blog
