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.cxf.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
