RE: NEW ISSUE: Marking RefProps/RefParams using attributes

Oops typo in sample....here's the correct one. This completes my action
item from yesterday.

Thanks,
dims

Complete Sample:
<SOAP-ENV:Envelope>
     <SOAP-ENV:Header>
         <wsa:RefPs 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>

-----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 1:01 PM
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 Tuesday, 30 November 2004 18:03:02 UTC