Resilient References? (Re: [ogsa-wg] ogsa London f2f minutes uploaded)
Frank Siebenlist
franks at mcs.anl.gov
Sat Jun 4 01:18:05 CDT 2005
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
More information about the ogsa-wg
mailing list