RE: i0001: EPRs as identifiers

BTW, I notice that Omri talks about Ref properties as part of the
identifier for an endpoint:

http://www.gazitt.com/OhmBlog/permalink.aspx/deea5866-4da7-4774-b7c6-4da
a7aabaec9

I think in my discussion I focused on Ref properties, and I did not
mention Ref parameters.

Cheers,
Dave

> -----Original Message-----
> From: Francisco Curbera [mailto:curbera@us.ibm.com]
> Sent: Saturday, November 13, 2004 9:35 AM
> To: David Orchard
> Cc: public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
> Subject: Re: i0001: EPRs as identifiers
> 
> 
> 
> 
> 
> I appreciate very much Dave's proposal and the advantage of having his
Web
> architecture expertise to help us navigate these murky waters.
However,
> before we approach the TAG or do anything drastic like that, I think I
> need
> to explain my qualms about the way we seem to be approaching this
issue; I
> have the feeling I am in a minority in this, but I fear an important
> perspective may be lost in this discussion.
> 
> First, we need to admit that the specification contains specific
language
> to prompt this concern and the current resolution approach. In
particular,
> Section 2.1 in the core document draft talks about using reference
> properties to "identify" the entity being conveyed. However, I claim
that
> this language is misleading and not consistent with the spirit of the
> spec;
> moreover, if we take it to its final conclusion important use cases
will
> not be appropriately supported.
> 
> My central point is that the idea that EPRs identify service endpoints
is
> wrong and potentially dangerous. There is a key different between
> identifiers and addresses. The Web architecture document correctly
states
> that different identifiers (URIs) should not be associated with the
same
> resource; while aliases are not prohibited, they do undermine the
> usefulness of URIs as identifiers and impose unnecessary cost on URI
> consumer applications. The notion of identifiers is essentially at
odds
> with having multiple for the same entity.
> 
> However, in the case of EPRs the ability to issue multiple different
ones
> for the same endpoint is a fundamental requirement. There are
situations
> where multiple access channels to the endpoint are provided but they
need
> to be selectively exposed to different clients; the hosting
infrastructure
> may issue different EPRs to different clients such that a client
> application would be able unable to tell whether they correspond to
the
> same resource or not. To abuse the snail mail metaphor a bit more, the
> address that is encoded in a letter sent to me cannot be used to
identify
> me in the way my social security number can, but is useful if you want
to
> get your letters to me. I have several mail addresses but a single
social
> security number. The notion of address assumes that the same entity
may
> have many, in contrast with the notion of identity (as the Web Arch.
> document recognizes).
> 
> A "wire-centric" interpretation of EPRs, I think, is much more
consistent
> with the spirit of Web services than this identity based approach. An
EPR
> encapsulates the information that must be conveyed in a message
envelope
> to
> ensure that it can be properly delivered to the endpoint. This is
clearly
> not the same as providing an identifier for the resource, but is
essential
> to ensure interoperable access to endpoints.  Regardless of how
> inconsistent the language in the current spec is today, we need to
make it
> clear that WS-Addressing is not about identifying resources but only
about
> providing the means to interoperably direct (address) messages to
them.
> Moreover, I think we should state that the identification of endpoints
is
> not within the scope of this WG. We just need to make these points
clear
> in
> the spec and let the TAG rest at ease knowing we are not trying to
break
> their carefully constructed Web architecture.
> 
> Paco
> 
> 
> 
> 
> 
> 
> 
> 
>                       "David Orchard"
>                       <dorchard@bea.com>              To:
<public-
> ws-addressing@w3.org>
>                       Sent by:                        cc:
>                       public-ws-addressing-req        Subject:  i0001:
> EPRs as identifiers
>                       uest@w3.org
> 
> 
>                       11/13/2004 01:13 AM
> 
> 
> 
> 
> 
> I offer a proposal for what the issue is, and a solution
> 
> Issue:
> 
> WS-Addressing EPRs specify a resource identification mechanism, called
> reference properties and reference parameters, in addition to URIs for
> identification purposes.  There is not a clear justification of the
> benefits of such an additional resource identification mechanism.
> 
> The W3C Web architecture [1] states "To benefit from and increase the
> value
> of the World Wide Web, agents should provide URIs as identifiers for
> resources.  Other resource identification systems (see the section on
> future directions for identifiers) may expand the Web as we know it
today.
> However, there are substantial costs to creating a new identification
> system that has the same properties as URIs."
> 
> The W3C TAG was asked the question about when to use GET for
retrieving
> resource representations and indirectly about when URIs should be
provided
> for resources in Issue #7 [2] and produced a finding [3].  Some of the
> finding material is included in the Web arch document.  The Web
> architecture is clear that there are substantial costs associated with
> resource identification systems other than URIs and the implication is
> that
> the benefits to such additional systems should be substantial.
> 
> The URI specification [4] provides a definition of a resource "A
resource
> can be anything that has identity."  Thus we do not need to determine
> whether an EPR identifies a resource or not, but whether an EPR is
used as
> an identifier.
> 
> The WS-Addressing member submission [5] is fairly clear that EPRs are
used
> for identification purposes.  Some sample quotes used in the document:
> "Dynamic generation and customization of service endpoint
descriptions. "
> "Identification and description of specific service instances"
> "we define a lightweight and extensible mechanism to dynamically
identify
> and describe service endpoints and instances"
> "Specific instances of a stateful service need to be identified"
> "A reference may contain a number of individual properties that are
> required to identify the entity or resource being conveyed"
> 
> A tell-tale sign of identifiers is comparisons of identifiers.  The
URI
> specification provides rules for URI comparison.  The WS-Addressing
> submission provides rules for EPR comparison.
> 
> Note that the Web architecture does not discuss stateful versus
stateless
> services or interactions, nor does it discuss the use of HTTP Cookies
to
> contain state or state identifier information.  To a certain degree,
the
> comparison of URIs vs EPRs may be thought of as a comparison of URIs +
> HTTP
> cookies vs EPRs.  However, this comparison will describe EPRs with
> reference properties without discussion of HTTP cookies, but the
> similarity
> of the benefits of HTTP cookies and EPR reference properties is
captured
> in
> the EPR benefits.
> 
> [1] http://www.w3.org/TR/webarch/#uri-benefits
> [2] http://www.w3.org/2001/tag/issues.html#whenToUseGet-7
> [3] http://www.w3.org/2001/tag/doc/whenToUseGet.html
> [4] http://www.ietf.org/rfc/rfc2396
> [5] http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/
> 
> 
> Resolution:
> The WS-Addressing WG will provide material, TBD format such as
standalone
> or primer or ..., that shows the benefits to be gained from
WS-Addressing
> reference properties and parameters.  It includes a comparison with
URI
> only solutions.
> 
> Sample applications and benefits
> A sample application is introduced with a skeletal display of use of
URIs
> and EPRs.
> 
> Sample application #1: Stateful Web service client.
> 
> A stateful service acting as a client makes a request to another
service.
> The client makes a request containing a ReplyTo containing an EPR.
The
> invoked service responds with the requested information including an
> WS-Addressing EPR processing model
> 
> Variation #1: Reference properties
> Client->Service:request
> <s:Header>
> <wsa:ReplyTo>
>    <wsa:EndpointReference>
>   <wsa:Address>http://www.fabrikam123.example/acct</wsa:Address>
>    <wsa:ReferenceProperties>
>        <fabrikam:CustomerKey>123456789</fabrikam:CustomerKey>
>    </wsa:ReferenceProperties>
>   </wsa:EndpointReference>
> </wsa:ReplyTo>
> </s:Header>
> 
> Service->Client Callback
> 
> <S:Header>
>     <wsa:To>http://www.fabrikam123.example/acct</wsa:To>
>     <fabrikam:CustomerKey>123456789</fabrikam:CustomerKey>
> </S:Header>
> 
> Variation #2a: Address only with full featured Qname to URI mapping
> 
> This takes the fabrikam:CustomerKey Qname and content and incorporates
it
> into the Address using an extension of QName/URI binding style #10 in
[1]
> Client->Service:request
> <s:Header>
> <wsa:ReplyTo>
>    <wsa:EndpointReference>
> 
>
<wsa:Address>http://www.fabrikam123.example/acct?(fabrikamns)CustomerKey
=1
> 23456789</wsa:Address>
>   </wsa:EndpointReference>
> </wsa:ReplyTo>
> </s:Header>
> 
> Service->Client Callback
> 
> <S:Header>
> 
>
<wsa:To>http://www.fabrikam123.example/acct?(fabrikamns)CustomerKey=1234
56
> 789</wsa:To>
> </S:Header>
> 
> Variation 2b: Simple Address
> The Address may be significantly simpler, such as
>
<wsa:Address>http://www.fabrikam123.example/acct/123456789</wsa:Address>
> 
> 
> 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
> Advantage of URIs
> Comparing URIs is simpler than comparing EPRs because the cost of
> canonicalizing EPRs can be significant given the XML C14N algorithm.
> 
> 
> Scalability
> No difference.  Both styles support stateful and stateless
interactions.
> 
> 
> 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)..
> 
> 
> 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.
> 
> Visibility
> Advantage of EPRs
> 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.
> 
> 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.
> 
> Advantage of URIs
> URI only EPRs offer clearly higher visibility into the message for any
> intermediary.
> 
> Security
> Advantage of EPRs
> 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
> 
> 
> 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.
> 
> 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.
> 
> [1]
http://www.pacificspirit.com/blog/2004/04/29/binding_qnames_to_uris
> [2]
>
http://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_
2_
> 3
> 
> 
>

Received on Saturday, 13 November 2004 23:13:24 UTC