Doug
You are quite right.
This was a mistake. I meant to say that the client may receive the ack
for request-2 before it receives response-1.
Paul
Doug Davis wrote:
>
> RM is silent on when an RMD should determine that a message is
> received and
> therefore should include it in the ackRanges. Given the spec in its
> current state
> I believe it to be most common for RMDs to be able to ack a request
> before the
> response is sent. So, when Paul said:
> There is no useful scenario. However, if the client sent a request-two
> before it had got response-1, it may get an ack for request-2 but no ack
> for request-1.
> I disagree. In all but this anon case I would expect most RMDs to
> have acked
> request-1 without waiting for response-1. And in this anon case its
> still an open issue.
>
> thanks,
> -Doug
>
>
>
> *Paul Fremantle <>*
>
> 03/16/2006 02:19 PM
>
>
> To
>
> cc
> Doug Davis/Raleigh/IBM@IBMUS, wsrx <>
> Subject
> Re: [ws-rx] An alternative approach to make anon reply-to and sync rm
> work
>
>
>
>
>
>
>
>
>
> Tom
>
> Answers inline.
>
> Tom Rutt wrote:
> > I assume we are talking about a wsdl resquest/response operation,
> > which is using ws-rm for both the request and response, the offer is
> > used in
> > the create sequence from the reqest sender to the request receiver,
> > and the sequence from request sender to request receiver is using the
> > anon acks to for the request.
> Yes. At least some of the operations involved are two-way. Of course
> some may have alternative MEPs.
> > Now it is not stated, but I assume the acks to for the offer sequence
> > must be an asych callback (i.e., not anonymous).
> Yes. The acksTo for the offered sequence is a real address (e.g. the
> same address as the server).
>
> > I interpret this case to state that the rmd has to respond to
> > pigybaccked http requests in the same order they are received.
> I'm not sure I understand this sentence.
> > Now
> > I assume that anon acks to means that the ack header can apear on any
> > http response which has a request carrying that sequence number in a
> > sequence or ackrequested header.
> Yes I agree.
> > Also, I cannot see a useful scenario for sending the ack before
> > sending the response for a given request message.
> There is no useful scenario. However, if the client sent a request-two
> before it had got response-1, it may get an ack for request-2 but no ack
> for request-1.
> > In face I see a case for having the ack send only after multiple
> > response are sent, on any one of the responses for that sequence.
> I think the server should ack whatever messages its RMD has received on
> any response to that sequence. But I don't see the ack behaviour should
> be different to an ordinary sequence.
> > I thought the original request sender could send an ack requested
> > without a message body or sequence header, thus there would be no
> > message number for the sequence. Thus the request sender can request
> > acks at any time.
> I agree the client can request acks any time.
> >
> > Tom Rutt
> >
>
> --
>
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://feeds.feedburner.com/bloglines/pzf
>
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://feeds.feedburner.com/bloglines/pzf
"Oxygenating the Web Service Platform", www.wso2.com
