Re: i0001: EPRs as identifiers

Hi Dave.

Nicely structured comparisons. Please see some comments below.

* David Orchard <dorchard@bea.com> [2004-11-12 22:13-0800]
[..]
> Comparison of Variations.
> 
>  
> 
> This comparison uses the Architecture properties of Key interest section
> from Dr. Fielding's thesis [2] as the criteria for evaluating these 2
> styles.  This is based upon the network characteristics of the
> architectures.  Note that the thesis specifically excludes those
> properties that are of interest to software architectures.
[..]
> 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.
> 
>  
> 
> 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.
> 
>  
> 
> Advantages of URIs
> 
> In many cases, the complexity of XML is not needed for the identifier,
> as shown in example 2b.  This enables the web service to be "on the Web"
> as an HTTP GET can be used to retrieve a representation of the state of
> the resource.  This also enables much of the web infrastructure to
> operate, such as caching intermediaries, security firewalls, etc..  This
> can lead to easier to debug systems (a web browser can retrieve the
> state for a human)..  

While it is true that mapping XML to URIs is hard and impractical, why
do reference properties need to be URIs?

They are identifiers used for routing for the service use, the service
provider can arbitrarily decide about their name and format, and the
URI syntax is likely to be sufficient.

Therefore, EPRs _introduce_ complexity by introducing a new
identification mechanisms. In order to talk about something on the Web
that would use Web services technologies, we would then need more than
just a URI: we would need a URI plus a bunch of XML.

Let's assume that I want to use XForms as an interface to my Web
service. The submission element uses a URI for the destination of its
action, which means that XForms would not be usable with reference
properties. Pick any specification from the TR page and you're likely
to reach the same conclusion.

Also, what about if I want to tell you about the address of my cool
service? Pasting a URI in an email is much simpler than pasting some
XML.

Therefore, the introduction of EPRs as identifiers will have a very
high cost.

> Evolvability
> 
> Advantage of EPRs
> 
> Separating the reference property from the URI may make it easier for
> service components to evolve.  A service component may know nothing
> about the deployment address of the service from the reference
> properties.  This effectively separates the concerns of identifiers into
> externally visible and evolvable from the internally visible and
> evolvable.  For example, a dispatcher could evolve the format it uses
> for reference properties without concern of the URI related software.
> The use of SOAP tools - for parsing the soap header for the reference
> properties - or xml tools - such as an xpath expression on the message -
> allow separate evolvability of components.  
> 
>  
> 
> Advantage of URIs
> 
> No advantage to URIs for evolvability.  

I believe that your analysis presupposes that what you call the
service component sits at a particular externally visible URI and
routes to a service which is only internally visible based on XML.

Web servers do routing based on URIs all the time: when I contact
www.w3.org on port 80 and I ask for http://www.w3.org/2002/ws/addr/,
the Web server serves me data that it may have gotten from
/wwwroot/2002/ws/addr/Overview.html on the filesystem, or from
/wwwroot/2002/ws/addr/index.html, or from some other place, or from a
Perl script that it found again somewhere else on the filesystem, or
that it's proxying from another machine, etc.

Similarly, programs that the Web server may invoke can do similar URI
routing. One can change the program and its location without changing
the URI and vice-versa.

Therefore, I don't believe that the external view of the URI is
tightly coupled to the internal representation and that URIs are an
obstacle to evolvability. It all depends on the implementation.

[..]
> Real-World
> 
> Advantage of EPRs
> 
> It is useful to examine not only theoretical architectures properties
> but real-world deployed architectures.  A significant portion of the Web
> is deployed with stateful web components that use HTTP Cookies to
> contain session or state identifying information.  For a variety of
> reasons, typically those detailed previously, application developers
> have chosen to use HTTP Cookies to contain identifying information in
> addition to URIs.  
> 
>  
> 
> Additionally, a variety of efforts have been undertaken to facilitate
> mapping of XML and QNames to URIs, such as WSDL 2.0 HTTP Binding.  There
> does not appear to be substantial product group interest in these
> technologies.  
> 
>  
> 
> Advantage of URIs
> 
> The subset of the Web that is "on the Web", that is has a URI that is
> dereferenceable, is clearly widely scalable, deployed, etc.

I believe that cookies do not come in the picture of identifying a
service, but of carrying state (RFC 2109 is about state management).

I believe that this argument works for reference parameters, that do
not service to identify a service: WS-Addressing says that they refer
to endpoints that have the same "associated metadata".

> Conclusion
> 
> This has shown that the choice of EPRs with Reference Properties versus
> EPRs without reference properties is a complex choice best left to the
> application developer.  As they have the choice with a Web of HTTP URIs
> and HTTP Cookies today, WS-Addressing gives Web service application
> developers the choice of their identifier architecture.  They can use
> URI only EPRs and they can use URIs + XML based reference properties and
> parameters.  

I don't think that the comparison is between URIs and EPRs but between
URIs and URI+RefProp's, leaving cookies out of the picture.

The one fundamental piece of the Web is identification with URIs. I
don't think that the above comparison shows enough advantages for
justifying the introduction of a new identification mechanism.

Regards,

Hugo

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