When an async request is acknowledged?

[Iván Brencsics <iv...@gmail.com>]

Hi,

I had a general question about web services. Sorry, it is not related 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 critical
failure happens, will send back an async response. The message might get
lost.

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 message
might get lost.

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.

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

Re: When an async request is acknowledged?

[Ivan Brencsics <iv...@gmail.com>]

Thanks a lot Aki for the explanation.


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

> 2014-08-15 22:11 GMT+02:00 Ivan Brencsics <iv...@gmail.com>:
> > Thanks for the explanation. From your answer I assume there is no single
> > 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 was
> > 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 interconnects
> > 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 <el...@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án Brencsics <iv...@gmail.com>:
> >> > Hi,
> >> >
> >> > I had a general question about web services. Sorry, it is not related
> 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 critical
> >> > 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 message
> >> > 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
> >>
>

Re: When an async request is acknowledged?

[Aki Yoshida <el...@gmail.com>]

2014-08-15 22:11 GMT+02:00 Ivan Brencsics <iv...@gmail.com>:
> Thanks for the explanation. From your answer I assume there is no single
> 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 was
> 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 interconnects
> 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 <el...@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án Brencsics <iv...@gmail.com>:
>> > Hi,
>> >
>> > I had a general question about web services. Sorry, it is not related 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 critical
>> > 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 message
>> > 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
>>

Re: When an async request is acknowledged?

[Ivan Brencsics <iv...@gmail.com>]

Thanks for the explanation. From your answer I assume there is no single
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 was
simply read out from the wire, and not processed at all? So do you
implement some kind of retry mechanism or not?

2) If you need to design a communication specification that interconnects
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?





2014-08-14 16:55 GMT+02:00 Aki Yoshida <el...@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án Brencsics <iv...@gmail.com>:
> > Hi,
> >
> > I had a general question about web services. Sorry, it is not related 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 critical
> > 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 message
> > 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
>

Re: When an async request is acknowledged?

[Aki Yoshida <el...@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án Brencsics <iv...@gmail.com>:
> Hi,
>
> I had a general question about web services. Sorry, it is not related 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 critical
> 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 message
> 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