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: Steve Graham <sggraham@us.ibm.com>
Date: Mon, 29 Nov 2004 08:25:03 -0500
To: Christopher B Ferris <chrisfer@us.ibm.com>
Cc: Mark Baker <distobj@acm.org>, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
Message-ID: <OFDE8A5B93.217F1287-ON85256F5B.0048850E-85256F5B.0049B468@us.ibm.com>
In WS-RF the concept formerly known as "implied resource pattern" has been 
slightly refactored and renamed to "WS-Resource Access Pattern".  During 
this refactoring, a small task force of the WSRF TC debated issues of 
references, identifiers etc. when considering our approach to representing 
"resources" in a Web services context.

The result, available at [1] states roughly:
EPRs are references, not identifiers of resources.  Each EPR MUST convey 
an identifier of the resource (either within the URI value of the 
wsa:Address component, or as value of the wsa:ReferenceProperty 


Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>

Christopher B Ferris/Waltham/IBM@IBMUS 
Sent by: public-ws-addressing-request@w3.org
11/24/2004 11:01 AM

Mark Baker <distobj@acm.org>
Re: Sample SOAP message on the wire with Reference Properties and 
Parameters (without a wrapper!)


Please see Paco's recent missive[1]... the EPR is NOT an identifier, it is 

an addressable reference.

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 
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.

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. 



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 
> > of a received message, they are
> > simply SOAP header blocks that are processed in the usual manner using 

> > 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
Received on Monday, 29 November 2004 13:44:50 UTC

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