- From: Srinivas, Davanum M <Davanum.Srinivas@ca.com>
- Date: Thu, 2 Dec 2004 17:06:33 -0500
- To: "Jonathan Marsh" <jmarsh@microsoft.com>, <public-ws-addressing@w3.org>
Jonathan, That was a suggestion from Glen. See http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0602.ht ml Thanks, dims -----Original Message----- From: Jonathan Marsh [mailto:jmarsh@microsoft.com] Sent: Thursday, December 02, 2004 3:35 PM To: Srinivas, Davanum M; public-ws-addressing@w3.org Subject: RE: NEW ISSUE: Marking RefProps/RefParams using attributes What is the purpose of the <wsa:RefPs soap:mustUnderstand="true"/> header? Is it really your intention that any SOAP message with refPs must insert the header with mustUnderstand="true"? > -----Original Message----- > From: public-ws-addressing-request@w3.org [mailto:public-ws- > addressing-request@w3.org] On Behalf Of Srinivas, Davanum M > Sent: Tuesday, November 30, 2004 10:01 AM > To: public-ws-addressing@w3.org > Subject: NEW ISSUE: Marking RefProps/RefParams using attributes > > > Title: Marking RefProps/RefParams using attributes > > Description: As mentioned in several threads, currently there is no > way to distinguish between regular soap headers and RefProps and > RefParams just by looking at the soap message on the wire. One could > use xml attributes to add extra information on soap headers which have > been added ONLY because they were part of the original EPR. This is > basically to be in tune with the "Self-description" mantra. > > Justification: Different types of intermediaries can use this > information for various purposes (say caching, monitoring, > logging/auditing). For example a transparent (does not generate EPR's > and is not an endpoint for soap messages) intermediary will be able to > track all Refp's flowing in the system without a user having to input > all QName's being used in the system or use some other out of band > mechanism. Another benefit is that one can even use the same QName in > both RefParams and RefProps IF we are able to mark them in some > fashion and we will be able to apply different policies based on > whether a QName is being used as a RefParam or present in RefProps. We > also need a way to ensure that attribute is understood by all nodes > (and more importantly fail when the soap nodes does not know how to > handle RefParams/RefProps attribute stuff) > > Target: Core > > Proposal: > - SOAP Headers that are added because they were part of an EPR's > ReferenceProperties are marked by adding the following attribute: > wsa:type="property" > - SOAP Headers that are added because they were part of an EPR's > ReferenceParameters are marked by adding the following attribute: > wsa:type="parameter" > - If there's at least one soap header marked with the wsa:type > attribute, then add a new header to ensure that the attribute is not > ignored silently: > <wsa:RefPs soap:mustUnderstand="true"/> > > Complete Sample: > <SOAP-ENV:Envelope> > <SOAP-ENV:Header> > <wsa:ReferenceParameters soap:mustUnderstand="true"/> > > <wsa:ReferenceProperties soap:mustUnderstand="true"/> > > <wsa:MessageID>msgid:1234567902282223</wsa:MessageID> > <wsa:To>http://www.example.com/services/someService</wsa:To> > <wsa:Action>http://www.example.com/someAction</wsa:Action> > > <wsa:From>http://www.example.com/clients/someClient</wsa:From> > > ... > <tns:resourceID > wsa:type="property">DataChunk42</tns:resourceID> > <tns:expires wsa:type="parameter">32000</tns:expires> > </SOAP-ENV:Header> > <SOAP-ENV:Body> > ... > </SOAP-ENV:Body> > </SOAP-ENV:Envelope> > > Problems: > [1] Possible Schema validation problem mentioned by Glen: > (http://lists.w3.org/Archives/Public/public-ws- > addressing/2004Nov/0602.h > tml) > [2] Possible Signing RefProps/RefParams problem mentioned by Rich: > (http://lists.w3.org/Archives/Public/public-ws- > addressing/2004Nov/0592.h > tml) > > Discussion Threads: > [1] > http://lists.w3.org/Archives/Public/public-ws- > addressing/2004Nov/thread. > html#478 > [2] > http://lists.w3.org/Archives/Public/public-ws- > addressing/2004Nov/thread. > html#544 > > > Davanum Srinivas > Computer Associates > Senior Architect, Web Services Group > Tel: +1 508 628 8251 > davanum.srinivas@ca.com > http://ws.apache.org/~dims/ > >
Received on Thursday, 2 December 2004 22:07:07 UTC