By digging a bit further, I found that some of these requirements (1: long time processing requests, 2: sync protocols) can be achieved using WS-Addressing Decoupled responses (http://cxf.apache.org/docs/ws-addressing.html#WS-Addressing-Decoupledresponses ).
Anyway, perhaps it makes sense to provide a bit more runtime support for such scenarios: async API for generic services (Provider<T> based), correlation between the messages, persistence of call context. Any thoughts? Regards, Andrei. > -----Original Message----- > From: Andrei Shakirin [mailto:[email protected]] > Sent: Freitag, 17. Januar 2014 17:22 > To: [email protected] > Subject: SOAP async communication in CXF > > 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.
