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

Re: Composibility problems with refps

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Mon, 22 Nov 2004 16:10:17 -0500
To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Cc: Jonathan Marsh <jmarsh@microsoft.com>, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org, tom@coastin.com
Message-ID: <OFBCC784D4.A6868BC1-ON85256F54.0071E4AF-85256F54.00744C53@us.ibm.com>


But then this means that the refps that under the current design become 
SOAP headers, and subject to 
the SOAP processing model, would no longer be subject to the SOAP 
processing model. I think that this
would be a collossal mistake.

Frankly, I think that the idea of reference properties/params interfering 
with other WS-* use of headers
is a red herring. Of course, it is always possible to do something that 
would break any protocol. At most, I could
see adding a note in the spec that recommended caution when including any 
protocol elements
as reference property/parameters as their subsequent inclusion as SOAP 
header blocks in messages 
addressed to the endpoint *might*, I repeat, *might* conflict with 
constraints as to cardinality of such
header blocks in a message, etc.

I would strongly discourage any thoughts of a wrapper element for 
reference property/parameters.


Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295

Anish Karmarkar <Anish.Karmarkar@oracle.com> 
Sent by: public-ws-addressing-request@w3.org
11/22/2004 02:03 PM

Jonathan Marsh <jmarsh@microsoft.com>, public-ws-addressing@w3.org
Re: Composibility problems with refps

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


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 
>>>> is required to copy the refps as individual SOAP header blocks 
>>>> 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 
>>>> that have a particular meaning that is conveyed from the sender to 
>>>> 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 21:10:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:28:21 UTC