RE: i0001: EPRs as identifiers

I've hacked this up a bit.
> > 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.
> 

By your argument, HTTP POST FORMs should be lobbied against.  The HTML
working group ought to be called to the matt in front of the TAG and
provide justification for why HTTP POST forms are permitted to exist as
HTTP POST forms results are not on the Web.  I think it's clear and
obvious that there are some advantages to resources being on the Web,
but also that not all resources need to be on the web. 

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

Hmm.  Another person trying to lobby the "implementation detail"
argument.  I don't get this argument.  

How I construct URIs is an implementation detail.  How I use cookies is
an implementation detail.  Whether I use GET or POST for my HTML forms
is an implementation detail.   Whether CSS or XSLT or DOM or ECMAscript
or Java Applets is an implementation detail.

I will also point out that by one view, REST is designed for
implementation details.  Because REST and the Web have a restricted verb
set, use URIs, and have self-describing data (namely the mime type) an
intermediary gets higher visibility into the message.  These constrains
enable an implementation of an intermediary to do it's thing with the
message.  By the same argument that you raise, I could have lobbied ten
years ago against self-describing data and say that's just an
"implementation detail" of whether the app puts a media-type in or not.
But that argument correctly didn't fly back then as people said that
with certain constrains, certain properties (in this case visibility)
are achieved.  

I think I've demonstrated that "implementation detail" is irrelevant to
comparing the architectural properties of URIs and EPRs.  What is
relevant is the ability to build the kinds of implementations that we
want.  In some cases, XML based dispatch is good, in others URIs are
good.  Let's focus on the properties.  

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

I've already shown that they aren't easily serialized into a URI.  I
have shown and referenced this many many many times now.  And XML is
needed because the receiver is built using XML.  Why are we debating
whether XML based apps are a good thing or not?
> > 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.
> 

I'm using the state id example to show that a large # of services are
built using stateful services (where state is kept on the service
between invokes) and the message contains an ID for that state.  That is
a very common application of cookies and we believe for EPRs.  All of
these "stateful" services are off the web.  

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

I have no problem saying that use of Ref Props/Params in EPRs takes a
resource off the Web, the same way that HTTP cookies and HTML FORM POSTS
results identify resources that are off the web.  There are definite
disadvantages and advantages to this

Cheers,
Dave

Received on Friday, 19 November 2004 20:34:02 UTC