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? 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
