cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Brencsics <ivan.brencs...@gmail.com>
Subject Re: When an async request is acknowledged?
Date Tue, 19 Aug 2014 09:26:18 GMT
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 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 <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án Brencsics <ivan.brencsics@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
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message