On Jan 20, 2014, at 10:39 AM, Andrei Shakirin <[email protected]> wrote:
> 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?
Should be just like in the generated case, but you need to create the extra
method yourself:
public class MyProvider implements Provider<Source> {
@UseAsyncMethod
public Source invoke(Source s) {
… if continuations aren’t supported …..
}
public Future<?> invoke(Source s, final AsyncHandler<Source> asyncHandler) {
final ServerAsyncResponse<Source> r = new ServerAsyncResponse<Source>();
new Thread() {
public void run() {
Source s = … create the response source ….
asyncHandler.handleResponse(r);
}
} .start();
return r;
}
}
That said, I don’t think we have a test for this. The theory is that it
should work. :-) If it doesn’t work, it’s a bug that we should get fixed.
Dan
>
> 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
>
--
Daniel Kulp
[email protected] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
