Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: pass (athena.apache.org: domain of ivan.brencsics@gmail.com
 designates 209.85.219.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAF8t5Xucm-GguvMOAyyYyJ-bBm1rpKGVLcSzxziueWuySnKrYw@mail.gmail.com>
References: 
 <CA+qVn1Si6GGnUcW8LWMdbaAp9oEY1ssWd8q23V1cb0LNkOQL6w@mail.gmail.com>
	<CAF8t5Xu1ibAuODAHPqbZ=tuxYSS0JVL=CVHSCx7FJtqpnRkSng@mail.gmail.com>
	<CA+qVn1QY-wUs1MgU0UhP+Nt5sUAKOnF+oDjAmP3bZaaQ92zM=g@mail.gmail.com>
	<CAF8t5Xucm-GguvMOAyyYyJ-bBm1rpKGVLcSzxziueWuySnKrYw@mail.gmail.com>
Date: Tue, 19 Aug 2014 11:26:18 +0200
Message-ID: 
 <CA+qVn1Q48+Pe-1LMNqpfPbfMNE85EPAMOk-YDCRAvtCKnCu5mg@mail.gmail.com>
Subject: Re: When an async request is acknowledged?
From: Ivan Brencsics <ivan.brencsics@gmail.com>
To: users@cxf.apache.org
Content-Type: multipart/alternative; boundary=001a11c200ca72c0530500f81431

--001a11c200ca72c0530500f81431
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks a lot Aki for the explanation.


2014-08-18 13:48 GMT+02:00 Aki Yoshida <elakito@gmail.com>:

> 2014-08-15 22:11 GMT+02:00 Ivan Brencsics <ivan.brencsics@gmail.com>:
> > Thanks for the explanation. From your answer I assume there is no singl=
e
> > truth here. Let me just have two questions.
> >
> > 1) If you need to integrate with an external system that publishes some
> > kind of oneway services, how do you interprete the HTTP 202 acknowledge=
?
> Do
> > you assume your message was persisted (so cannot be lost), or that it w=
as
> > simply read out from the wire, and not processed at all? So do you
> > implement some kind of retry mechanism or not?
>
> The only thing that we can assume is that some component accepted the
> message. But we cannot assume if the message will be processed or if
> the request was sent to the right service (e.g.., the request might
> have been sent to the wrong service and that service responded with an
> http 202).
>
> So you will need to add an "real" acceptance acknowledgement mechanism
> either in the protocol layer (e.g., using WS-RM, etc) or in your
> application layer (e.g., your synchronously called service putting the
> request in a queue and returning an http 202 and then executing the
> actual service). For the former, as I described in my previous reply,
> the acknowledgement is done using the RM-Ack message and there is no
> ack semantics associated with the http 202 response. For the latter,
> the http 202 response can be used as an acknowledgement message.
> Regarding the retry mechanism, you will have one in the corresponding
> layer if you are providing At-Least-Once or Exactly-Once QoS.
>
> >
> > 2) If you need to design a communication specification that interconnec=
ts
> > systems, and you use oneway services, do you specify what a HTTP 202
> > acknowledge should mean? So do you make it mandatory for the parties
> > implementing your protocol to interpret the acknowledge the same way?
> >
>
> Without having the same interpretation, or in other words, the same
> protocol, the client cannot assume what is happening for the request
> message at the server.  I think my answer to question 1 is also
> answering this question.
>
> regards, aki
>
> >
> >
> >
> >
> > 2014-08-14 16:55 GMT+02:00 Aki Yoshida <elakito@gmail.com>:
> >
> >> Maybe this is a difficult question to answer.
> >>
> >> An HTTP 202 response will be returned for a request that has been
> >> determined as a oneway service call. If something goes wrong before
> >> that happens, there will be some HTTP 4xx/5xx error. The semantics of
> >> HTTP 202 may differ depending on what your code (not the service code
> >> itself but the extension/feature used with the service) is doing up to
> >> that point.
> >>
> >>
> >> 2014-08-14 13:12 GMT+02:00 Iv=C3=A1n Brencsics <ivan.brencsics@gmail.c=
om>:
> >> > Hi,
> >> >
> >> > I had a general question about web services. Sorry, it is not relate=
d
> to
> >> > CXF, but this is a so good community, maybe someone can help me:).
> >> >
> >> > In case of an async web service call the receiver acknowledges the
> >> request
> >> > with an HTTP 202 usually. What is the semantics of this acknowledge:
> >> >
> >> > 1) We received the message, will process it later, and if no critica=
l
> >> > failure happens, will send back an async response. The message might
> get
> >> > lost.
> >>
> >> this is the case assumed for plain web services.
> >>
> >> >
> >> > 2) We received the message, validated it, so we can process it later=
.
> >> Will
> >> > send back an async response later if no critical failures. The messa=
ge
> >> > might get lost.
> >>
> >> if you add your validation interceptor before the above oneway switch
> >> is taking place, you can get this behavior.
> >>
> >> >
> >> > 3) We received, validated and persisted the request. So it wont be
> lost.
> >> We
> >> > will process it, and send back an async response later for sure.
> >> >
> >>
> >> similarly, if you have your custom persistence before the oneway
> >> switch, you can also get this behavior. Another way of persisting the
> >> request is using WS-RM. But with WS-RM, the HTTP code itself has not
> >> much meaning as an Ack, as WS-RM uses its own SOAP based Ack messages
> >> that are either returned in the HTTP response or sent back separately
> >> using a separate connection to the client.
> >>
> >> > 4) ...
> >> >
> >> > Does HTTP 202 has such a semantics, or does it leave the meaning
> open? Or
> >> > if a system uses async calls, should it decide on its own, what does
> >> > "acknowledge" mean?
> >> >
> >> > Regards,
> >> > Ivan
> >>
>

--001a11c200ca72c0530500f81431--