[gfs-wg] RNSResolver-related questions

Thu Feb 2 16:55:54 CST 2006

Hello Peter,

Please see my comments below.

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

My apologies.  First, let me say that although I am certain that a 
resolver service like the RNSResolver is essential to the base RNS 
namespace service, the RNSResolver port type and associated operations 
were not as extensively tested or documented as well.  This was primarily 
due to the perception that other resolver services would soon occupy this 
space, and since this was not the focus of RNS, it did not receive equal 
time and treatment.

As a result, I noticed that indeed the RNSResolver lacks a valid operation 
for dereferencing or ?unbinding? a single EPR from a list that may be 
associated with a logical reference.  To accommodate this properly, the 
udpateLogicalReference operation should include a conditional description 
similar to the RNS update() operation in section 1.4.2.5, wherein complete 
lists of EPRs may be handled in a single transaction or single EPRs may be 
added or ?inserted? ONLY.  This same logic is true for the 
udpateLogicalReference since both update and delete change types would 
require implicit identification of the EPR to be updated or deleted.  I 
will change the udpateLogicalReference operation to reflect this logic; 
thank you!

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

The RNSResolver port type does reflect an implicit resource properties 
document for the LogicalReference resource.  In other words, the 
LogicalReference entry may be manifest as a WS-Resource with properties 
that may be queried via standard WSRF operations.  So in this case, a 
property extension mechanism would simply enable additional properties to 
be defined and associated with the LogicalReference entry.  There are two 
properties currently associated with the LogicalReference resource, which 
are the ?Description? and ?EndpointReferenceList? properties.  Therefore, 
an extension mechanism would simply extend this list, for example by 
adding something like a ?LastModified? property.

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

I understand your position, this is still an issue.  As I mentioned in my 
last response, immediately before this quote, ?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.?

Bulk operations are more of a framework issue rather than something that 
can/should be handled per service.  The RNS specification does not address 
this issue.  Although it is certainly a valid concern and a real-world 
issue, the problem should be addressed at lower levels.

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

I may not completely understand your presented scenario, but let me try to 
reflect what I do understand about your example.  You may have multiple 
servers whose physical addresses are encapsulated in valid EPRs and are 
mapped to logical names with the RNSResolver.  These servers may change 
physical addresses and therefore require updated EPR values to update the 
resolver registry.  It sounds like the problem you mentioned in this last 
paragraph is that if the update EPR operation requires the value of the 
EPR in order to update/delete it, then the relocated server would have to 
know what its previous address/EPR value was before it could update the 
resolver registry with its new one, correct?  If this is close to 
accurate, then my recommendation would be: (1) to associate a single 
logical reference per server and (2) upon any change event on the server 
(physical address change, relocation, etc.) the server (perhaps during the 
boot/init process) would simply update the resolver mapping with its new 
information.  This approach ensure the most timely and accurate 
synchronization between logical and physical.  Keep in mind if each server 
is associated with a  corresponding logical reference, then the update 
process would be as simple as performing an updateLogicalReference() 
operation issuing the new EPR as the revised EndpointReferenceList; this 
would effectively unbind the reference to the deprecated EPR and rebind it 
to the new EPR in a single transaction, without requiring the knowledge of 
the previous EPR.

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/20060202/f7503c8b/attachment.html 