- From: Martin Gudgin <mgudgin@microsoft.com>
- Date: Mon, 15 Nov 2004 03:23:57 -0800
- To: "Francisco Curbera" <curbera@us.ibm.com>, "David Orchard" <dorchard@bea.com>
- Cc: <public-ws-addressing@w3.org>, <public-ws-addressing-request@w3.org>
Paco, et.al. While I've not had time to digest this fully (I'm somewhat behind on e-mail) my initial take is that it is a coherent and defensible position to take. I have a long plane flight later today so hopefully I'll find time to respond properly. Gudge > -----Original Message----- > From: public-ws-addressing-request@w3.org > [mailto:public-ws-addressing-request@w3.org] On Behalf Of > Francisco Curbera > Sent: 13 November 2004 17:35 > 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)C > ustomerKey=123456789</wsa:Address> > </wsa:EndpointReference> > </wsa:ReplyTo> > </s:Header> > > Service->Client Callback > > <S:Header> > > <wsa:To>http://www.fabrikam123.example/acct?(fabrikamns)Custom > erKey=123456789</wsa:To> > </S:Header> > > Variation 2b: Simple Address > The Address may be significantly simpler, such as > > <wsa:Address>http://www.fabrikam123.example/acct/123456789</ws > a: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_arc > h.htm#sec_2_3 > > > > >
Received on Monday, 15 November 2004 13:20:33 UTC