[gfs-wg] RNSResolver-related questions

[Manuel Pereira]

Hello Peter,

Let me apologize for the perceived lack of response.  However, I have 
double-checked and I must report that I did not receive the message that 
you speak of and included at the end of this message.

In any case, thank you for your comments and feedback, you will find my 
comments below.

Let's begin with your first set of questions:

> 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?

First, please keep in mind that the statement "This property value MUST be 
embedded in the Update change type element" only applies to the 
"Description" property of the LogicalReference.  Second, the "Description" 
property is a "Description of the LogicalReference" and not a description 
of the EndpointReference.  Thus the constraint on where this property may 
appear; since only a single description can be associated with a 
LogicalReference at a time, the specification precludes the use of 
"Insert" or "Delete" for this particular property.

As for an EPR add and an EPR delete within the "updateLogicalReference" 
operation, you have exposed a mistake in the document.  Thank you for 
catching that, it must have been the product of a copy and paste error. 
Again the statement "This property value MUST be embedded in the Update 
change type element" only applies to the "Description" property of the 
LogicalReference.  I will omit this statement from the EPR property 
description for this operation in the document.

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

I trust my explanation above resolves this point.

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

I certainly like this idea, however, as currently presented the RNS 
specification does not  suggest that the RNSResolver service is 
extendible.  The quality of extensibility specifically corresponds to the 
RNS namespace service.  Modifying the RNSResolver service specification to 
accommodate extensibility is certainly doable and should be considered as 
a future enhancement.

> 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 agree and like these ideas.

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

Actually in order to leverage ChangeInput in this way, the service would 
need to have a defined list of properties that may be "changed."  For 
instance, in the RNS port type, one can easily extend the properties 
document of a given resource by using the profile extension operations 
(insertProperty, etc) defined in the specification.  Once a property is 
defined, one can then use the ChangeInput message to manipulate defined 
resource properties.  Although a similar dynamic property extension 
mechanism is currently not defined for the RNSResolver port type, given 
necessary interest, it would be easy to add.

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

I agree that batch processing for bulk disparate operations is very 
attractive and promises efficiency in large scale systems.  Accomplishing 
this in a ?standard? way is another issue.  In as much as WSRF accommodate 
batch processing RNS does, and so it strives to maintain a standard and 
generic approach to the problem.

With regard to the example that you presented, it sounds like that could 
easily be resolved by using the updateEndpointReference operations. 
Logical references theoretically should not change even if physical 
locations, addresses, etc. change; in fact that is the principal purpose 
for using logical references.  Therefore, in this example you are really 
interested in changing the target address rather than the logical 
referencing and this can be accomplished using the updateEndpointReference 
operation which may potentially affect more than one logical reference 
since RNSResolver facilitates a many-to-many mapping between logical 
reference and EPR.

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

Please keep in mind that the ChangeInput message (or complexType) is 
defined by the RNS specification and is not bound to WSRF or directly 
associated with it.  The WSRF influence is seen only within the 
ChangeInput message, specifically by the ?changeProperties? element (which 
is a reference to wsrp:SetResourceProperties).

Your point remains an arguable point.  I could be persuaded either way; 
that is to say I could be persuaded to define a separate set of 
input/change messages to handle mutation of RNSResolver resources. 
However, I have not seen a substantiated argument for this, and it seems 
the intuition of consistency between services is more desirable.
-------------------

Thank you again for your comments and feedback!

Best regards,
Manuel Pereira
------------------------------------------------------
IBM Almaden Research Center
1-408-927-1935                 [Tieline: 457]
mpereira at us.ibm.com
------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/gfs-wg/attachments/20060127/0c8b61c7/attachment.htm