Team,
Here's the re-worked proposal...dropping the <wsa:RefPs> element as per
Jonathan [1]
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, discovery). 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.
Problems: There are the downsides (schema-validation[2], signing[3]) to
this proposal but those appear to be manageable. This keeps the
generated headers as true SOAP headers, participating in the SOAP
processing model, including targeting the headers via @actor/@role and
marking them individually as @mustUnderstand.
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"
Complete Sample:
<SOAP-ENV:Envelope>
<SOAP-ENV:Header>
<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>
[1]
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0128.ht
ml
[2]
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0602.ht
ml
[3]
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0592.ht
ml
Davanum Srinivas
Computer Associates
Senior Architect, Web Services Group
Tel: +1 508 628 8251
davanum.srinivas@ca.comhttp://ws.apache.org/~dims/