Re: Issue #1 proposed resolution

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:39:20 UTC