[gfs-wg] RNS Resolver clarifications

[Manuel Pereira]

Hello Peter,

Thank you for your feedback, you will find my comments below.

> I've been thinking about implementing the RNS Resolver port type defined
> in the RNS specification (if there already exists a reference
> implementation, please let me know). However, it appears to me as if the
> specification contains a few "gaps".

We currently have a reference implementation that we hope to release to
Globus soon.  Additionally, I am in the process of making binaries
available at www.alphaworks.ibm.com.  Having shared this with you, this
particular port type is relatively simple and multiple reference
implementations can prove to be a good thing; so I don't want to discourage
your efforts.

With regard to your comment on "gaps", I would expect a few discrepancies
as this draft is in its preliminary phase, however let me try to explain
our initial thinking on this matter (see below).

> In particular, the {delete,update}EndpointReference, and the
> updateLogicalReference operations all require the RNS Resolver to be able
> to compare EPRs for equality. For instance, on a deleteEndpointReference
> invokation the Resolver must find all logical references containing
> the particular EPR and remove its mapping from them.

By logical implication it is true that a delete and update operation
require some level of comparison to be able to perform the indicated task.
However, the equality operation is only with respect to the EPR, that is
the reference pointer, and not the endpoint.  For instance, WS-Names, as
proposed in the OGSA-Naming WG, are intended to facilitate equality
comparison (only) amongst EPRs by way of an "abstract name".  This
"abstract name" essentially provides a unique identity for any given
endpoint, and therefore when used within an EPR enables EPRs to be compared
on the basis of what they "point to" or "reference".  This is not what is
intended to be implied in the RNS spec for the resolver port type.
Although this particular port type has not been the focus of our work it
certainly provides a useful utility service that is necessarily
complimentary to the RNS namespace port type.

In short, the deleteEndpointReference() and updateEndpointReference()
operations do not mandate how EPRs are compared, yet does require that
equality is somehow determined.  The issue is, however, that the "EPR" is
compared on the basis of the "EPR" and not on the basis of "if two EPRs are
equal in the sense that they ultimately refer to the same thing."  It is
like comparing two C pointers (on the basis of their respective addresses)
versus comparing the value of what they are referencing (ie. ( a==b ) vs.
strcmp( a,b ) ).

> According to the WS-Addressing specification, it "provides no concept of
> endpoint identity and therefore does not provide any mechanism to
> determine equality or inequality of EPRs". A similar point is also made
in
> the RNS specification (page 25) which states that "... a single
> EPR or LogicalResolver cannot be deleted or updated, since they are not
> identified by any corresponding handle or name." Still, the RNS Resolver
> port type is supposed to provide support for that kind of behavior.

On the basis that the implementation is seeking to identify a particular
EPR (string) strictly on the basis of its stored value (not its referential
value), then it is not about "endpoint identity" but rather EPR identity.
You have raised a good question in that the RNS namespace port type does
not allow this type of manipulation, but it does remain consistent in that
neither port type attempt to attribute some identity handle to an EPR.  The
key difference is that the resolver port type must deal with deleting the
actual stored EPR values (strings) and manage binding relationships.

> Does this mean that the RNS Resolver specification leaves the EPR
equality
> decision to the implementation?

Ultimately the answer is yes, on the basis of the type of comparison
described above: pointer equality, not endpoint equality.

> I would also like some other clarifications:
>
> * Several RNS Resolver operations are said to "throw exceptions" when
>   they for some reason fail. Exactly what fault messages are they
>   supposed to return?

Thank you for bringing this to my attention, these assertions are obviously
incomplete.  I will address this clarification as soon as possible.

> * Another ambiguity: what are the deleteEndpointReference semantics in
>   case of failure? What if the deletion is successfull in, say, nine of
>   ten mappings, but fail on the tenth? Should deletion be atomic, or
>   should the fault message somehow indicate what mappings failed?

I should elaborate on this point as well.  Given that the
deleteEndpointReference operation only deals with one condition, namely if
the EPR being deleted is the only one associated with a logical name, there
really shouldn't be failure in unbinding strings.  I will provide more
description for this point as well.

Again, thank you for your time and comments.

Best regards,
Manuel Pereira
------------------------------------------------------
IBM Almaden Research Center
1-408-927-1935                 [Tieline: 457]
mpereira at us.ibm.com
------------------------------------------------------