On Jan 22, 2014, at 5:33 AM, Andrei Shakirin <[email protected]> wrote:
> 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’d go with the second. According to: http://mail-archives.apache.org/mod_mbox/cxf-commits/200906.mbox/%3C20090629194405.15A8A23888E7%40eris.apache.org%3E returning the Provider method was explicitly needed due to something with proxies, but I really don’t remember why. :-( Dan > > 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 > -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
