Resilient References? (Re: [ogsa-wg] ogsa London f2f minutes uploaded)
Ian Foster
foster at mcs.anl.gov
Fri Jun 3 22:32:10 CDT 2005
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"/>
></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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20050603/0c2cad6e/attachment.htm
More information about the ogsa-wg
mailing list