Hi Dan, > That said, I don't think we have a test for this. The theory is that it > should > work. :-) If it doesn't work, it's a bug that we should get fixed.
Thanks, it is really has an issue there: JAXWSProviderMethodDispatcher returns invoke() method directly from javax.xml.ws.Provider interface and of course this method doesn't contain any annotation. Therefore JAXWSMethodInvoker.adjustMethodAndParams() doesn't recognizes @UseAsyncMethod annotation there. The solution will be either get "real" overriding invoke() method from ServiceObject in JAXWSProviderMethodDispatcher or only check annotation for overriding method in JAXWSMethodInvoker.adjustMethodAndParams(). First solution looks better for me, but second has less side effects. I will create Jira issue and will fix that. Regards, Andrei. > -----Original Message----- > From: Daniel Kulp [mailto:[email protected]] > Sent: Montag, 20. Januar 2014 18:52 > To: [email protected]; Andrei Shakirin > Subject: Re: SOAP async communication in CXF > > > On Jan 20, 2014, at 10:39 AM, Andrei Shakirin <[email protected]> wrote: > > > Hi Christian and Dan, > > > > Thanks for your comments. > > > > I will start to implement my use case on the base of decoupled WS- > Addressing and OneWay's and illustrate that with a blog and example. > > Would like to evaluate the enhancement of using the @UseAsyncMethod > with decoupled WS-Addressing. > > > > @Dan: > > Regarding @UseAsyncMethod and Provider<T>: I am a bit confused with > that, because normally interface have to provide either Future<?> as return > type or AsyncHandler as argument to return response in other thread. How > service implementing Provider<T> could look like with asynchronous style? > > Should be just like in the generated case, but you need to create the extra > method yourself: > > > public class MyProvider implements Provider<Source> { > > @UseAsyncMethod > public Source invoke(Source s) { > ... if continuations aren't supported ..... > } > > public Future<?> invoke(Source s, final AsyncHandler<Source> > asyncHandler) { > final ServerAsyncResponse<Source> r = new > ServerAsyncResponse<Source>(); > new Thread() { > public void run() { > Source s = ... create the response source .... > asyncHandler.handleResponse(r); > } > } .start(); > return r; > } > } > > That said, I don't think we have a test for this. The theory is that it > should > work. :-) If it doesn't work, it's a bug that we should get fixed. > > Dan > > > > > > > Regards, > > Andrei. > > > >> -----Original Message----- > >> From: Daniel Kulp [mailto:[email protected]] > >> Sent: Montag, 20. Januar 2014 14:34 > >> To: [email protected]; Andrei Shakirin > >> Subject: Re: SOAP async communication in CXF > >> > >> > >> On Jan 17, 2014, at 11:22 AM, Andrei Shakirin <[email protected]> > wrote: > >>> I have some requirements regarding async communication for SOAP (the > >> topic is related to > >> http://cxf.547215.n5.nabble.com/Suggestion-regarding- > >> link-between-two-portTypes-and-operations-in-WSDL-td5738657.html , > >> but > >> reformulated): > >>> > >>> 1. Service can process requests for a long time, for example some > >>> days 2. Communication should be possible even with HTTP protocol, > >>> not only with JMS 3. Communication must be tolerant to server > >>> restart => call context have to be persisted > >>> > >>> On the client side JAX-WS provides async methods for generated > >>> clients > >> (via Future<> and AsyncHandler<>) and for generic Dispatch interface > >> (invokeAsync()). > >>> On the server side JAX-WS doesn't define async API, but CXF provides > >>> @UseAsyncMethod annotation > >>> (http://cxf.apache.org/docs/annotations.html#Annotations-org.apache. > >>> cx > >>> f.annotations.UseAsyncMethod%28since2.6.0%29 ) > >>> > >>> However currently I see some limitations of async communication: > >>> 1. CXF doesn't provide async API for the generic, not generated > >>> services > >> (Provider<T>). As a sample we can refer to Metro/RI implementation: > >> https://jax-ws.java.net/nonav/jax-ws-20- > >> fcs/arch/com/sun/xml/ws/api/server/AsyncProvider.html . > >> > >> The UseAsyncMethod annotation thing that we use for the generated > stuff > >> SHOULD also work for Provider based services. If not, it's a bug. > >> > >> > >>> 2. @UseAsyncMethod will be activated only if transport supports > >> asynchronous communication. > >> > >> It likely should also be activated for decoupled WS-Addressing cases and > >> OneWay's. That's certainly a good enhancement request. > >> > >>> 3. There is no concept to persist/restore call context on the service > >>> side. > >>> > >>> The question is: are these requirements interesting for the community? > >> Does it make sense to extend CXF to support such scenarios? > >>> As possible features can be the following: > >>> 1. Provide AsyncProvider like API for generic service > >>> implementations > >> > >> See above. > >> > >>> 2. Simulate async communication via two oneWay operations: one on > >>> client > >> and one on service side. This could help to avoid dependency on > transport. > >>> 3. Provide extension point to persist call context to make possible > >>> finish the > >> request processing even after service restart. > >> > >> THIS would be super hard. Much of the stuff in the context and messages > is > >> not Serializable. I'm really not sure how much could be persisted and > >> recovered reliably. Being generic maps, interceptors and such can add > >> pretty much anything to them which could easily break this. > >> > >> Client side is even more complex. In the decoupled cases, the > >> decoupled endpoint isn't started until the the first request that > >> needs it is sent. Thus, if the client restarts, it wouldn't startup. > >> Thus, we'd need to change that somehow. Bunch of other issues > >> related to callbacks that might no longer be valid and such as well. > >> > >> Honestly, if this is to be modeled as two one-ways, the best option > >> is to really model it as two one ways and pass and > EndpointReferenceType as a > >> parameter. (or header) By actually modeling it as one ways, there is a > >> lot > >> less needed from a correlation standpoint (and any correlation would be > >> done at the application layer). This should also maintain general > >> interoperability and work with other clients such as .NET or Metro. > >> > >> > >> -- > >> 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
