[gfs-wg] RNSResolver-related questions
Manuel Pereira
mpereira at almaden.ibm.com
Fri Jan 27 14:11:36 CST 2006
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
More information about the gfs-wg
mailing list