Hi Andrei,
using WS Adressing to specify the reply to endpoint sounds like a great
solution to me. Perhaps you can create an example and a blog entry for
that case. This might inspire people to use this feature. I for example
did not even realize this possibility exists. If you are interested I
can help to work out the example.
With some example code behind, it is probably also easier to discuss how
we could support long running exchanges in the front end.
I am not yet completely positive about the context persistence. It could
be an interesting feature but as long running processes are always also
connected to the business logic I am not sure how much can be gained
with a persistence on the lower level only.
Christian
On 20.01.2014 12:22, Andrei Shakirin wrote:
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.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
