W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

Re: Composibility problems with refps

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Mon, 22 Nov 2004 11:03:40 -0800
Message-ID: <41A2380C.9030102@oracle.com>
To: tom@coastin.com
CC: Jonathan Marsh <jmarsh@microsoft.com>, public-ws-addressing@w3.org

I agree that would indeed solve the problem -- either refp specific 
header(s) or the use of [to] property.

-Anish
--

Tom Rutt wrote:

> 
> As Glen has suggested before, encapsulating the ref parms and ref props 
> in a ws-addressing specific header element would allow arbitrary
> qnames for the ref props and ref parms, without confusion.
> 
> Tom Rutt
> 
> Anish Karmarkar wrote:
> 
>>
>> Yes.
>> Or in the context of SOAP, composability with any specification that 
>> uses SOAP header(s) as a mechanism to convey information.
>>
>> -Anish
>> -- 
>>
>> Jonathan Marsh wrote:
>>
>>> Specifically, you're worried about the case where the reference
>>> properties and reference parameters are in a namespace used by the
>>> reliability, security, etc. mechanisms, right?
>>>
>>>
>>>> -----Original Message-----
>>>> From: public-ws-addressing-request@w3.org [mailto:public-ws-
>>>> addressing-request@w3.org] On Behalf Of Anish Karmarkar
>>>> Sent: Monday, November 15, 2004 11:10 AM
>>>> To: public-ws-addressing@w3.org
>>>> Subject: Composibility problems with refps
>>>>
>>>>
>>>> All,
>>>>
>>>> During last week's concall discussion of issue i008 I took an action
>>>> to
>>>> explain the composibility problem with refps in an email. This email
>>>> fulfills that action.
>>>>
>>>> WS-Addressing [1] Submission includes [reference properties] and
>>>> [reference parameters] in the info models for EPR. These refps are
>>>> opaque to the consumer. In the SOAP binding of EPR, the refps are
>>>> bound
>>>> as individual SOAP header blocks. I.e., a consumer of a EPR using SOAP
>>>> is required to copy the refps as individual SOAP header blocks without
>>>> understanding what the blocks mean or do.
>>>>
>>>> Typically SOAP header blocks are part of a SOAP module and express
>>>> certain functionality. For example, WSS, WS-Reliability,
>>>> WS-ReliableMessaging, WS-C, WS-T WS-Context etc, specify header blocks
>>>> that have a particular meaning that is conveyed from the sender to the
>>>> receiver. Specifications in the realm of Web services are designed to
>>>> be
>>>> composible with other specs. For example, WS-Context can be composed
>>>> with WS-Reliability and WSS.
>>>>
>>>> A consuming application that dereferences an EPR that contains refps
>>>> may
>>>> have some policies in place wrt to reliability, security,
>>>> coordination,
>>>> transaction, privacy etc. Given that refps may contains any XML and
>>>> these refps are bound as SOAP header blocks, refps can potentially
>>>> interfere with composibility of WS-Addressing with other WS-* specs
>>>> that
>>>> the consumer may be using. The opacity of the refps prevents the
>>>> consumer from making any inferences about the refps in an EPR.
>>>>
>>>> This issue is slightly different from the security of EPRs -- which
>>>> *may* potentially be resolved by requiring the minter of the EPR to
>>>> sign
>>>> the EPR.
>>>>
>>>> HTH to clarify the issue.
>>>>
>>>> -Anish
>>>> -- 
>>>>
>>>>
>>>>
>>>> [1] http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/
>>>>
>>>
>>>
>>>
>>
> 
Received on Monday, 22 November 2004 19:04:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:59 GMT