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

Sat Jun 4 01:38:31 CDT 2005

Sorry, there was a confusing typo in my last email:
s/different EPRs/different resources/

For clarity I just restate my corrected message here:

------

The proposed "solution":

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

shows to me that we still do not understand what those RRs do or are.

An RR refers to a resolver service that doesn't expect an EPR as a
parameter and wouldn't even know what to do with it, while a resolver
that does expect an EPR as a parameter wouldn't know what to do if it
didn't receive one - there is completely different semantics associated
with the two use cases and overloading the interface to accommodate both
is poor design.

I'm sorry to bring some object-speak in here to make the point, but one
could see the analogy where an RR is an object-reference where a message
"resolve" will return a new reference, while the resolver-EPR is like a
class-reference with a class/static-function that needs an EPR/name to
return a reference. If you have the idea that you could reuse the
resolver-EPR to resolve many different names/EPRs pointing at different
RESOURCES, while the RR is truly tied to a single "resource", then you
have the right picture.

-Frank.

----------------------------------------------------

Frank Siebenlist wrote:

> The proposed "solution":
>
>> 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.
>>
>
> shows to me that we still do not understand what those RRs do or are.
>
> An RR refers to a resolver service that doesn't expect an EPR as a
> parameter and wouldn't even know what to do with it, while a resolver
> that does expect an EPR as a parameter wouldn't know what to do if it
> didn't receive one - there is completely different semantics associated
> with the two use cases and overloading the interface to accomodate both
> is poor design.
>
> I'm sorry to bring some object-speak in here to make the point, but one
> could see the analogy where an RR is an object-reference where a message
> "resolve" will return a new reference, while the resolver-epr is like a
> class-reference with a class/static-function that needs an epr/name to
> return a reference. If you have the idea that you could reuse the
> resolver-epr to resolve many different EPRs pointing at different EPRs,
> while the RR is truly tied to a single "resource", then you have the
> right picture.
>
> -Frank.
>
>
>
> Mark Morgan wrote:
>
>> The following secion is copied directly from the WSRF Base Profile
>> document
>> submitted to Grid Forge on 22 May 2005
>>
>> "
>> 3.1.2 Resilient Endpoint References
>>
>> WS-Addressing does not provide a normative mechanism for creating
>> resilient
>> endpoint references: i.e., an endpoint reference that can be
>> "renewed" from
>> some source when it becomes invalid. An OGSA service may require a
>> resilient
>> endpoint reference. To accomplish this, resiliency metadata MAY be
>> included
>> in an endpoint reference.
>>
>> R0305 An ENDPOINTREFERENCE MAY contain zero or more
>> ogsa-bp:resilientReference extensibility elements from the
>> http://www.ggf.org/namespaces/2005/03/OGSABasicProfile-1.0 namespace to
>> specify the endpoint reference for a reference resolution service.
>>
>> R0307 A reference resolution INSTANCE MUST support the ogsa-rns:Resolve
>> message exchange to allow for the re-resolution of the endpoint
>> reference.
>>
>> R0308 A CONSUMER of an endpoint reference that contains an
>> ogsa-bp:resilientReference extensibility element SHOULD send an
>> ogsa-rr:Resolve message exchange to the ogsa-bp:resilientReference in
>> response to a wsrf-rap:ResourceUnknownFault.
>> "
>>
>> This particular section refers to a message exchange defined inside
>> of the
>> RNS spec which coincidentally infact passes an abstract name as it's
>> parameter. However, a phone conversation with Tom Maguire informs me that
>> this is legacy text which wasn't updated due to the conversation in
>> London.
>> The intended result is to have a message exchange where the caller didn't
>> have to know about Abstract names. In essence, a message exchange
>> which was
>> empty as far as parameters go and for which all relevant information was
>> contained in reference properties/parameters.
>>
>> This section describes the resolution protocols that "would" have been in
>> place in the base profile had we not decided at the London face to face
>> meeting that it was unnecessary to do so given that the naming group
>> could
>> make a small modification and satisfy the requirements. To recap, the
>> discussion was that if Andrew and myself could come up with a resolution
>> protocol that worked with WS-Naming that satisfied the requirement of not
>> requiring an abstract name, then there was no reason to put it in the
>> Base
>> Profile.
>>
>> Here is technically some reasons why.
>>
>> First, if we look at the section described by the old Base Profile that I
>> pasted above, one can extrapolate a "possible" EPR and "possible" message
>> exchange for this particular form of resolution. Here is one way it might
>> look (note, I assume a particular version of WS-Addressing, but concepts
>> remain unchanged as versions of Addressing change):
>>
>> // Possible EPR
>> <wsa:SomeEPR>
>> <wsa:To>http://www.some.url/some-path/some-service</wsa:To>
>> <wsa:ReferenceParameters>
>> <SomeOpaqueData>...</SomeOpaqueData>
>> </wsa:ReferenceParameters>
>> <wsa:metadata>
>> <ogsa-bp:resilientReference
>> xmlns:ogsa-bp="http://www.ggf.org/namespaces/2005/03/OGSABasicProfile-1.0">
>>
>> <wsa:To>http://www.some-other.url/some-other-path/some-other-service</wsa:To
>>
>>
>> <wsa:ReferenceParameters>
>> <SomeOpaqueData>...</SomeOpaqueData>
>> </wsa:ReferenceParameters>
>> <wsa:metadata>
>> "etc...."
>> </wsa:metadata>
>> </ogsa-bp:resilientReference>
>> </wsa:metadata>
>> </wsa:SomeEPR>
>>
>> // Possible resolution message
>> <soap:Body>
>> <ogsa-bp:resolve
>> xmlns:ogsa-bp="http://www.ggf.org/namespaces/2005/03/OGSABasicProfile-1.0"/>
>> </soap:Body>
>>
>> Now, for the sake of discussion, I attach a handful of sections and
>> slides
>
> >from WS-Naming documents that are relevant:
>
>> "
>> The process for adding a resolver to an existing EPR is analogously
>> simple
>> to that of adding an Abstract Name. A new element called
>> ReferenceResolver
>> is added to the Endpoint Reference Type of any service endpoint which
>> supports the WS-Naming profile. This element is itself an Endpoint
>> Reference Type and can be as arbitrarily simple (Figure 3) or complex
>> (Figure 4) as desired.
>> "
>>
>> "
>> Figure 3:
>> <wsa:EndpointReference
>> xmlns:wsa="http://www.w3.org/2005/02/addressing"
>> xmlns:name="http://tempuri.org/">
>> <wsa:Address>http://tempuri.org/example</wsa:Address>
>> <wsa:Policies>
>>
>> <name:AbstractName>urn:guid:B94C4186-0923-4dbb-AD9C-39DFB8B54388</name:Abstr
>> actName>
>>
>> <name:ReferenceResolver>
>>
>> <wsa:Address>http://tempuri.org/resolver1</wsa:Address>
>> </name:ReferenceResolver>
>> </wsa:Policies>
>> </wsa:EndpointReference>
>> "
>>
>> "
>> Figure 4:
>> <wsa:EndpointReference
>> xmlns:wsa="http://www.w3.org/2005/02/addressing"
>> xmlns:name="http://tempuri.org/">
>> <wsa:Address>http://tempuri.org/example</wsa:Address>
>> <wsa:Policies>
>>
>> <name:AbstractName>urn:guid:B94C4186-0923-4dbb-AD9C-39DFB8B54388</name:Abstr
>> actName>
>>
>> <name:ReferenceResolver>
>>
>> <wsa:Address>http://tempuri.org/resolver1</wsa:Address>
>> <wsa:ReferenceParameters>
>> guid:8733111B-84FA-4da8-89FE-417932B3B92C
>> </wsa:ReferenceParameters>
>> <wsa:Policies>
>>
>> <name:AbstractName>urn:guid:55AD06F6-2F35-409a-9DCE-E5F304E557AA</name:Abstr
>> actName>
>> <name:ReferenceResolver>
>>
>> <wsa:Address>http://tempuri.org/resolve2</wsa:Address>
>> </name:ReferenceResolver>
>> </wsa:Policies>
>> </name:ReferenceResolver>
>> </wsa:Policies>
>> </wsa:EndpointReference>
>> "
>>
>> And finally, here are the two, "original" methods from the Naming
>> document:
>> EPR resolve(AbstractName)
>> EPR resolve(EPR)
>>
>> Based on the discussion and agreements reached in London, Andrew and
>> I were
>> to come up with resolution that didn't require a parameter. The
>> discussion
>> on this will happen at the next Naming telecon, but 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. If this were to be the case, a
>> possible message for resolution would be:
>>
>> // Possible resolution message
>> <soap:Body>
>> <ws-naming:resolve
>> xmlns:ws-naming="http://some-appropriate-namespace"/>
>> </soap:Body>
>>
>> First of all, if we look back at the original resolution message from the
>> base profile case, we see that there is absolutely nothing WSRF-like
>> about
>> it. That begs the question why such a thing would go into the WSRF Base
>> Profile. Putting it there nearly guarantees that any OGSA profile
>> will have
>> to redefine another resolution exchange that will look idential, but
>> which
>> will occur in different namespaces, thereby breaking a point of
>> interoperability that didn't have to be broken. By moving it into the
>> naming group, which exists outside of any profile, interoperability
>> is much
>> more likely and possible.
>>
>> Further, the only difference between the two messages that are in
>> this email
>> is the namespace -- clearly this would indicate that the naming group is
>> capable of satisfying all of the requirements that the profile has
>> technically. In fact, if you compare the corresponding pieces side by
>> side,
>> the only real difference between what is in the OGSA Base Profile,
>> and what
>> is in the naming group is that the naming group allows for a slightly
>> broader interpretation of the bits without requiring that broader
>> view. In
>> otherwords, everything in the base profile is a subset of naming as
>> already
>> written down in documents or proposed on email. Just as in the case with
>> the Base Profile stuff, the information in WS-Naming is optional to
>> implementors as well.
>>
>> A direct comparison of Base Profile Resolution and WS-Naming Resolution
>>
>> Base Profile Resolution WS-Naming Resolution
>> ----------------------- --------------------
>> * Any given EPR may have a * Exactly the same
>> piece of metadata which is
>> itself an EPR representing
>> a resolver service. Nothing
>> prevents this resolver EPR from
>> also having it's own resolver EPR
>> contained therein, and etc.
>> * The resolver service must implement a * The resolver service will
>> either
>> message exchange which effectively be required to implement a message
>> satisfies the function signature: excahnge for the
>> interface:
>> EPR resolve() EPR resolve( [EPR] )
>> or it will be
>> required to implement both:
>> EPR resolve(
>> [EPR] )
>> EPR resolve(
>> AbstractName )
>> or some set that
>> is functionally equivalent
>>
>> These are the two pieces of resolution in both cases and the seem pretty
>> much equivalent.
>>
>> -Mark
>>
>>
>>
>>> -----Original Message-----
>>> From: owner-ogsa-wg at ggf.org [mailto:owner-ogsa-wg at ggf.org] On
>>> Behalf Of Andrew Grimshaw
>>> Sent: Friday, June 03, 2005 1:00 PM
>>> To: 'Frank Siebenlist'; ogsa-wg at ggf.org
>>> Cc: 'Hiro Kishimoto'
>>> Subject: RE: Resilient References? (Re: [ogsa-wg] ogsa London
>>> f2f minutes uploaded)
>>>
>>> Frank et. Al.
>>> Let me begin by saying that I believe there are two basic
>>> arguments for keeping resolution out of the base profile and
>>> in WS-Naming (really the WS-Name Resolution component): 1)
>>> architectural cleanliness and politics, and 2) purely
>>> technical. Mark Morgan will address (2) in a subsequent email.
>>> I will address (1).
>>>
>>> Architectural cleanliness and politics.
>>> Let's take the architectural issue first.
>>>
>>> What we are taking about is naming and name resolution
>>> including rebinding of existing bindings. Here a binding is
>>> some sort of <address, way to identify the thing the binding
>>> is for> tuple. Multi-layer schemes for this are as old as
>>> Moses in distributed systems - and even in regular operating
>>> systems and programming languages (think swizzle).
>>>
>>> Now, suppose that we have a mechanism in WSRF-Base Profile
>>> for doing the rebinding as proposed, i.e,
>>> ogsa-bp:resilientReference
>>> ogsa-rns:Resolve
>>>
>>> Later, a different OGSA base profile, perhaps for WSI, comes
>>> along and they also need a resolution scheme. So we have
>>> another set of names/namespaces for doing EXACTLY the same thing.
>>>
>>> OR, a basic WS facility, endorsed by many major players,
>>> comes along that also does resolution ... and we yet another
>>> way of doing the same thing.
>>>
>>> It is, in my opinion, much better to do resolution ONCE,
>>> along with other naming and name resolution, and in such a
>>> way as to be completely INDEPENDENT of grid. Why independent
>>> of grid? Because we want a system that will be as ubiquitous
>>> as possible - and used for both "grid services" and more
>>> general "web services".
>>>
>>> Now to politics. If we assume for the moment that a) naming
>>> and binding has broader impact than just grids, and b) we are
>>> striving for wide-spread usage, then it is very important
>>> that all of the major vendors are willing to "buy in" to
>>> whatever scheme we come up with. The reality right now is
>>> that some vendors will not touch anything associated with
>>> WSRF. Yet your proposal will be in the WSRF-Base-Profile!
>>>
>>> As I mentioned earlier Mark will address some of the more
>>> technical issues.
>>> I'll steal some of his thunder and point out that the current
>>> proposal in WS-Naming clearly separates "naming" from
>>> "resolution". Indeed, once could resolve an EPR that does
>>> not contain an abstract name.
>>>
>>> Andrew
>>>
>>> Ps. Below I comment on some of your specific points, with
>>> <AG> .. </AG> tags.
>>>
>>> -----Original Message-----
>>> From: owner-ogsa-wg at ggf.org [mailto:owner-ogsa-wg at ggf.org] On
>>> Behalf Of Frank Siebenlist
>>> Sent: Wednesday, June 01, 2005 8:55 PM
>>> To: ogsa-wg at ggf.org
>>> Cc: Hiro Kishimoto
>>> Subject: Re: Resilient References? (Re: [ogsa-wg] ogsa London
>>> f2f minutes
>>> uploaded)
>>>
>>> Let me try to argue one more time about NOT including the
>>> resilient reference spec in the ws-naming.
>>>
>>> First of all, this resilient reference (RR) is not dependent
>>> on any naming scheme; not on any notion of what an identity
>>> is, may be or smells like: no name is "visible" to the
>>> consumer of the RR's EPR as all is hidden inside of that EPR.
>>>
>>> <AG> This is the case in the proposed WS-Naming scheme as
>>> well, the consumer does not have to look at the AbstractName
>>> if there is one - and indeed with the modifications based on
>>> Tom's feedback, there need not be an AbstractName at all. </AG>
>>>
>>> The interface has no input message parameter, is extremely
>>> simple and easy to implement - the code that would deal with
>>> those RRs would be fairly straightforward and would provide
>>> clients with that extra stability that will allow them to
>>> connect with those resources that may move, or may listen on
>>> other ports, or bound to a different protocol, whatever...
>>>
>>> <AG> Dito </AG>
>>>
>>>
>>> In other words, it is a thing or rare beauty and an
>>> abstraction you don't find often.
>>>
>>> <AG> Dito </AG>
>>>
>>> Now the cons of adding this to the ws-naming are:
>>>
>>> * all naming discussions that I've been part of get bugged
>>> down in religious discussions about what names are, what
>>> identities are, whether we need them, what their formats are
>>> or should be or should not be, whether we should use URIs or
>>> should not, how many naming levels we need, what interfaces
>>> we will have for resolutions and what parameters will be
>>> passed - none of this is trivial and it will take time for
>>> all to agree ... and it is very possible that not all will agree...
>>>
>>> <AG> First, as I said above AbstractNames and resolution are separate.
>>> Second, one of the nice things about AbstractNames is they
>>> are just strings.
>>> Interpretation is up to the generator of the names, they need
>>> no parsing.
>>> </AG>
>>>
>>> * ...and the most important thing is that there will also be
>>> the notion of "ws-naming" compliance that is needed for
>>> interoperability, which brings up another complicated
>>> discussion of what subset of ws-naming needs a MUST or a SHOULD...
>>>
>>> Note that the RRs are very useful stand-alone, without any of
>>> the additional naming features, bells and whistles.
>>> <AG> See my above comments on cleanliness and politics. </AG>
>>>
>>> So in order to keep the RRs save and allow for adoption of
>>> RRs, we would then need a ws-naming "level-0 compliance" that
>>> would allow implementers to adopt the RRs without the rest of
>>> ws-naming. Higher level compliances would then deal with the
>>> actual use of names, naming conventions and such.
>>>
>>> That last observation could also lead to a decision to split
>>> the charter of ws-naming in two. The first part would deal
>>> with RRs only and could most probably be decided quickly with
>>> a separate, very short spec, while the second part of the
>>> charter would deal with the more complicated matter that
>>> involves the visible names. I can imagine that MS would be
>>> very much in favor of such a pragmatic approach.
>>>
>>> -Frank.
>>>
>>> PS. Please note that I am very interested in ws-naming and
>>> truly hope that useful things will come out of it, but for
>>> the reasons stated I would like to save this little RR-gem
>>
>> >from unnecessary delays and adoption hurdles such that it
>>
>>> could actually be deployed.
>>>
>>>
>>> Frank Siebenlist wrote:
>>>
>>>
>>>
>>>> I've been reading the minutes and was wondering if anything
>>>>
>>>>
>>> was decided
>>>
>>>
>>>> about those Resilient References.
>>>>
>>>> Personally I hope it is still in the BP as it seems
>>>> independent/stays-clear of any of the naming issues.
>>>>
>>>> In other words, this seems low hanging fruit and moving it in the
>>>> naming profile could delay adoption (unless anyone can tell
>>>>
>>>>
>>> me that all
>>>
>>>
>>>> the naming will be resolved next week ;-) ).
>>>>
>>>> -Frank.
>>>>
>>>>
>>>>
>>>>
>>>> Hiro Kishimoto wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Hi all,
>>>>>
>>>>> Mark and Andreas upload F2F minutes to GridForge.
>>>>> Please have a look and approve them tomorrow.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> They are now online:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> https://forge.gridforum.org/projects/ogsa-wg/document/f2f-mi
>>>>>
>>>>>
>> nutes-2005
>>
>>
>>>>> 0524
>>>>>
>>>>>
>>> /en/1
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> https://forge.gridforum.org/projects/ogsa-wg/document/f2f-mi
>>>>>
>>>>>
>> nutes-2005
>>
>>
>>>>> 0523
>>>>>
>>>>>
>>> /en/1
>>>
>>>
>>>>> Thanks Mark and Andreas for your excellent minutes!
>>>>> ----
>>>>> Hiro Kishimoto
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>> --
>>> Frank Siebenlist franks at mcs.anl.gov
>>> The Globus Alliance - Argonne National Laboratory
>>>
>>>
>>>
>>
>>
>>
>

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