RE: i0001: EPRs as identifiers

Hi David,

> Paco & Savas,
> 
> Regarding:
>
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0355.ht
ml
>
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0358.ht
ml
> 
> If I understand you correctly, you are arguing that an EPR is *not*
used
> to identify "the service", rather it is merely used to route messages
to
> one of several delivery points belonging to the same logical
"service".
> 

<snip />

I don't want to argue on Paco's behalf so I won't do it :-) Here's my
view...

My agreement with Paco's argument was about the difference between a
reference and an identifier. For example, your bank account number is an
identifier which is independent of any communication/infrastructure
technology. You can use that identifier when you call your bank over the
phone, when you access your account details over the web, when you
create a CORBA object to represent your account (the identifier is a
property of the object and not the IOR itself), etc. I hope you see
where I am coming from and I think that's what Paco meant when I agreed
with him.

Now, on EPRs...

To me, an EPR identifies the destination of a message. I don't think
EPRs should be used as identifiers of or references to resources. Since
we are talking about Web Services, an EPR should be a reference to a
service. 

I personally have mixed feelings about the Ref Props/Params. I really
like the way they are used in WS-Eventing when a subscriber gives an EPR
to the event source telling it how to communicate with the event sink.
The event source doesn't really know anything about the semantics of
that EPR (whether it's a stateful resource, a service, a black hole). It
just includes some additional information into the message, as it was
asked to do. Conceptually, the architecture does not change as far as
the event source is concerned.

However, in the same spec we see a different use of the EPR where it is
used to refer to a subscription instance (a resource). WS-RF and
WS-Transfer do this as well. There is a conceptual change at the
architectural level; one that suggests a move from service-orientation
to resource-orientation. In WS-RF for example an EPR is a reference to a
WS-Resource not a service. Architects and developers now have to reason
in terms of resources and not in terms of services. In the WS-Eventing
case, I no longer send the message to the subscription manager. I have
to reason in terms of a specific resource (the subscription) and I have
to send my message there.

The analogy in real life would be that we don't talk to our bank
accounts but we talk to our bank about our accounts.

Yes, one would argue that a service can be seen as a resource but I
personally see a difference; the former isn't explicitly associated with
state or state representation while the former is (just in case I am
misunderstood... this doesn't mean that there is no state in services).

However, I am sidetracking here to a different, more difficult
discussion which is architecture-related and, perhaps, more abstract.

To return to the Ref Props/Params discussion. I can see Gudge's and
others' argument about the benefit of instructing a sender to include
SOAP headers to the messages it sends to an endpoint. However, I also
observe the manner in which specs like WS-RF and WS-Transfer use EPRs as
if they were network-wide object pointers. Perhaps that's not the
intention of the WS-RF and WS-Transfer spec authors but that's how I see
people using it. One could say that this is fine, since we shouldn't
mandate a single architectural view to everyone.

BTW... I think a simple EPR like the one bellow will cause some problems
:-)

<wsa:EndpointReference>
  <wsa:Address>Uri</wsa:Address>
  <wsa:ReferenceProperties>
    <wsa:Action>urn:to:add:header:or:not:to:add</wsa:Action>
  </wsa:ReferenceProperties>
</wsa:EndpointReference>

Regards,
--
Savas Parastatidis
http://savas.parastatidis.name

Received on Wednesday, 17 November 2004 22:55:40 UTC