i001: EPRs as identifiers: update to EPR pros and cons by adding ref prop scenario

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

Two 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)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>

</S:Header>

 

Variation 2b: Simple Address

The Address may be significantly simpler, such as

 
<wsa:Address>http://www.fabrikam123.example/acct/123456789</wsa:Address>

 

Scenario #2: Reference Properties + Parameters

 

A transaction coordinator supports 3 possible interfaces.  Context
Management, such as CreateContext, is interface A.  There are 2
supported transaction protocols, interfaces B and C.  The typical
pattern of interaction is that a client uses interface A, and then one
of interface B or C, depending upon the type of protocol requested.
Operations are b in interface B and c in interface C.  For simplicity,
we will collapse the registration for a protocol step.  The interaction
pattern is:

1. Client sends CreateContext to A

2. A returns Context which contains EPR to register for context. 

3. Client invokes operation b or c from interface B or C to EPR. The
coordinator determines which interface is invoked based upon the EPR.
The interface invoked must match the requested protocol or a fault is
generated.

 

Variant #1: URI centric deployment

The context creation service, implemented with interface A, is deployed
at URI http://example.org/A. The transaction management services, that
implement interfaces B and C, are deployed at http://example.org/B and
http://example.org/C.   For comparison, we shall assume that the URIs
have a similar lifetime to the EPR with Reference Properties. 

 

EPRs looks like:

<wsa:EndpointReference>

 <wsa:Address>http://example.org/A</wsa:Address>

</wsa:EndpointReference>

 

<wsa:EndpointReference>

 <wsa:Address>http://example.org/B/tx:Id/1234</wsa:Address>

</wsa:EndpointReference>

 

<wsa:EndpointReference>

 <wsa:Address>http://example.org/C/tx:Id/5678</wsa:Address>

</wsa:EndpointReference>

 

Client issues request b or c to the EPR

 

Variant #2: Ref Property centric deployment.

Interface A, B, C are deployed at URI http://example.org/A.  The create
context returns an EPR with Reference Properties that identify the
interface, and Reference Parameters that identify the instance.

 

The EPRs are:

<wsa:EndpointReference>

 <wsa:Address>http://example.org/A</wsa:Address>

</wsa:EndpointReference>

 

<wsa:EndpointReference>

 <wsa:Address>http://example.org/A</wsa:Address>

 <wsa:ReferenceProperties>
  <m:Prop>PhaseZero</m:Prop>
 </wsa:ReferenceProperties>

 <wsa:ReferenceParameters>

   <tx:Id>1234</tx:Id>
 </wsa:ReferenceParameters>

</wsa:EndpointReference>

 

<wsa:EndpointReference>

 <wsa:Address>http://example.org/A</wsa:Address>

 <wsa:ReferenceProperties>
  <m:Prop>TwoPhase</m:Prop>
 </wsa:ReferenceProperties>

  <wsa:ReferenceParameters>

   <tx:Id>1234</tx:Id>
 </wsa:ReferenceParameters>

</wsa:EndpointReference>

 

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.

- I18N may be better served by XML structures than URI structures
because of flexibility in the XML encoding character sets.

 

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 enablesb 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)..  

 

 

Visibility

Advantage of EPRs

EPRs provide 2 different visibility points, URIs and soap headers.  It
may be advantageous to separate the visibility into 2 different types of
software.  Looking at the RefP scenarios, the scope of visibility may be
just a single URI for the transaction coordinator, and then there is
another layer of security that is transaction specific.  This is
embodied in the transaction software.  Providing two layers of security
and separating these into 2 different extension points may be simpler
and more appropriate than using a single extension point.  

 

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 higher visibility for URI-only software into the
message for any intermediary.

 

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.  

 

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 and there are pros
and cons to both styles.  As they have the choice with a Web of HTTP
URIs and HTTP Cookies today, WS-Addressing with ReferencePs 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