Re: Issue #1: Proposed text and resolution

On Fri, Nov 05, 2004 at 11:27:32AM -0800, David Orchard wrote:
> Issue:
[snip]

Very nicely stated!

Unfortunately, the compliments end there. 8-O 8-)

> 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.
> 
>  
> 
> Performance, Scalability
> 
> No difference.
> 
>  
> 
> Simplicity
> 
> 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.

Are you arguing that *since* EPRs are XML, *and* XML doesn't serialize
well to URI form, therefore it would be simpler not to use URIs? 
Because as I see it, you need to *defend* the choice of XML.  Why do
identifiers need to be in XML?  XML's great and all, but it's not a
panacea.  The only appreciable value I can see in using XML is if those
identifiers weren't opaque.  Is that true?  If not, then XML provides
very little, if any, value-add.  If so, then I'd suggest you've got a
different problem;

  "Agents making use of URIs SHOULD NOT attempt to infer properties of
   the referenced resource."
    -- http://www.w3.org/TR/webarch/#uri-opacity

FWIW, that advice is not specific to URIs, its generic to any
identification system which aims to be deployed at scale, which
presumably is the case for EPRs.

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

That separation you discuss is an implementation detail, not an
aspect of the architecture.  Consider Web servers that have a config
file which is used to map URIs to code, freeing up the code from having
to be bound to any particular URI.  You haven't demonstrated to me that
evolvability is impacted.  In fact, all of these explanations describe
architectural properties in terms of implementation details, not in
terms of architectural constraints.  I don't see how you can make your
case doing that.

> Visibility
> 
> URIs provide for visibility into the interaction between two components.

???

> There are scenarios that indicate visibility into the reference property
> is not necessary.  Inserting the reference property may hinder
> visibility.  The security desired may be at the address level, and
> inserting the URI serialization of the ref property may harm the ability
> to appropriately apply security.  For example, the Address may already
> have query parameters that are part of the service identifier, and the
> reference property as a query parameter may result in difficult parsing
> as the query parameters are not necessarily order preserved.
> Potentially multiple reference properties compounds the problem.  

Implementation details, and a pretty obscure one (and relevant to *very*
few services) at that.

> Additionally, a service provider may not want for the reference property
> to be visible as part of the URI.  Presumably they could encrypt the
> reference property and then insert into the Address field, but this
> leaves us back to the simplicity argument and inserting XML into URIs.
>
> Security
> 
> Dr. Fielding's thesis does not directly address security.  One potential
> aspect of security is "guessing" at endpoints.  Encrypting the reference
> property does not cover signing a reference property.  A reference
> property might be encrypted and signed by a service provider using the
> OASIS WS-Security standard 

The dissertation does cover security, but in architectural terms.
For example, where it talks about the role of self-description,
visibility, etc...  I don't see a problem with guessing identifiers; if
your security policy depends on security through obscurity, I don't
consider that much of a security policy.

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

Ok, but how does that help your case?  I can't see it.

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

Sorry, but I don't think this argument comes anywhere *close* to making
the case for abandoning the most fundamental Web specification of them
all.  But don't feel bad, I don't think *any* argument could. 8-)

The world chose URIs 10+ years ago, and I don't see that changing in my
lifetime, nor even beyond.  New URI schemes, yes.  A whole new
identification system?  Not a snowballs chance in hell.

If abandoning the whole concept of EPRs isn't to the groups liking (8-),
then IMO you need to define an "epr" URI scheme.  That would, I'd say,
make a fine resolution to this issue.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Friday, 5 November 2004 21:45:03 UTC