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

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

sgg
[1] 
http://www.oasis-open.org/committees/download.php/9547/wsrf-WS-Resource-1.2-draft-01.doc

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

To
Mark Baker <distobj@acm.org>
cc
public-ws-addressing@w3.org
Subject
Re: Sample SOAP message on the wire with Reference Properties and 
Parameters (without a wrapper!)







Mark,

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. 

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