Thanks a lot Aki for the explanation.
2014-08-18 13:48 GMT+02:00 Aki Yoshida <elak...@gmail.com>: > 2014-08-15 22:11 GMT+02:00 Ivan Brencsics <ivan.brencs...@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 <elak...@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.brencs...@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 > >> >
