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

Anish,

Yes, this proposal does not deal with the "that for certain SOAP header
block definitions having multiple instances of the same header may be
undefined/illegal/counterproductive" problem. 

Yes, you need out of band coordination between the folks writing the
client, writing the service and those writing the handlers for the spec
submission (and latest drafts!!!) to work. This proposal does not
alleviate that problem. 

Thanks,
dims

-----Original Message-----
From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] 
Sent: Monday, December 20, 2004 2:06 PM
To: Srinivas, Davanum M
Cc: public-ws-addressing@w3.org
Subject: 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.h
tml_ 
> 
> [2] 
>
_http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0602.h
tml_ 
> 
> [3] 
>
_http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0592.h
tml_ 
> 
> 
> 
> *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, 21 December 2004 21:09:07 UTC