Re: i008 - Marking RefProps/RefParams using attributes [Take #2]

Dims,

How does this proposal deal with the problem that for certain SOAP 
header block definitions having multiple instances of the same header 
may be undefined/illegal/counterproductive?

Specifically, a consumer's local policy may require it to include a 
certain header block of type A (with some well defined semantics). 
Another instance of A may also be included as a refp. The opacity of the 
refps prevent the consumer from making any decision regarding header 
block A. Furthermore, it is possible that different part of the 
system/stack may deal with the policy to include header block of type A 
and WS-Addressing. For example, a JAX-RPC handler chain.

Thx.

-Anish
--

Srinivas, Davanum M wrote:
> *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.html_ 
> 
> [2] 
> _http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0602.html_ 
> 
> [3] 
> _http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0592.html_ 
> 
> 
> 
> *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 Monday, 20 December 2004 19:07:21 UTC