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

Re: Sample SOAP message on the wire with Reference Properties and Parameters (without a wrapper!)

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Wed, 24 Nov 2004 11:38:52 -0500
To: Christopher B Ferris <chrisfer@us.ibm.com>
Cc: Mark Baker <distobj@acm.org>, public-ws-addressing@w3.org
Message-id: <533E3EE8-3E37-11D9-8A29-000A95BC8D92@Sun.COM>

On Nov 24, 2004, at 11:01 AM, Christopher B Ferris wrote:
> Please see Paco's recent missive[1]... the EPR is NOT an identifier,  
> it is
> an addressable reference.
The distinction isn't that clear to me.

> The ref props/params *can* be used to provide additional information  
> that
> the service provider will use
> as it sees fit. One such purpose that has been used by WS-RF has been  
> to
> pass keys/identifiers to

There's that identifier word again.

> resources (implied resource pattern) as ref props, but that is not the
> only use of ref props/params.
> In the context of the implied resource pattern, the ref props  
> serialized
> as SOAP headers can be
> considered the equivalent of cookies used to associate a stateful  
> session,
> like a shopping cart service
> might do.
That may be your view but it is not clearly reflected in the  
specification status quo. In particular, ref params seems closer to  
cookies and the spec states that [address] + [reference properties] ==  

"[address] : URI (mandatory) - An address URI that identifies the  
endpoint. This may be a network  address or a logical address.
[reference properties] : xs:any (0..unbounded) - A reference may  
contain a number of individual properties that are required to identify  
the entity or resource being conveyed."

Note the use of 'identify' in each of the above.

> As an example that is often used, a service might have three levels of
> service; silver, gold and platinum.
> Each level of service might have a different policy that applies.  
> Hence, I
> would use the ref props to
> include a <myservice:MembershipLevel> element with the possible values
> Silver, Gold, or Platinum.
> Is that identity? Nope.
It could be viewed in two ways:

(i) You have the Gold Service, the Silver Service and the Platinum  
Service. The [address] + [reference properties] identifies the service  
you are using.
(ii) You have one service that is parameterized by service level. The  
[address] identifies the service you are using.

Using the status quo of the spec you'd achieve (i) by specifying a  
precious metal in a reference property and (ii) by specifying it in a  
reference parameter.


> [1]
> http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/ 
> 0355.html
> Cheers,
> 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
> public-ws-addressing-request@w3.org wrote on 11/24/2004 09:48:35 AM:
>> On Tue, Nov 23, 2004 at 11:28:50AM -0500, Christopher B Ferris wrote:
>>> Dims,
>>> Why? There is no utility in making such a distinction from the
> perspective
>>> of a received message, they are
>>> simply SOAP header blocks that are processed in the usual manner  
>>> using
> the
>>> SOAP processing model.
>> Has the WG decided what the identifier is yet?  Because if it has, I
>> maintain that it's maximally self-descriptive for the identifier to be
>> able to be located within the message which provides increased
>> visibility for (generally) very little cost.  Some might recall the
>> issue with HTTP 1.0 allowing partial URIs in the request line, and the
>> ensuing problems for supporting virtual hosting.  This necessitated  
>> the
>> introduction of the Host header in HTTP 1.1 which restored the lost
>> identifying information.
>> If the URI + RefProps is the identifier, then the RefProps need to be
>> declared as such.  If it's just the URI, then all is good; wsa:To
>> suffices.  If it's the whole EPR, then you need a way to distinguish
>> RefProps & RefParams from each other, as well as other SOAP headers.
>> Self-description means never having to say you're sorry.
>> Mark.
>> -- 
>> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Marc Hadley <marc.hadley at sun.com>
Web Technologies and Standards, Sun Microsystems.
Received on Wednesday, 24 November 2004 16:38:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:07 UTC