Resilient References? (Re: [ogsa-wg] ogsa London f2f minutes uploaded)
Frank Siebenlist
franks at mcs.anl.gov
Sat Jun 4 01:24:15 CDT 2005
+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