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

Sat Jun 4 08:44:39 CDT 2005

Hi Frank,

I am not so sure if we have enough reasons to prohibit a parameter 
for a resolution service.

(1) In OGSI era, there is HandleResolver portType and findByHandle
operation has a target parameter. 

(2) Does your design cover all WS-addressing scenarios other than
WS-resource?

Thanks,  
----
Hiro Kishimoto

> -----Original Message-----
> From: Frank Siebenlist [mailto:franks at mcs.anl.gov]
> Sent: Saturday, June 04, 2005 3:39 PM
> To: Frank Siebenlist
> Cc: Mark Morgan; 'Andrew Grimshaw'; ogsa-wg at ggf.org; 'Hiro Kishimoto'
> Subject: Re: Resilient References? (Re: [ogsa-wg] ogsa London f2f minutes
> uploaded)
> 
> 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