[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]