Hi, 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 . 2. @UseAsyncMethod will be activated only if transport supports asynchronous communication. 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 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. Any thoughts regarding that? Regards, Andrei.
