- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Mon, 06 Feb 2006 12:07:13 -0800
- To: David Orchard <dorchard@bea.com>
- CC: Marc.Hadley@Sun.COM, paul.downey@bt.com, chrisfer@us.ibm.com, distobj@acm.org, dmh@tibco.com, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
David Orchard wrote: > >>-----Original Message----- >>From: Marc.Hadley@Sun.COM [mailto:Marc.Hadley@Sun.COM] > > <bigsnip/> > >>The main use case I've heard is to allow WS-RX acks to be sent on the >>HTTP response even when the actual SOAP response message is conveyed > > in > >>some other way. For this use case I don't think (1) is valid since it >>involves some WS-RX header processing. For this use case I think that >>something part way between 2 and 3 is being suggested, i.e. the mU > > check > >>is done and the WS-RX headers are processed but not necessarily all of >>the headers. From a WS-Addr perspective it would be good to define >>whether WS-A header are processed before the WS-RX ack is sent so a >>sender can know whether to expect WS-A MAPs in the WS-RX ack message > > or > >>not. > > > SOAP doesn't give an ordering and neither does ws-a or ws-rx. We've > never defined any kind of WS-ProcessingModel spec that defines an order. > The closest we have gotten is WSS which says order of security is the > order in which the tokens are in the header block. This is akin to the > XML processing model problem aka does XInclude happen before or after > schema validation before or after xslt. Which has sparked a Processing > Model WG at the W3C. > I agree with that. In addition, in the WS-RX case, it is not necessary that the receiver send a WS-RX ack to the message in the HTTP request. The WS-RX RMD (Reliable Messaging Destination) may use the HTTP response channel to ACK messages that have been received in the past. I.e., the RMD may not have truly even looked at the message in the HTTP request, but is leveraging the existence of a back-channel to push acks for previous messages. -Anish --
Received on Monday, 6 February 2006 20:10:21 UTC