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

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] ==  
identifier:

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

Marc.

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