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 Fri, 15 Aug 2014 20:11:48 GMT
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 <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