[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] An alternative approach to make anon reply-to and sync rmwork
Paul Fremantle wrote: I am confused about this scenario. I would like to have a few things clarified. 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. Now it is not stated, but I assume the acks to for the offer sequence must be an asych callback (i.e., not anonymous). I interpret this case to state that the rmd has to respond to pigybaccked http requests in the same order they are received. 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. Also, I cannot see a useful scenario for sending the ack before sending the response for a given request message. 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 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. Is this the scenario we are talking about here? Tom Rutt > Doug > > The use of this model by the client is optional. > > So two possibilities. > > 1) The client needs to use the HTTP connection as the correlator. In > this case it can either keep replaying the request message, or *just > not use this model*. > 2) The client can use the relatesTo header as the correlator (and the > client RMS/RMD) doesn't span multiple endpoints. In this case it > works. If the client's RMS/RMD spans multiple endpoints, then the > choice is there to *just not use this model*. Its optional. > > Paul > > > > Doug Davis wrote: > >> >> Paul, >> >> I think there are some problems with this - I still think this >> violates WSA. There's a reason anon replyTo means, in essence, the >> http response flow of the request message. The connection becomes >> the correlator between the request and the response - meaning if >> several anon requests come in the only way the server knows which >> client gets which response is thru the http connection. In your >> scenario if there are two anon requests sent to the server using the >> same sequence and no responses sent, when the third connection is >> made (to carry the ackReq) how does the server know which client is >> initiating the request. It can not simply assume that just because >> they shared the same sequence that they also share WSA state and that >> any response can be sent to any client. The correlation is now lost. >> thanks, >> -Doug >> >> >> >> *Paul Fremantle <paul@wso2.com>* >> >> 03/09/2006 06:53 PM >> >> >> To >> wsrx <ws-rx@lists.oasis-open.org> >> cc >> >> Subject >> [ws-rx] An alternative approach to make anon reply-to and sync rm >> work >> >> >> >> >> >> >> >> >> >> The biggest issue with the two way reliable HTTP + anonURI case is the >> requirement to replay request messages to get responses. >> >> Why is this a problem? Because it means that the client has to store >> requests (if and only if the interaction is two-way) beyond getting >> an ack >> for that request. >> >> This means that the RMS has to "know" if this particular message >> interaction is one-way or two way. This means that for example, a dumb >> gateway can't do it without looking at WSDLs etc. >> >> Why do we need to do this: because WSA states: >> >> "For instance, the SOAP 1.2 >> HTTP binding puts the reply message in the HTTP response." >> >> So I agree we should not put an application reply to message A in an >> HTTP response to application message B. >> >> However, if we added the following text to our spec: >> >> "In the case where an offered sequence is used, the RMS may send an >> <wsrm:AckRequested> header together with an empty SOAP body. A valid >> response to this message MAY either contain an empty SOAP body, or MAY >> contain a message for the *offered* sequence". >> >> The result of this would be that the response message on the HTTP reply >> would be a valid reply to the request message and therefore would not >> break the >> WS-Addressing text above. Effectively WSRM would be defining what >> the SOAP request/reply would be, and therefore "making it right" >> with respect to the HTTP binding. >> >> So, when things are going well the HTTP reply to any given request >> message would be the >> correct response message. But in the case that this message got lost or >> delayed, the RMS would have a choice. If it still had the message, >> and it >> "knew" that the MEP was two-way, it could choose to resend the >> original request OR it could send an empty body with an ackRequested >> header. >> >> This also gives the offered sequence a message onto which to >> piggyback Close and TerminateSequence requests, solving another problem. >> >> More importantly it removes the need for >> the RMS to "know" the MEP, because by the repeated application of >> empty-body ackRequests, >> the RMS can get the offered sequence into a decent state. >> >> The only compulsory implementation change I see is that the RMD would >> have to be coded to know what this empty body + ackrequest means. >> >> From the RMS I see this as optional. It is completely up to the RMS >> whether it initiates a CS with Offer+AnonURI. So if an implementation >> doesn't support this, >> it will never initiate such a channel. And if the RMS does initiate such >> a channel, it will "know" it is in this mode, that it needs to send >> occasional empty ackrequests until it can close down the offered >> sequence. >> >> In addition we would have to remove the words that say Offer is >> simply an optimization, >> because this usage makes a specific correlation between a sequence >> and offered sequence. >> >> Paul >> >> -- >> >> Paul Fremantle >> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair >> >> http://feeds.feedburner.com/bloglines/pzf >> paul@wso2.com >> >> "Oxygenating the Web Service Platform", www.wso2.com >> >> > -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]