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

RE: i0001: EPRs as identifiers

From: Srinivas, Davanum M <Davanum.Srinivas@ca.com>
Date: Sat, 13 Nov 2004 18:16:34 -0500
Message-ID: <87527035FDD42A428221FA578D4A9A5B0858D78D@usilms24.ca.com>
To: "David Orchard" <dorchard@bea.com>, "Francisco Curbera" <curbera@us.ibm.com>
Cc: <public-ws-addressing@w3.org>, <public-ws-addressing-request@w3.org>

Blogs are good!!! :) Does this change your proposal?


-----Original Message-----
From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of David Orchard
Sent: Saturday, November 13, 2004 6:13 PM
To: Francisco Curbera
Cc: public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
Subject: RE: i0001: EPRs as identifiers

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


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


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

> 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
> 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 23:16:46 UTC

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