Resilient References? (Re: [ogsa-wg] ogsa London f2f minutes uploaded)
Hiro Kishimoto
hiro.kishimoto at jp.fujitsu.com
Sat Jun 4 08:00:30 CDT 2005
Hi Ian, Frank, and Andrew,
I think separate WS-RR spec can be a solution.
It will give a bit of extra work to OGSA-naming WG
but they will finish this very short spec in a short
period.
Thanks,
----
Hiro Kishimoto
> -----Original Message-----
> From: Frank Siebenlist [mailto:franks at mcs.anl.gov]
> Sent: Saturday, June 04, 2005 3:24 PM
> To: Ian Foster
> Cc: Mark Morgan; 'Andrew Grimshaw'; ogsa-wg at ggf.org; 'Hiro Kishimoto'
> Subject: Re: Resilient References? (Re: [ogsa-wg] ogsa London f2f minutes
> uploaded)
>
> +1 for a separate WS-ResilientReference document.
>
> (...and unfortunately, I'll be somewhere across the Atlantic at the time
> of the telcon on Monday...)
>
> -Frank.
>
>
>
> Ian Foster wrote:
>
> > How about the following approach that seems to satisfy all issues
> > raised to date:
> >
> > ---> We produce a separate WS-ResilientReference document.
> >
> > This has the following advantages:
> >
> > * It is not part of OGSA WSRF Base Profile
> >
> > * it can be done very quickly (we have all of the text)
> >
> > * It is not tied up with the WS-Naming stuff, which I for one am not
> > to sure about in all of its details
> >
> > Votes for or against?
> >
> > Regards -- Ian.
> >
> > At 03:24 PM 6/3/2005 -0400, 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
> >> <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
> >> >
> >
> > _______________________________________________________________
> > Ian Foster www.mcs.anl.gov/~foster
> > <http://www.mcs.anl.gov/%7Efoster>
> > Math & Computer Science Div. Dept of Computer Science
> > Argonne National Laboratory The University of Chicago
> > Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A.
> > Tel: 630 252 4619 Fax: 630 252 1997
> > Globus Alliance, www.globus.org <http://www.globus.org/>
>
>
> --
> Frank Siebenlist franks at mcs.anl.gov
> The Globus Alliance - Argonne National Laboratory
More information about the ogsa-wg
mailing list