W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

RE: i0001: EPRs as identifiers

From: David Orchard <dorchard@bea.com>
Date: Sat, 13 Nov 2004 14:49:09 -0800
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF0A3CA57E@ussjex01.amer.bea.com>
To: "Francisco Curbera" <curbera@us.ibm.com>
Cc: <public-ws-addressing@w3.org>

Let me see if I understand you correctly.  

You are asserting that Reference properties are not being used as a
service identifier because:
- Reference properties may be different across multiple
protocols/bindings for the same endpoint
- Reference properties are about the address of the endpoint, not an
identifier for the endpoint.

Any similarity between reference properties, such as the use of words
like identity and the equivalence function, and identifiers is
misleading and should be corrected.

Is that roughly right?


> -----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
> architecture expertise to help us navigate these murky waters.
> 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
> to prompt this concern and the current resolution approach. In
> Section 2.1 in the core document draft talks about using reference
> properties to "identify" the entity being conveyed. However, I claim
> 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
> not be appropriately supported.
> My central point is that the idea that EPRs identify service endpoints
> wrong and potentially dangerous. There is a key different between
> identifiers and addresses. The Web architecture document correctly
> that different identifiers (URIs) should not be associated with the
> 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
> with having multiple for the same entity.
> However, in the case of EPRs the ability to issue multiple different
> for the same endpoint is a fundamental requirement. There are
> where multiple access channels to the endpoint are provided but they
> to be selectively exposed to different clients; the hosting
> may issue different EPRs to different clients such that a client
> application would be able unable to tell whether they correspond to
> 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
> me in the way my social security number can, but is useful if you want
> get your letters to me. I have several mail addresses but a single
> security number. The notion of address assumes that the same entity
> 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
> with the spirit of Web services than this identity based approach. An
> encapsulates the information that must be conveyed in a message
> to
> ensure that it can be properly delivered to the endpoint. This is
> not the same as providing an identifier for the resource, but is
> 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
> providing the means to interoperably direct (address) messages to
> Moreover, I think we should state that the identification of endpoints
> not within the scope of this WG. We just need to make these points
> in
> the spec and let the TAG rest at ease knowing we are not trying to
> their carefully constructed Web architecture.
> Paco
>                       "David Orchard"
>                       <dorchard@bea.com>              To:
> 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
> 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
> resource representations and indirectly about when URIs should be
> 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
> 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
> 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
> 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
> 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
> services or interactions, nor does it discuss the use of HTTP Cookies
> contain state or state identifier information.  To a certain degree,
> comparison of URIs vs EPRs may be thought of as a comparison of URIs +
> 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
> 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
> or primer or ..., that shows the benefits to be gained from
> reference properties and parameters.  It includes a comparison with
> only solutions.
> Sample applications and benefits
> A sample application is introduced with a skeletal display of use of
> and EPRs.
> Sample application #1: Stateful Web service client.
> A stateful service acting as a client makes a request to another
> The client makes a request containing a ReplyTo containing an EPR.
> 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
> into the Address using an extension of QName/URI binding style #10 in
> Client->Service:request
> <s:Header>
> <wsa:ReplyTo>
>    <wsa:EndpointReference>
> 23456789</wsa:Address>
>   </wsa:EndpointReference>
> </wsa:ReplyTo>
> </s:Header>
> Service->Client Callback
> <S:Header>
> 789</wsa:To>
> </S:Header>
> Variation 2b: Simple Address
> The Address may be significantly simpler, such as
> Comparison of Variations.
> This comparison uses the Architecture properties of Key interest
> 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
> 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
> is not standardized and potentially problematic, some of the issues
> - 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
> 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
> 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
> 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,
> shown in example 2b.  This enables the web service to be "on the Web"
> 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
> such as caching intermediaries, security firewalls, etc..  This can
> 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
> the deployment address of the service from the reference properties.
> effectively separates the concerns of identifiers into externally
> and evolvable from the internally visible and evolvable.  For example,
> dispatcher could evolve the format it uses for reference properties
> without
> concern of the URI related software.  The use of SOAP tools - for
> the soap header for the reference properties - or xml tools - such as
> 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
> There are scenarios that indicate visibility into the reference
> is
> not necessary.  Inserting the reference property may hinder
> The security desired may be at the address level, and inserting the
> serialization of the ref property may harm the ability to
> apply security.  For example, the Address may already have query
> parameters
> that are part of the service identifier, and the reference property as
> query parameter may result in difficult parsing as the query
> are
> not necessarily order preserved.  Potentially multiple reference
> properties
> compounds the problem.
> Additionally, a service provider may not want for the reference
> 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
> 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
> aspect of security is "guessing" at endpoints.  Encrypting the
> 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
> real-world deployed architectures.  A significant portion of the Web
> 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
> Additionally, a variety of efforts have been undertaken to facilitate
> mapping of XML and QNames to URIs, such as WSDL 2.0 HTTP Binding.
> 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
> EPRs without reference properties is a complex choice best left to the
> application developer.  As they have the choice with a Web of HTTP
> and
> HTTP Cookies today, WS-Addressing gives Web service application
> the choice of their identifier architecture.  They can use URI only
> and they can use URIs + XML based reference properties and parameters.
> [1]
> [2]
> 3
Received on Saturday, 13 November 2004 22:49:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:07 UTC