Re: i0001: EPRs as identifiers

Issue 1 states the following:
“
The Architecture of the World Wide Web, First Edition indicates that 
distinct resources must be assigned to distinct URIs. This must be 
considered when refining the mechanism for the service specific message 
headers.
“

If reference properties are to be consistent with the web architecture, 
we need to define a new term for the “thing” behind the web resource 
addressed by the URI, that the action is “dispatched to”. I suggest that 
a term (say “Web Service Endpoint”) needs to be formally defined to 
allow us to talk about this “thing” without conflicting with the Web 
Architecture. (suggestions for better terms are welcomed, but that is 
what I will use in the rest of this email)..

Side note (
This of course should be absolutely optional and not rule out the other 
design pattern where a Resource is identified by an URI which includes 
the URL of the Web Service through which it is accessed. In the latter, 
the address is of the (Web) Resource itself. In the former, the address 
is of the Web service only, and the resource ID is just a property of 
this reference. In that case we could call also such a resource a “[Web] 
Service Resource”, to avoid confusion with “Web Resource” (instead of 
the term “web service endpoint” which I chose above to get rid of the 
resource word). A Service Resource implies that it is used via a 
Service, (Web service or other), and therefore does not need to be 
addressed directly via the Web (URI) although it may.)

Before the concept of reference properties can be reconciled with the 
web architecture, the intended uses (and associated semantics) of 
reference properties associated with a Web Service address URI need to 
be clarified by this group.

Examples of fuzzy semantics (these regard the soap binding) needing 
clarification:
a) For the SOAP binding, what are the intended targets for these 
reference parameters sent sent in soap headers?

b) Do all the reference properties need to be targeted to the final web 
service destination address? It would seem that this is required for the 
web service to dispatch the operation to the intended web service 
resource. I believe any “routing” info for intermediaries need be dealt 
with separately.

c) If the reference properties are intended to be directed at soap 
actors other than the ultimate web service addressed by the URI, how 
does the Sender know what values to put in the SOAP actor for the header 
containing the reference parameter(s)?
If this is required, the role(s) associated with headers would be 
specified in the EPR I guess.

I believe these points, and others, need to be clarified before the 
concept of resource properties can be reconciled with the web architecture.

I also have included some explicit comments on David Orchard’s proposal 
below:

David Orchard wrote:

 > 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.
 >
This might be aided by introducing a new term for the “thing” which is 
being referenced “behind” the URI in the destination address. (e.g, Web 
Service Endpoint). This would be distinguished from the concept of “web 
resource” which is described in the following paragraph of Dave’s 
contribution.
 >
 >
 > 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.
 >
Again, defining a new term for the “thing” behind the web resource 
identified by the URI, is required to reconcile reference properties 
with the Web Architecture.
 >
 >
 > 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”

Why bring state into this discussion. Stateful service is a confusing 
thing to bundle with endpoint reference concerns. What we are talking 
about here is a “thing” which I am calling “web service endpoint” for 
which needs these reference properties are needed for the web service at 
the destination to properly “dispatch” the action to. What does 
statefullness of a service have to do with flexible and scalable 
addressing capabilities?
 >
 > “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.
 >
 >
 >
 > [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
 >
Again: the use of the word “stateful” is not needed to explain this 
concept. Us a new formal term, such as “web service endpoint”.
 >
 >
 > 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 #2: Address only
 >
In this case the web service and the web service resource are the same 
“thing”, so reference properties are not used.
 >
 >
 > 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=123456789</wsa:Address>
 >
 > </wsa:EndpointReference>
 >
 > </wsa:ReplyTo>
 >
 > </s:Header>
 >
 >
 >
 > Service->Client Callback
 >
 >
 >
 > <S:Header>
 >
 > 
<wsa:To>http://www.fabrikam123.example/acct?(fabrikamns)CustomerKey=123456789</wsa:To>
 >
 > <fabrikam:CustomerKey>123456789</fabrikam:CustomerKey>
 >
 > </S:Header>
 >
 >
 >
 > 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.
 >
 >
 >
 > 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.
 >
 >
 >
 > 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.
 >
 >
 >
 > 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
 >
 >
 >
 >
 >
 > 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.
 >
 >
 >
 > 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.
 >
 >
 >
 > 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
 >
 >
 >
 >
 >
 >
 >
 >


-- 
----------------------------------------------------
Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744 Fax: +1 732 774 5133


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Monday, 15 November 2004 17:07:39 UTC