RE: i0001: EPRs as identifiers

Hugo, 

Comments inline

> -----Original Message-----
> From: Hugo Haas [mailto:hugo@w3.org]
> Sent: Monday, November 15, 2004 7:43 AM
> To: David Orchard
> Cc: public-ws-addressing@w3.org
> Subject: 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.

Could you provide a shorter proposed text?  I'll point out that the cost
of deploying an additional infrastructure might not be as high as you
think, given that SOAP infrastructure already exists, and the cost of
Ref props in addition to deploying EPRs + WS-A is a fixed cost (ie we're
already doing EPR + WS-A so that can't be counted as part of the cost).
I should actually say that somewhere, that the incremental costs for Ref
properties isn't that high given deployed SOAP stacks and introduction
of WS-A.  

If an author wants to use XForms, why couldn't they use an XForm
compliant URI in the EPR?  Now if you want to talk about sucky bindings
of XML to URIs, I could be all over that.  But I don't think that's the
issue.  The XForm creator has the option in EPRs to use just a URI.

> 
> > 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.
> 

Can you provide shorter text?  4 paragraphs seems a bit lengthy.

> [..]
> > 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".
> 

My company uses cookies to identify a service using a state id.  I think
a majority of cookie uses are for state id not state.  I absolutely and
completely couple the use of ref properties with state identifiers as
arguably the most common use case for the scenario.  But before you
mention "stateless", remember that I'm the one who brought up the
stateless web service as a scenario for EPRs at the tail end of the
discussion.

> > 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.
> 

What a surprise (oosh, inner voice Dave).  I think you are ignoring the
realities of the Web, in particular the HUGE use of cookies for state
identifiers but not for state.  I have a very large installed customer
base that makes extensive use of that facility, for the reasons listed
earlier.  

To be blunt, I think many of the URI folks think that cookies for state
id are very bad, that web services ought to be stateless.  I've
separately rebutted that point many times, but the point is that cookies
are here and useful and good, and Ref Props bring the same kind of
echoing capability to SOAP.  And the Web Arch certainly does NOT say
that stateful services are bad or that cookies are bad.  

Remember that this comparison does not "weight" the concerns.  Some
folks consider some of the items listed to be incredibly high in
importance.

Cheers,
Dave

Received on Tuesday, 16 November 2004 05:13:24 UTC