RE: Issue #1 proposed resolution

<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

Received on Tuesday, 18 January 2005 22:24:48 UTC