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

Mon Jun 6 09:45:44 CDT 2005

Sorry Andrew, but the following points were made in previous emails but
you have chosen to ignored them so far:

* the optional parameter doesn't work because your resolver and that RR
are different animals: the first one is a "service" and the second one
is a statefull webservice resource, and you should define a separate
porttype for each.

* by adding it it in the same spec, the RR becomes dependent on the
adoption of the whole ws-naming , which I do not see as anything trivial
no matter how much you try to trivialize it.

Both these argument were made before, it would be great if you could
address those concerns.

-Frank.

Andrew Grimshaw wrote:

> All,
>
> That is essentially what the existing WS-Naming work does. It has two
> separate components – a resolver component and an abstract naming
> component. The abstract naming component is extremely simple, an
> abstract name is optional, and is a string.
>
> Therefore, we already have a document written up (with all the XML) –
> in a proposed working group with a charter working its way through the
> system, why start a new thing for an essentially equivalent thing.
>
> Andrew
>
> * From: * owner-ogsa-wg at ggf.org [mailto:owner-ogsa-wg at ggf.org] *On
> Behalf Of *Ian Foster
> *Sent:* Friday, June 03, 2005 11:32 PM
> *To:* Mark Morgan; 'Andrew Grimshaw'; 'Frank Siebenlist'; ogsa-wg at ggf.org
> *Cc:* 'Hiro Kishimoto'
> *Subject:* RE: Resilient References? (Re: [ogsa-wg] ogsa London f2f
> minutes uploaded)
>
> 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