[ogsa-wg] What's in a webservice-resource name...?

[Frank Siebenlist]

I would like to re-start a discussion about the naming of resources now that the resource reference properties have been ousted. 
(this ousting may be a blessing as it could simplify our naming as I will argue)

The following is a snippet from the latest ws-addressing draft:

------<snippet>--------
2.3 Endpoint Reference Comparison

During the course of Web services interactions applications may receive 
multiple endpoint references describing the endpoints it needs to 
interact with. Different copies of an endpoint reference may also be 
received over time.

The following rule clarifies the relation between the behaviors of the 
endpoints represented by two endpoint references with the same [address];
•
The two endpoints accept the same sets of messages, and follow and 
require the same set of policies. That is, the XML Schema, WSDL, and 
policy and other metadata applicable to the two references are the same.

However, the metadata embedded in each of the EPRs MAY differ, as the 
metadata carried by an EPR is not necessarily a complete statement of 
the metadata pertaining to the endpoint. Moreover, while embedded 
metadata is necessarily valid at the time the EPR is initially created 
it may become stale at a later point in time.

To deal with conflicts between the embedded metadata of two EPRs, or 
between embedded metadata and metadata obtained from a different source, 
or to ascertain the current validity of embedded metadata, mechanisms 
that are outside of the scope of this specification, such as EPR life 
cycle information [see 2.4 Endpoint Reference Lifecycle] or retrieval of 
metadata from an authoritative source, SHOULD be used.

The [address] properties of two endpoint references are compared 
according to Section 6 of [RFC 2396bis].

Therefore, a consuming application should assume that different XML 
Schemas, WSDL definitions and policies apply to endpoint references 
whose addresses differ.

2.4 Endpoint Reference Lifecycle

This specification does not define a lifecycle model for endpoint 
references and does not address the question of time-to-live for 
endpoint references. Other specifications that build on or use 
WS-Addressing may define a lifecycle model for endpoint references 
created according to that specification.

--------</snippet>------

It is almost as if lawyers wrote the statements above... or maybe it is an ill description of a Turing test that we can use to determine if two EPRs refer to the same webservice-resource... :-(

My layman and naive interpretation is that if the EPR's addresses of two EPRs are the same, then they refer to the same resource.

We essentially now have a "name" for our resource, which is the address' URI value, and if EPR-names are equal, then those names refer to the same webservice-resource.

I remember that we challenged the "uniqueness" property of the address before. (e.g. the use of ip-addresses inside an EPR-address, like 127.0.0.1 or 10.*.*.* would not make the EPR-address globally unique addresses).
However, in practice we must have a uniqueness property for the address within the "context of usage", otherwise we would be in real trouble. So, we could live within *our* 10.*.*.* domain happily and be guaranteed about the uniqueness of those ip-addresses. In other words, the real global uniqueness may not be a big deal in practice, and there are simple remedies like adding a uuid to the uri if needed.

If we have in addition a resolver-EPR that we can associate with an EPR through embedding (or through other means), then we essentially have introduced a mechanism that we could use for an additional naming-level scheme.

The Resolver-EPR is also an EPR, and will also have a name: its address' URI.
The Resolver-EPR's name will also uniquely refer to the same webservice-resource as the EPR it is associated with. In other words, the Resolver-EPR's name can be used as an alternative name for the webservice-resource.

We can use this to derive statements like: if two EPR have different names, but their associated resolver-EPRs have the same name, then those EPRs refer to the same webservice-resource.

It would allow a client to find out that different EPRs that use different mechanisms, like soap/http and soap/reliable-messaging, describe alternative ways to talk to the same webservice-resource

As the EPR's address can be "logical", we could use any naming scheme we want for a Resolver-EPR's address (as long as it's an URI), and could use human readable names, or application-domain specific names, or UUIDs.

In other words, by standardizing the usage convention of a resolver/stable/resilient/renewable-EPR, we have introduced a flexible naming mechanism for our webservice-resources.

It would also leave the use of different naming schemes open ... which could be considered a good thing.

Regards, Frank.

PS. I feel obliged to point out that there are serious trust issues associated with the binding of different names to the same webservice-resource...but that is orthogonal to the "naming" itself.


-- 
Frank Siebenlist        franks at mcs.anl.gov
The Globus Alliance - Argonne National Laboratory