[gfs-wg] RNSResolver-related questions

[Peter Gardfjäll]

Manuel,

thanks for your reply. I have some further questions that you can find
below.

On Fri, 27 Jan 2006, Manuel Pereira wrote:

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

Ok, but still, how would the Delete change type element be used to
identify the particular EPR to be deleted from the logical reference (as
the Delete-component is only capable of carrying a QName)?

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

Could you describe what such a property extension mechanism would look
like in the RNSResolver case (which does not have WS-Resources and
resource property documents)?

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

Right, however my service container may contain several services and/or
WS-Resources - each of which is mapped by an individual logical reference.

The updateEndpointReference operation could be used to update the target
address of each logical reference to that of the relocated server, but
that would either require the restarted server to somehow know its
previous location, or for each service to fetch its previous target
address from the RNS resolver and then update it appropriately. I believe
that a more elegant model would be to allow a lifetime to be associated
with each mapping, hence allowing soft-state handling of the mappings. A
relocated server would then only need to add its new EPR, and its old
mapping would eventually be invalidated (once its lifetime expires).


regards, Peter