Re: Issue #1 proposed resolution

One benefit of the implied resouce pattern in this example could be that 
eprs for sysadmins would have the three refParms,
rack, row, and column.      The same endpoint could also provide an 
alternative reference for the repair service  bureau, with a single 
refParm (serialNumber).    

However this would entail 40000 EPRs for that machine room. 

With such large numbers, this flexibility is probably not worth the high 
price of so many EPRs.  It is probably better to give the repair service 
bureau their own operation with the single input parameter.

Tom Rutt

Tom Rutt wrote:

> I gave this example for illustrative purposes. 
> I agree that in this case, putting the three "access handle" 
> parameters in the request message body would be a better
> solution than using 20000 EPRs.
> In fact, I still do not understand the great benefit of the implied 
> resource pattern for WSRF.
>
> Tom Rutt
>
> Savas Parastatidis wrote:
>
>> <snip />
>>
>>  
>>
>>> 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.
>>>
>>>   
>>
>>
>> Would you be prepared to generate all possible permutations of your
>> parameters and generate an EPR for each one of them? Remember, the
>> consumer of the EPR is not allowed to reason about the contents of the
>> ReferenceProperties and, hence, they can't just change the values of
>> your parameters to convey their intentions on which of the resources
>> they want to access.
>>
>> What if we had 1,000 different changing parameters associated with a
>> manageable backend resource (your collection of blades). Would you have
>> included all of them in WS-Refs and/or WS-Params and generate all
>> possible EPRs? How would you do the association between an EPR and a
>> manageable resource? You'll need to convey those semantics separately to
>> the consumer of your EPR because Reference Properties are opaque.
>>
>> What's wrong with having an address (not an identifier) for the service
>> and convey the request for the serial number inside the message instead
>> of coupling the "state of the interaction" with something that should
>> really be just an address.
>>
>> For example,
>>
>> Wouldn't something like this be better?
>>
>> <epr>
>>  <wsa:Address>http://service.org/management</wsa:Address>
>> </epr>
>>
>> <soap:Envelope>
>>  <soap:Header>
>>    <wsa:To>http://service.org/management</wsa:address>
>>  </soap:Header>
>>  <soap:Body>
>>    <m:serialNumberRequest>
>>      <m:rackNumber>1</m:rackNumber>
>>      <m:rowNumber>2</m:rowNumber>
>>      <m:collumnNumber>3</m:collumnNumber>
>>    </m:serialNumberRequest>
>>  </soap:Body>
>> </soap:Envelope>
>>
>> Coupling the interaction-specific state with the address means that we
>> have to carry that state whenever we want to pass references around...
>>
>> <epr>
>>  <wsa:Address>http://service.org/management</wsa:Address>
>>  <wsa:ReferenceProperties> <!-- or ReferParams -->
>>    <m:rackNumber>1</m:rackNumber>
>>    <m:rowNumber>2</m:rowNumber>
>>    <m:collumnNumber>3</m:collumnNumber>
>>  </wsa:ReferenceProperties>
>> </epr>
>>
>> Why couple the interaction state with an endpoint? If the Reference
>> Properties are not treated as part of an identifier, why not separate
>> them and treat interaction state as orthogonal to the issue of how
>> services should be addressed? Just concentrate on what the name of the
>> TC suggests... addressing :-)))
>> If, as David Orchard suggested, Reference Properties/Parameters are
>> treated as the interaction data then we end up with a problem of pinning
>> that interaction data to a particular address and, hence, make it
>> difficult to model message exchanges with multiple services that may
>> share interaction data. Using one of Dave's examples (the shopping
>> cart), imagine a situation where one wishes to buy flowers from the
>> flower service and chocolates from the chocolate service. I personally
>> think that architecturally it makes sense to represent the shopping cart
>> as a separate entity and not couple it with the addresses of the two
>> services.
>>
>> It's this
>>
>> <epr>
>>  <Address>urn:shop:flowers</Address>
>>  <ReferenceProperties>
>>    <flower:cart>1</flower:cart>
>>  </ReferenceProperties>
>> </epr>
>>
>> <epr>
>>  <Address>urn:shop:chocolates</Address>
>>  <ReferenceProperties>
>>    <choco:cart>1</choco:cart>
>>  </ReferenceProperties>
>> </epr>
>>
>> Vs this
>>
>> <epr>
>>  <Address>urn:shop:flowers</Address>
>> </epr>
>>
>> <epr>
>>  <Address>urn:shop:chocolates</Address>
>> </epr>
>>
>> <cart:distributed-cart>1</cart:distributed-cart>
>>
>> (please note that the actual SOAP messages may look the same but in the
>> latter case the header was not introduced into the Envelope because of
>> the semantics of the EPR)
>>
>>
>> In the first case I will have two different bills since there is no
>> concept of a shared cart. One could create a cart "instance" using a
>> shopping-cart service and then pass that "by-reference" but this is very
>> much like the distributed-object model and I don't know whether we want
>> to go there :-)
>>
>> It is much easier to reason about the distributed interaction in the
>> second case. I want to buy chocolates? I just communicate with the
>> service and contextualise my interaction with the appropriate
>> cart-specific information. I want to buy flowers? I do the same using
>> the same cart (if I want to).
>>
>> In the example above, we could have used WS-Context for carrying or
>> managing that interaction-specific state. If we were not supportive of
>> WS-Context, however, we could use an application-specific header to
>> contextualise all interactions. The use of such a header would be
>> independent of any addressing-related structures. We could even make it
>> part of the application-specific payload of the message. It's an
>> architecture decision; a decision that does not have to relate to how we
>> address services.
>>
>> The point is that the semantics of the interaction specific state are
>> separated from the address and become visible in the messages. Hence,
>> there is no need to convey any additional semantics out-of-band.
>>
>> Also, what are the implications for EPR equality? If an EPR with
>> Reference Props/Params is not treated as an identifier anymore (which is
>> good of course), then what does equality of such EPRs mean?
>>
>> <epr1>
>>  <wsa:Address>urn:shop:chocolates</wsa:Address>
>>  <wsa:ReferenceProperties>
>>    <choco:cart>1000</choco:cart>
>>  </wsa:ReferenceProperties>
>> </epr1>
>>
>> <epr2>
>>  <wsa:Address>urn:shop:chocolates</wsa:Address>
>>  <wsa:ReferenceProperties>
>>    <choco:cart>1001</choco:cart>
>>  </wsa:ReferenceProperties>
>> </epr2>
>>
>> How do we reason about these two EPRs? They both point to the same
>> address. The consumer of this structure can reason about that. However,
>> they have different reference props. What does this say to the consumer?
>> Obviously, some semantics have to be associated with the EPR out-of-band
>> because the consumer is not allowed to reason about the contents of the
>> reference properties. For example, "epr1 is the address of the
>> chocolates service when using cart 1000" while "epr2 is the address of
>> the chocolates service when using cart 1001". This information is not
>> conveyed at all by just sending an EPR but it is conveyed if we decouple
>> the interaction state from the endpoint reference of a service.
>>
>>
>>
>> To conclude, although in the past I was not against Reference Properties
>> because I liked the way in which they were used in some specifications
>> (e.g. parts of WS-Evenmting) I now propose that the TC considers the
>> removal of Reference Properties/Parameters from the EPR structure. In
>> the spirit of WS composability I think the issues of interaction
>> data/state and addressing should remain separate.
>>
>> Best regards,
>> -- 
>> Savas Parastatidis
>> http://savas.parastatidis.name
>>
>>  
>>
>

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

Received on Tuesday, 18 January 2005 22:46:26 UTC