Hi Andrei, thanks for checking. We found this workaround only by debugging and some guessing. If there is something that is more to the rules, that would be better I assume.
Henning Ursprüngliche Nachricht Von: ashaki...@talend.com.INVALID Gesendet: 9. Juli 2019 10:48 vorm. An: users@cxf.apache.org Antworten: users@cxf.apache.org Betreff: RE: Robust Asynchronous Message Exchange using WS-Addressing Hi Henning, There are some comments inline: -----Original Message----- From: Henning Blohm <henning.bl...@zfabrik.de> Sent: Freitag, 5. Juli 2019 12:33 To: users@cxf.apache.org Subject: Re: Robust Asynchronous Message Exchange using WS-Addressing Warning! External email. Exercise caution when opening attachments or clicking any links. >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. Well, from my perspective 202 here just mean that message achieved the receiver and it can be processed. All other logic inclusive message validation will be fulfilled asynchronously. >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. It is debatable is such behavior really in sense of asynchronous processing. But if you cannot change it, there is no choice. >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. This is a valid workaround to model communication using two one-way calls. Perhaps it will be enough just to remove ReplyTo header instead deactivating whole WS-Addressing - have to verify that. >Thanks, >Henning Regards, Andrei. 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 > https://urldefense.proofpoint.com/v2/url?u=http-3A__ashakirin-2Dcxf-2D > async.blogspot.com_&d=DwIFaQ&c=2w5q_42kFG40MI2alLPgJw&r=bWOqkHjIZE0sZt > dpFMIhm-lcbhtB3cv08OlIr0lkKR4&m=fTXPL5bP7fGYZEPkX5JYlLPaG5fN8YboN9EQUo > WbWzA&s=nJhZd92wNxKzRp0_m3jm_Pi3zmdVg_d7oh0x0HSSJR0&e= > > 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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_pub_henning-2Dblohm_0_7b5_628&d=DwIFaQ&c=2w5q_42kFG40MI2alLPgJw&r=bWOqkHjIZE0sZtdpFMIhm-lcbhtB3cv08OlIr0lkKR4&m=fTXPL5bP7fGYZEPkX5JYlLPaG5fN8YboN9EQUoWbWzA&s=fGDjech5bKse_uBIQ__a22mZMb7bpvo0N8m1YEetC2w&e= > ZFabrik <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.zfabrik.de&d=DwIFaQ&c=2w5q_42kFG40MI2alLPgJw&r=bWOqkHjIZE0sZtdpFMIhm-lcbhtB3cv08OlIr0lkKR4&m=fTXPL5bP7fGYZEPkX5JYlLPaG5fN8YboN9EQUoWbWzA&s=VGR9tKs8BBajHSpchW0BKRgWc4blhktlvkAkbrCtsgE&e= > Blog <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.z2-2Denvironment.net_blog&d=DwIFaQ&c=2w5q_42kFG40MI2alLPgJw&r=bWOqkHjIZE0sZtdpFMIhm-lcbhtB3cv08OlIr0lkKR4&m=fTXPL5bP7fGYZEPkX5JYlLPaG5fN8YboN9EQUoWbWzA&s=lE2VwelERk9M87kILCAGEvsT7lI26qTTak5WjfWbde8&e= > Z2-Environment <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.z2-2Denvironment.eu&d=DwIFaQ&c=2w5q_42kFG40MI2alLPgJw&r=bWOqkHjIZE0sZtdpFMIhm-lcbhtB3cv08OlIr0lkKR4&m=fTXPL5bP7fGYZEPkX5JYlLPaG5fN8YboN9EQUoWbWzA&s=0XxDjkFimGE0whWe2nzhqfLqReKxo5p__We8JQ8dvcI&e= > Z2 Wiki <https://urldefense.proofpoint.com/v2/url?u=http-3A__redmine.z2-2Denvironment.net&d=DwIFaQ&c=2w5q_42kFG40MI2alLPgJw&r=bWOqkHjIZE0sZtdpFMIhm-lcbhtB3cv08OlIr0lkKR4&m=fTXPL5bP7fGYZEPkX5JYlLPaG5fN8YboN9EQUoWbWzA&s=gEfVAWhwSLvNiDyOlyjxEa1SZXzemBdNM-EOCDB7opc&e= > 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