Re: i0001: EPRs as identifiers

Hi Dave.

* David Orchard <dorchard@bea.com> [2004-11-15 21:13-0800]
[..]
> > > 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.

So I think that we agree that services using EPRs containing reference
properties cannot be used with what I would call globally Web
technologies, because those rely on identification of resources by
URIs only.

You talked about being on the Web mainly in terms of doing HTTP GET
requests and Web infrastructure such as caches. I believe that the
more important issue is that you can't use Web technologies to talk
about your service.

Here is some text for your comparison to add in the advantage for URIs
bucket:

  Using URIs only to identify an endpoint allows to reuse all usual
  Web technologies such as XForms, P3P, RDF, etc.

  It also allows to communicate a reference easily, e.g. in an email,
  on a piece of paper, on a billboard, etc.

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

My argument is that I don't think that there is a clear winner between
each solution on this, that it is purely an implementation artifact:
one can dispatch using the SOAP message content, or one could dispatch
in an equally externally-internally decoupled way using the URI.

So I would actually like to remove advantages on the EPR side for
this.

Also, something which is not clear to me at this point is the
following: if reference properties are specific to a service and
opaque to the client, i.e. arbitrary, and as they always seem to be
things like state id, customer key and the like which can be
serialized in a URI easily, why is XML needed here?

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

I am afraid that I don't get the difference between state id and
state. My understanding is that it is an identifier which refers to a
certain state (hence the name), therefore it indirectly represents
state, but it does not identify a different service.

You seem to think otherwise though. Let's talk about this F2F this
week. We may need a new category for this as I'm not sure it's covered
by the topics that we've discussed previously.

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

I think that it needs to be made clear that, as specified under
simplicity, using a mechanism in addition to URIs to identify a
resource takes you out of the Web and basically leaves you on your own
for a lot of things. I think that this is something which needs to be
very clearly stated, probably in the conclusion as well.

Regards,

Hugo

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