Re: i001: EPRs as identifiers: update to EPR pros and cons by adding ref prop scenario

Hi Dave.

* David Orchard <dorchard@bea.com> [2004-12-03 09:11-0800]
> I offer a proposal for what the issue is, and a solution
>
>
>
> Issue:
>
>
>
> WS-Addressing EPRs specify a resource identification mechanism, called
> reference properties and reference parameters, in addition to URIs for
> identification purposes.  There is not a clear justification of the
> benefits of such an additional resource identification mechanism.
[..]
> A tell-tale sign of identifiers is comparisons of identifiers.  The URI
> specification provides rules for URI comparison.  The WS-Addressing
> submission provides rules for EPR comparison.

As I said in the past, the EPR versus URI comparison as identifiers is
really about URI + Reference Properties versus URIs by themselves IMO.
To back this claim, the comparison section only mentions the [address]
and [reference properties] properties of an EPR.

[..]
> Sample application #1: Stateful Web service client.
>
>
>
> A stateful service acting as a client makes a request to another
> service.  The client makes a request containing a ReplyTo containing an
> EPR.  The invoked service responds with the requested information
> including an WS-Addressing EPR processing model
[..]

I still think that, in this example, fabrikam:CustomerKey is a
reference parameter and not a reference property, but I think that
your second example (thank you for providing it) is a better one for
the purpose of our discussion.

> Scenario #2: Reference Properties + Parameters
>
>
>
> A transaction coordinator supports 3 possible interfaces.  Context
> Management, such as CreateContext, is interface A.  There are 2
> supported transaction protocols, interfaces B and C.  The typical
> pattern of interaction is that a client uses interface A, and then one
> of interface B or C, depending upon the type of protocol requested.
> Operations are b in interface B and c in interface C.  For simplicity,
> we will collapse the registration for a protocol step.  The interaction
> pattern is:
>
> 1. Client sends CreateContext to A
>
> 2. A returns Context which contains EPR to register for context.
>
> 3. Client invokes operation b or c from interface B or C to EPR. The
> coordinator determines which interface is invoked based upon the EPR.
> The interface invoked must match the requested protocol or a fault is
> generated.
>
>
>
> Variant #1: URI centric deployment
>
> The context creation service, implemented with interface A, is deployed
> at URI http://example.org/A. The transaction management services, that
> implement interfaces B and C, are deployed at http://example.org/B and
> http://example.org/C.   For comparison, we shall assume that the URIs
> have a similar lifetime to the EPR with Reference Properties.
>
>
>
> EPRs looks like:
>
> <wsa:EndpointReference>
>
>  <wsa:Address>http://example.org/A</wsa:Address>
>
> </wsa:EndpointReference>
>
>
>
> <wsa:EndpointReference>
>
>  <wsa:Address>http://example.org/B/tx:Id/1234</wsa:Address>
>
> </wsa:EndpointReference>
>
>
>
> <wsa:EndpointReference>
>
>  <wsa:Address>http://example.org/C/tx:Id/5678</wsa:Address>
>
> </wsa:EndpointReference>
>
>
>
> Client issues request b or c to the EPR

Or it could also look like:

  <wsa:EndpointReference>
    <wsa:Address>http://example.org/B</wsa:Address>
    <wsa:ReferenceParameters>
      <tx:Id>1234</tx:Id>
    </wsa:ReferenceParameters>
  </wsa:EndpointReference>

Again, I would like to emphasize that issue i001 IMO is really about
reference properties, on which we should focus the debate.

> Variant #2: Ref Property centric deployment.
>
> Interface A, B, C are deployed at URI http://example.org/A.  The create
> context returns an EPR with Reference Properties that identify the
> interface, and Reference Parameters that identify the instance.
>
>
>
> The EPRs are:
>
> <wsa:EndpointReference>
>
>  <wsa:Address>http://example.org/A</wsa:Address>
>
> </wsa:EndpointReference>
>
>
>
> <wsa:EndpointReference>
>
>  <wsa:Address>http://example.org/A</wsa:Address>
>
>  <wsa:ReferenceProperties>
>   <m:Prop>PhaseZero</m:Prop>
>  </wsa:ReferenceProperties>
>
>  <wsa:ReferenceParameters>
>
>    <tx:Id>1234</tx:Id>
>  </wsa:ReferenceParameters>
>
> </wsa:EndpointReference>
>
>
>
> <wsa:EndpointReference>
>
>  <wsa:Address>http://example.org/A</wsa:Address>
>
>  <wsa:ReferenceProperties>
>   <m:Prop>TwoPhase</m:Prop>
>  </wsa:ReferenceProperties>
>
>   <wsa:ReferenceParameters>
>
>    <tx:Id>1234</tx:Id>
>  </wsa:ReferenceParameters>
>
> </wsa:EndpointReference>

Agreed.

> Comparison of Variations.
[..]
> Simplicity
>
>
>
> Advantages of EPRs
>
> Web services are based upon XML.  Many applications use XML as the
> mechanisms for identifying their components.  The binding of XML into
> URIs is not standardized and potentially problematic, some of the issues
> being:
>
> - XML contains QNames as element names, attribute names, and content.
> QNames are based upon absolute URIs.  URIs in URIs is not simple.
>
> - XML elements can have multiple children at all levels, whereas URIs
> have path hierarchy that ends in a multiple children query parameters.
>
> - The XML information model is complex with attributes, elements, PIs,
> comments, entity references and whitespace.  These do not match well to
> URIs.
>
> - Character encodings are different between XML and URIs.
>
> - URIs have potential length restrictions
>
> - URIs have different security properties than SOAP header blocks, such
> as level of encryption and signing.
>
> - I18N may be better served by XML structures than URI structures
> because of flexibility in the XML encoding character sets.
>
>
>
> XML applications that use XML for identification will probably be
> simpler to write with EPRs than with URI only identifiers.  This
> includes SOAP tools and XML tools.

I am sympathetic to the temptation to use XML for identifying things
on the Web and the difficulty of serializing arbitrary XML into URIs.

However, the Web uses URIs. As shown above in your examples and in
previous discussions over the past few weeks mentioning opacity,
arbitrary XML is not needed: there always is an alternative to use
URIs (I have yet to see an example where it is not the case).

Unfortunately, this alternative way introduces a new mechanism for
identifying things on the Web. It is still not clear to me that people
*cannot* do something without reference properties that they could do
with them, or that there would be substantial cost associated with
this.

I will make the following — non-exclusive, as one could say that ref
prop could also be part of the URI path, etc. — parallel in EPRs
versus the current real-world Web:

 [address]   URI

 [reference properties]  HTTP cookies used to identify
     a resource

 [reference parameters]  HTTP cookies used to carry
     state

I hope that we can agree on this parallel.

To me, HTTP cookies used to identify a resource is a bad use of
cookies. While I agree that it is a (bad) practice which is sometimes
done today — which I believe not to be the most frequent use of
cookies —, I do not think that we should legitimize it and encourage
people to do it, especially as, once again:
- it is possible to do without it.
- it has huge implications for the Web and Web technologies that are
  all based on URIs.

However, if one really wanted to do it and they were not allowed to
use reference properties, then they could *still* do it with reference
parameters only, the same way people can do it with just cookies now,
in addition to URIs.

Based on previous discussions that have not been reflected in your
updated comparison, I and other believe that having this new
identification mechanism is a bad idea.

Therefore, I would like to propose that we close issue i001 by
removing reference properties from the specification.

Regards,

Hugo

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/