RE: Issue #1: Proposed text and resolution

Just a thought....For variation #2: Can we go with QName stuff as
follows? [used by javax.xml.namespace.QName]
 
 "{" + Namespace URI + "}" + local part. If the Namespace URI
.equals(""), drop the braces
 
thanks,
dims

 

 
  _____  

From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of David Orchard
Sent: Friday, November 05, 2004 2:28 PM
To: public-ws-addressing@w3.org
Subject: Issue #1: Proposed text and resolution



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.

 

[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 #2: Address only

 

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=1234
56789</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