Resilient References? (Re: [ogsa-wg] ogsa London f2f minutes uploaded)
Mark Morgan
mmm2a at virginia.edu
Fri Jun 3 14:24:04 CDT 2005
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
>
More information about the ogsa-wg
mailing list