Re: Issue #1 proposed resolution

Say I have a room full of 100 equipment racks, each one having 20 
shelves containing 10 blade computer cards.  This room has 20000 blade 
computer cards, all exactly the same, with the same policy attached, but 
having different serial numbers in their rom.

A common use case (ws-rm, systems management etc) is having one web 
service "type" with a single http address, with two operations 
(getSerialNumber(), getCPUCoreTemp()).

The sysadmin wishes to employs the use of refPs (in this case they could 
be refParms since the messages sent for each of them is the same) to 
distinguish which blade is of concern.  He defines three refParms 
(rackNumber, rowNumber, CollumNumber).

These three refParms are not universal identifiers, since on any given 
day, one of the blades can be pulled out for repair, and replace with 
another having a different serial number.  The serial number of the 
blade is an identifier, but still, if I change the
value of any one of the three refParms I would get a different answer 
for the getSerialNumber() querry, and the getCPUCoreTemp() operation 
will give and answer specific to that blade. 

In summary, this sysAdmin person wants to use the refParms as "access 
handles" to direct the query to a particular "bag of state".

Tom Rutt

Bob Freund wrote:

>Is it not then simply that ws-a provides parameters that modify the behavior
>of a resource identified by a uri?
>-bob
>
>-----Original Message-----
>From: public-ws-addressing-request@w3.org
>[mailto:public-ws-addressing-request@w3.org] On Behalf Of Francisco Curbera
>Sent: Monday, January 17, 2005 12:59 PM
>To: Hugo Haas
>Cc: Mark Baker; David Orchard; public-ws-addressing@w3.org;
>public-ws-addressing-request@w3.org
>Subject: Re: Issue #1 proposed resolution
>
>Hi Hugo,
>
>I am glad you see this as a step towards successfully closing this issue;
>reading your last main on this topic I realized this proposal was pretty
>close to your view also. Two comments:
>
>1. You are right that a proposal compatible with this thinking would
>certainly require removing from the text everything that would seem to
>imply that EPRs and/or ref. props. are identifiers (I made a proposal for
>this some time ago).
>
>2. I think the ref. properties vs. ref. parameters discussion is not
>central to issue 1 and could be cleanly separated. If we assume that the
>only identifier in an EPR is the Address field, and characterize both
>properties and parameters as "state" associated to the interaction, then
>the difference between the two boils down to whether a change in one of
>them should be interpreted by the consumer of the EPR as implying a
>possible change in the policies that affect the interaction. Note that a
>change of policies is in no way associated to a change in "identity" or
>anything like that, as policies can change very dynamically during the
>course of the interaction (depending of the date or time of the day) w/o
>any implication that the "resources" or parties involved have changed.
>
>If people are concerned about that issue (props vs. params) I suggest we
>separate it into a different issues.
>
>Paco
>
>
>
>|---------+----------------------------------->
>|         |           Hugo Haas <hugo@w3.org> |
>|         |           Sent by:                |
>|         |           public-ws-addressing-req|
>|         |           uest@w3.org             |
>|         |                                   |
>|         |                                   |
>|         |           01/17/2005 11:14 AM     |
>|---------+----------------------------------->
> 
>  
>
>>---------------------------------------------------------------------------
>>    
>>
>----------------------------------------------------------|
>  |
>|
>  |       To:       David Orchard <dorchard@bea.com>, Mark Baker
><distobj@acm.org>                                                      |
>  |       cc:       public-ws-addressing@w3.org
>|
>  |       Subject:  Re: Issue #1 proposed resolution
>|
> 
>  
>
>>---------------------------------------------------------------------------
>>    
>>
>----------------------------------------------------------|
>
>
>
>
>Hi Dave and Mark.
>
>This is indeed very encouraging.
>
>* David Orchard <dorchard@bea.com> [2005-01-16 14:16-0800]
>[..]
>  
>
>>1. Consider a stateful interaction model where ref. properties are
>>
>>interaction data and the full state of the interaction (in the form of
>>
>>actual business data: a shopping cart, for example); this usage follows
>>
>>the canonical stateless implementation that http cookies allow. In fact,
>>
>>the semantics of ref props in this usage case are not very different
>>
>>from cookie semantics except for the fact that WS-Addressing does not
>>
>>define an EPR lifecycle. The EPR in this situation acts as a mere
>>
>>packaging mechanism for transmitting to the service requester the URI
>>
>>address + state that is characteristic of a particular interaction. In
>>
>>particular, there is only one identifier involved here, the URI
>>
>>providing the network address. The state represented by the ref. props.
>>
>>has no identification function in this case.  The EPR is nothing but an
>>
>>XML envelope for the two.  To reiterate, the EPR is not an identifier
>>
>>but a container used to specify echoed state information.
>>    
>>
>
>Aren't you describing a use for reference parameters here, and not
>reference properties, then?
>
>  
>
>>2. The use of EPRs and ref props as a server side "identifier"
>>
>>(as opposed to client side identifiers) is another possible and probable
>>
>>use case. Here, the combination of URI and ref. props. is used by the
>>
>>infrastructure to retrieve stateful artifacts associated with the
>>
>>interactions. Typically, in these cases the internal implementation of
>>
>>the server side provides for mechanisms to compare two EPRs for
>>
>>"sameness" and can operate with proper id semantics internally.
>>
>>Reference properties carry server side specific data (not business data
>>
>>as before).
>>    
>>
>[..]
>
>* David Orchard <dorchard@bea.com> [2005-01-16 22:17-0800]
>  
>
>>Yeah, we should remove that wording as it's true yet implies the client
>>will make use of the EPRs for identification purposes.  I have no
>>problems with RefPs being used for identification, but it's by no means
>>the only case.
>>    
>>
>
>So, if only the server-side is concerned with what RefP's are used
>for, and that the wording about the identifying role of [reference
>properties] should be removed, then doesn't that it means that
>[reference properties] and [reference parameters] are equally opaque
>bags of XML data from the requester's perspective?
>
>* Mark Baker <distobj@acm.org> [2005-01-16 23:48-0500]
>  
>
>>On Sun, Jan 16, 2005 at 06:51:59PM -0800, David Orchard wrote:
>>    
>>
>>>EPRs aren't defined to be identifiers.  An EPR may contain identifiers,
>>>but it may contain state.  Therefore, there's no conflict with EPRs (as
>>>a class) as they stand with advice to use URIs for identifiers.
>>>      
>>>
>>This is very encouraging, and if that were the case I agree that there
>>would be no issue.  But for this;
>>
>>"A reference may contain a number of individual properties that are
>>required to identify the entity or resource being conveyed."
>> --
>>    
>>
>http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/#_Toc77464317
>  
>
>>Your RefProp example in your initial post didn't use them as identifiers
>>though; it used them as RefParams in fact.  So I'll go out on a limb and
>>ask; would you be content with removing RefProps?  Alternately, would
>>you be content with saying that RefProps shouldn't be used for
>>identification?  (though I guess you'd then have to distinguish them
>>from RefParams, but perhaps you have some ideas about that).
>>    
>>
>
>I think that your alternative only holds true if [reference
>properties] are not considered by the client side for metadata
>comparison purposes. If it were not the case, then [reference
>properties] would be identifying this metadata about the endpoint.
>
>If we agree on this, then I think that we are saying [reference
>properties]' use is essentially similar to [reference parameters]',
>and that they are basically the same. Are we?
>
>Cheers,
>
>Hugo
>
>--
>Hugo Haas - W3C
> mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
>
>
>#### signature.asc has been removed from this note on January 17, 2005 by
>Francisco Curbera
>
>
>  
>

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Monday, 17 January 2005 20:40:14 UTC