Resilient References? (Re: [ogsa-wg] ogsa London f2f minutes uploaded)

[Frank Siebenlist]

Wow - if I understand it well, then what you've described is essentially
the resilient reference functionality with an optional "hint-EPR".

If that's true, then I owe you a big apology for the misunderstanding on
my part.

Somehow I was convinced that the intended use of your "EPR resolve(EPR)"
was a generic resolution service where the passed EPR as the parameter
would hold the dispatching info to find the right slot where the
application's EPR was stored - it would be another way to hide the
name-knowledge inside of an EPR from the clients. It also implies that
you do not intend to support this use case as it requires the mandatory
passing of the EPR, which is now optional.

Ok - then if we would augment the resilient reference wording with your
"hint-EPR" explanation, we would have the finished spec for the
naming-less ws-naming spec!

Sorry again for my misunderstanding.
Regards, Frank.




Mark Morgan wrote:

>>when Mark writes: "...the general idea we have is to in fact 
>>possibly have a method who's signature is EPR resolve( [EPR] 
>>) Where the parameter EPR is optional..."
>>
>>Does this "optional" mean that the schema for the input 
>>message parameter of the resolve operation will have an 
>>optional "EPR"; it should either be empty or consist of a single EPR?
>>    
>>
>
>Borrowing the pseudo syntax used in the "Web Services Base Notification 1.2
>Working Draft 03, 21 June 2004" and replacing the given template for the
>NotificationMessage syntax with appropriate naming elements, what I mean is
>this:
>
>
>	<ogsa-naming:Resolve>
>		<ogsa-naming:ResolutionMessage>
>			<ogsa-naming:TargetEPRHint>?
>				wsa:EndpointReference
>			</ogsa-naming:TargetEPRHint>
>		</ogsa-naming:ResolutionMessage>
>	</ogsa-naming:Resolve>
>
>  
>
>>If so, what does the "optional" mean for the implementors of 
>>that porttype/operation "EPR resolve( [EPR] )"?
>>Does the service implementation have to cater for both options?
>>    
>>
>
>No, it doesn'.  It can implement the empty parameter one, or both the empty
>parameter one and the one that takes an EPR as a parameter.  See below for
>explanation.
>
>  
>
>>Or can it just return an error for the one it doesn't implement?
>>    
>>
>
>No, this would not be correct I don't believe.
>
>  
>
>>And then what does the "optional" mean for the client's processing?
>>If the schema indicates that the client could either call the 
>>resolve operation with or without the original EPR, how does 
>>it know which option to choose? Should it just try the one it likes?
>>    
>>
>
>The important points to recall here are:
>	1) There are two EPRs involved in this communication conversation.
>One is the obvious one listed as an optional parameter.  For clarity, let's
>call that parameter the "Hint EPR".  The other EPR is the implicit one which
>would be indicated in the SOAP headers to which the communication is taking
>place.  Let's call that EPR the "Resolver EPR".
>	2) The Resolver EPR is created with whatever information the
>implementor of the resolution services feels is appropriate.  It's up to
>that service to generate an EPR with enough information to do the
>resolution.
>	3) The Hint EPR is just that -- a hint.  It should not be considered
>the end all source of information for resolution.
>
>What we imply by all of this is that a resolution service should be able to
>deal with a resolution message that does not include any EPR as a parameter
>by virtue of the fact that the Resolution EPR to which the resolution
>messages are addressed is created by that service with enough information to
>completely carry out the resolution.  If an EPR is given as a parameter to
>that resolution service, the service MAY choose to use that hint to more
>efficiently resolve the endpoint in question, but is not required to do so.
>In otherwords, a resolution service implementor may choose to implement code
>that uses the optional EPR parameter if available, but MAY also choose to
>ignore it.
>
>From the client perspective, it should be the case that the client may
>equally choose to send either an empty message (since this is guaranteed to
>work), or one with an EPR (since a service may choose to ignore this
>parameter).  In this way the client is free to pick either one -- the
>parameterless one if it feels inclined to go with no hints, or the message
>with an EPR if the client feels like this extra hint may be useful.
>
>So, in what cases would the EPR parameter be useful should the client decide
>to send it and should the service decide to use it?  Well, in the general
>case, we have found that it is tremendously useful (bordering on necessary)
>sometimes for a client to indicate to a resolution service that that client
>has already tried to communicate with a given binding (EPR) and that the
>resolution service might want to go to extra efforts (i.e., instead of just
>looking the binding up in a cache or table) to determine whether or not a
>more suitable EPR exists.
>
>-Mark
>
>  
>
>>Thanks, Frank.
>>    
>>
>
>  
>

-- 
Frank Siebenlist               franks at mcs.anl.gov
The Globus Alliance - Argonne National Laboratory