If you set an endpoint property of “org.apache.cxf.oneway.robust” to “true” on 
the service, the one ways are handled very differently.   It MAY work for your 
case, but I’m not really sure.   The 202 is sent back AFTER the service is 
called, but before the response message is called.    It may be what you need.  
 

Dan



> On Jul 5, 2019, at 6:32 AM, Henning Blohm <henning.bl...@zfabrik.de> wrote:
> 
> Hi Andrei,
> 
> responding with a 202 is absolutely fine. Responding without giving the
> application a chance of deciding whether the message makes sense is a
> little too aggressive.
> 
> In the specific case, the other party is already existing and there was no
> way for us to change it. As far as I can tell, the remote service was
> implemented using .Net.
> 
> The way it works on their side is that WS-Addressing is used to supply a
> callback address (us in that case)  but the first gets a real synchronous
> response indicating whether the original request was accepted or not. If
> so, the callback address will be called later with the actual processing
> result. This is the scenario b) below.
> 
> In order to achieve this behavior, we disabled WS-Addressing processing by
> CXF for the service endpoint, so that there is no asynch response sent by
> CXF and turn addressing on again and set WS-Addressing data on an outbound
> interceptor.
> 
> Thanks,
> Henning
> 
> Am Do., 4. Juli 2019 um 17:29 Uhr schrieb Andrei Shakirin
> <ashaki...@talend.com.invalid>:
> 
>> Hi,
>> 
>> 202 as response for one-way is designed. The idea is that client thread
>> must not wait for the response, it is asynchronous communication.
>> There are three ways to implement this requirement:
>> 1) use WS-Addressing and WSA-ReplyTo header
>> 2) use two independent one-way calls
>> 3) use native async transport JMX
>> 
>> I described some details of this in
>> http://ashakirin-cxf-async.blogspot.com/
>> 
>> Regards,
>> Andrei.
>> 
>> -----Original Message-----
>> From: Henning Blohm <henning.bl...@zfabrik.de>
>> Sent: Montag, 10. Juni 2019 12:40
>> To: users@cxf.apache.org
>> Subject: Robust Asynchronous Message Exchange using WS-Addressing
>> 
>> 
>> Warning! External email. Exercise caution when opening attachments or
>> clicking any links.
>> 
>> 
>> Hello CXF users,
>> 
>> I would like to ask for some advise on how to handle a robust asynchronous
>> message exchange using WS-Addressing and CXF.
>> 
>> So system A sends a message to system B for processing, and if B accepts
>> the message, system A will receive some later callback from B conveying
>> some information on how processing of the message worked out.
>> 
>> It should be possible for B to check on correctness of the message and B
>> should be able to setup whatever is needed for later (e.g. commit some data
>> to a database, put something into some queue) before it confirms submission
>> of message.
>> 
>> For non-technical reasons I would like to use WS-Addressing to communicate
>> the callback address.
>> 
>> I tried two approaches:
>> 
>> a) A One-Way service.
>> 
>> In that case, I noticed, CXF already returns an HTTP 202 (Accepted) reply
>> before the application has any chance to get its hands on the message.
>> I found no (harmless) way to have CXF wait for the application to check
>> and really "accept" the message.
>> 
>> I would really like to be able to validate the incoming message and safely
>> put it in a processing queue before replying with a 202 response.
>> 
>> Is that possible?
>> 
>> 
>> b) A Two-Way service with (empty) response message (even if no content)
>> 
>> In that case, using WS-Addressing CXF sends an empty SOAP response to the
>> replyTo address on its own with a new request after the method call
>> completed.
>> 
>> I would really like to be able to synchronously reply with a simple
>> message indicating whether submission was successful and if so, send a more
>> detailed processing message to the replyTo callback when processing is done.
>> 
>> Is that possible?
>> 
>> 
>> So, in essence, I would like to use WS-Addressing to specify a callback
>> address and return some simple response synchronously for the incoming call
>> while using the callback address for a more detailed callback later.
>> 
>> Would one of the two approaches above work or should I follow some other
>> direction.
>> 
>> Thanks,
>> Henning
>> As a recipient of an email from Talend, your contact personal data will be
>> on our systems. Please see our contacts privacy notice at Talend, Inc. <
>> https://www.talend.com/contacts-privacy-policy/>
>> 
>> 
>> 
> 
> -- 
> Henning Blohm
> 
> henning.bl...@zfabrik.de
> Linkedin <http://www.linkedin.com/pub/henning-blohm/0/7b5/628>
> ZFabrik <http://www.zfabrik.de>
> Blog <http://www.z2-environment.net/blog>
> Z2-Environment <http://www.z2-environment.eu>
> Z2 Wiki <http://redmine.z2-environment.net>
> 
> T: +49 6227 3984255
> F: +49 6227 3984254
> M: +49 1781891820
> 
> *ZFabrik Software GmbH & Co. KG*
> Lammstrasse 2, 69190 Walldorf
> Handelsregister: Amtsgericht Mannheim HRA 702598
> Persönlich haftende Gesellschafterin: ZFabrik Verwaltungs GmbH, Sitz
> Walldorf
> Geschäftsführer: Dr. H. Blohm u. Udo Offermann
> Handelsregister: Amtsgericht Mannheim HRB 723699

-- 
Daniel Kulp
dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog 
<http://dankulp.com/blog>
Talend Community Coder - http://talend.com <http://coders.talend.com/>

Reply via email to