[gfs-wg] RNSResolver-related questions

[Peter Gardfjäll]

Hello everybody,

I never received any replies on my questions regarding the somewhat
ambiguous semantics of the updateLogicalReference operation, as defined
in the RNS specification. Therefore, I will make another attempt and
re-post my previous questions (found below). In addition to my previous
questions I would also like to take the opportunity to ask some other
questions.

First, are there any guidelines regarding how to extend the "base
RNSResolver" (as described in the specification) with additional
capabilities?

In particular, I believe that it would be useful to be able to associate
additional properties with an individual name-to-address mapping (as
opposed to the entire LogicalReference). As a concrete example,
associating a time-to-live (TTL) property with a mapping could be useful
to, e.g., facilitate soft-state management of name-to-address mappings
and/or simplify the creation of client-side caching (and cache entry
invalidation) mechanisms. Consider a scenario where each name-to-address
mapping of a LogicalReference represents a replica service. A TTL would
be associated with each individual replica-address mapping (e.g.
allowing the RNSResolver implementation to remove a mapping belonging
to a replica that is no longer extending its TTL, and hence can be
considered unavailable).

I guess that the open nature of the ChangeInput element (which allows for
an unbounded set of changeProperty values) would facilitate such property
extensions, however in its current form it would be difficult to distiguish
what properties are targeted to the LogicalReference (such as the
"Description" element introduced in the spec) and what properties are
attributed to a particular name-to-address mapping.

Another useful capability would be support for batch update operations. As
I understand the current specification, it only supports batch updates
involving a single logical name (potentially mapping to several
addresses). However, a batch operation allowing several (1-N)
LogicalReferences to be added/updated in a single invocation would also
be useful. For example, consider the case where a relocated service
container is restarted on a new host and need to re-register a set of
LogicalReferences. In this case a batch operation could save several
RNSResolver invocations (and network roundtrips).

Finally, I wonder if the ChangeInput element, and in particular the
SetResourceProperties sub-element it contains, is a good match for
the RNSResolver porttype operations. Specifically, the Delete component
seems useless when it comes to removing EPRs, as it is only capable of
referencing QNames. And since the RNSResolver is not a WSRF-compliant
service the SetResourceProperties document does not make sense (at least
not in the WSRF sense) which only causes confusion regarding its semantics
in this case.

It would be highly appreciated if someone could elaborate on these issues.

Thanks, Peter

On Thu, 15 Dec 2005, Peter Gardfjäll wrote:

>
> Hello everybody,
>
> I would like some clarifications regarding the use of the
> updateLogicalReference operation of the RNSResolver porttype.
>
> According to the specification, the operation is intended to allow
> "the caller to update the description of the Logical Reference and
> add and/or remove associated EPRs."
>
> Furthermore, the specification states that the EndpointReference property
> value "MUST be embedded in the Update change type element" of the
> changeProperties element (a SetResourceProperties element as pictured
> below).
>
>   <wsrp:SetResourceProperties>
>     {
>       <wsrp:Insert >
>         {any}*
>       </wsrp:Insert> |
>       <wsrp:Update >
>         {any}*
>       </wsrp:Update> |
>       <wsrp:Delete ResourceProperty="QName" />
>     }+
>   </wsrp:SetResourceProperties>
>
> So, if your are only allowed to use the Update change type of the
> SetResourceProperties element, how would you distinguish an EPR add from
> an EPR delete operation?
>
> Furthermore, the specification is quite contradicting as it a few lines
> down goes on to state that:
>
> "The ChangeInput parameter is fully capable of inserting, updating, and
> deleting properties in a single message exchange via the changeProperties
> component. This means that an rns:EndpointReference value may be used for
> adding a new EPR while another rns:EndpointReference value is sent
> identifying an existing endpoint reference that should be de-referenced.
> Values MUST be represented by the appropriate change type: Insert, Update,
> or Delete."
>
> Still, if this is true, how would you represent an EPR delete using the
> Delete change type element (which only takes a QName and does not allow
> endpoint references to be specified)?
>
> A few examples covering the intended use of this operation would be very
> helpful.
>
> Cheers,
> Peter
>