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@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Frank Siebenlist Sent: Wednesday, June 01, 2005 8:55 PM To: ogsa-wg@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-minutes-20050524 /en/1

...

https://forge.gridforum.org/projects/ogsa-wg/document/f2f-minutes-20050523 /en/1

Thanks Mark and Andreas for your excellent minutes! ---- Hiro Kishimoto

-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory

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@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Andrew Grimshaw Sent: Friday, June 03, 2005 1:00 PM To: 'Frank Siebenlist'; ogsa-wg@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@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Frank Siebenlist Sent: Wednesday, June 01, 2005 8:55 PM To: ogsa-wg@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@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

Hi Ian, Frank, and Andrew, I think separate WS-RR spec can be a solution. It will give a bit of extra work to OGSA-naming WG but they will finish this very short spec in a short period. Thanks, ---- Hiro Kishimoto

-----Original Message----- From: Frank Siebenlist [mailto:franks@mcs.anl.gov] Sent: Saturday, June 04, 2005 3:24 PM To: Ian Foster Cc: Mark Morgan; 'Andrew Grimshaw'; ogsa-wg@ggf.org; 'Hiro Kishimoto' Subject: Re: Resilient References? (Re: [ogsa-wg] ogsa London f2f minutes uploaded)

+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@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Andrew Grimshaw Sent: Friday, June 03, 2005 1:00 PM To: 'Frank Siebenlist'; ogsa-wg@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@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Frank Siebenlist Sent: Wednesday, June 01, 2005 8:55 PM To: ogsa-wg@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@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@mcs.anl.gov The Globus Alliance - Argonne National Laboratory

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@ggf.org [mailto:owner-ogsa-wg@ggf.org] *On Behalf Of *Ian Foster *Sent:* Friday, June 03, 2005 11:32 PM *To:* Mark Morgan; 'Andrew Grimshaw'; 'Frank Siebenlist'; ogsa-wg@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@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Andrew Grimshaw Sent: Friday, June 03, 2005 1:00 PM To: 'Frank Siebenlist'; ogsa-wg@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@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Frank Siebenlist Sent: Wednesday, June 01, 2005 8:55 PM To: ogsa-wg@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@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@mcs.anl.gov The Globus Alliance - Argonne National Laboratory

Andrew Grimshaw wrote:

... 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.

<AG> Frank, this is not correct. The proposed WSNR works for BOTH stateless services as well as statefull webservice resources. Thus, WSNR works for a larger set of use cases. </AG>

Interesting, maybe I'm still missing something. It would be helpful if you and Mark could elaborate a little on the proposed scheme. when Mark writes: "...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..." Does this "optional" mean that the schema for the input message parameter of the resolve operation will have an optional "EPR"; it should either be empty or consist of a single EPR? If so, what does the "optional" mean for the implementors of that porttype/operation "EPR resolve( [EPR] )"? Does the service implementation have to cater for both options? Or can it just return an error for the one it doesn't implement? And then what does the "optional" mean for the client's processing? If the schema indicates that the client could either call the resolve operation with or without the original EPR, how does it know which option to choose? Should it just try the one it likes? Thanks, Frank. ---------------------------------------------------------------------------------

* 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.

<AG> Frank, the document could easily be split. Further, I think it is trivial - it is basically a use-pattern on WS-Addressing - that is all. The AbstractNames require NO specifications at all. </AG>

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@ggf.org [mailto:owner-ogsa-wg@ggf.org] *On Behalf Of *Ian Foster *Sent:* Friday, June 03, 2005 11:32 PM *To:* Mark Morgan; 'Andrew Grimshaw'; 'Frank Siebenlist'; ogsa-wg@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@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Andrew Grimshaw Sent: Friday, June 03, 2005 1:00 PM To: 'Frank Siebenlist'; ogsa-wg@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@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Frank Siebenlist Sent: Wednesday, June 01, 2005 8:55 PM To: ogsa-wg@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@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@mcs.anl.gov The Globus Alliance - Argonne National Laboratory

Hi folks, I have read the WS-Naming strawman and been trying to follow the discussion on resilient references on the list. Putting EPRs inside EPRs seems a bit strange to me - the following seems simpler (the obvious inspiration is tinyurl) ... <wsa:EndpointReference> <wsa:Address>mailto:mark.mckeown@manchester.ac.uk</wsa:Address> <ws-name:Handle>http://www.thegrid.com/a4dfg</ws-name:Handle> </wsa:EndpointReference> Where "Handle" is used as an identifier/name and is mandated to be a HTTP/S URI. To resolve the Handle a client does a HTTP GET on the URI to get a new EPR, (client gets 404 if resolution is not supported, 410 if the service/resource is gone/terminated). I can see a number of advantages to this: *) It is simple and easy to implement. *) The Cache-Control headers in HTTP can be used to pass on information to the client to indicate how long it can cache an EPR for - this is an optional optimization. *) If-Modified-Since HTTP header could be supported so a client will only retieve a new EPR if the one it has is stale - again an optional optimization. *) The "Handle" is easy to pass around between users - it can be pasted into a mail message and the reciever can use HTTP GET to retrieve the EPR. *) HTTPS can be used when trust is important. *) The service developer can make his EPRs "resilient" whenever he wants, ie he creates an EPR with a "Handle" but only later makes the "Handle" URI live. Effectively the low level HTTP protocol could be used to bootstrap the higher level SOAP protocol. Perhaps there are strong reasons why this approach was not considered? cheers Mark ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Mc Keown RSS Mark.McKeown@man.ac.uk Manchester Computing +44 161 275 0601 University of Manchester ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On Fri, 10 Jun 2005, Mark Morgan wrote:

...

when Mark writes: "...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..."

Does this "optional" mean that the schema for the input message parameter of the resolve operation will have an optional "EPR"; it should either be empty or consist of a single EPR?

Borrowing the pseudo syntax used in the "Web Services Base Notification 1.2 Working Draft 03, 21 June 2004" and replacing the given template for the NotificationMessage syntax with appropriate naming elements, what I mean is this:

<ogsa-naming:Resolve> <ogsa-naming:ResolutionMessage> <ogsa-naming:TargetEPRHint>? wsa:EndpointReference </ogsa-naming:TargetEPRHint> </ogsa-naming:ResolutionMessage> </ogsa-naming:Resolve>

...

If so, what does the "optional" mean for the implementors of that porttype/operation "EPR resolve( [EPR] )"? Does the service implementation have to cater for both options?

No, it doesn'. It can implement the empty parameter one, or both the empty parameter one and the one that takes an EPR as a parameter. See below for explanation.

...

Or can it just return an error for the one it doesn't implement?

No, this would not be correct I don't believe.

...

And then what does the "optional" mean for the client's processing? If the schema indicates that the client could either call the resolve operation with or without the original EPR, how does it know which option to choose? Should it just try the one it likes?

The important points to recall here are: 1) There are two EPRs involved in this communication conversation. One is the obvious one listed as an optional parameter. For clarity, let's call that parameter the "Hint EPR". The other EPR is the implicit one which would be indicated in the SOAP headers to which the communication is taking place. Let's call that EPR the "Resolver EPR". 2) The Resolver EPR is created with whatever information the implementor of the resolution services feels is appropriate. It's up to that service to generate an EPR with enough information to do the resolution. 3) The Hint EPR is just that -- a hint. It should not be considered the end all source of information for resolution.

What we imply by all of this is that a resolution service should be able to deal with a resolution message that does not include any EPR as a parameter by virtue of the fact that the Resolution EPR to which the resolution messages are addressed is created by that service with enough information to completely carry out the resolution. If an EPR is given as a parameter to that resolution service, the service MAY choose to use that hint to more efficiently resolve the endpoint in question, but is not required to do so. In otherwords, a resolution service implementor may choose to implement code that uses the optional EPR parameter if available, but MAY also choose to ignore it.

...

From the client perspective, it should be the case that the client may equally choose to send either an empty message (since this is guaranteed to work), or one with an EPR (since a service may choose to ignore this parameter). In this way the client is free to pick either one -- the parameterless one if it feels inclined to go with no hints, or the message with an EPR if the client feels like this extra hint may be useful.

So, in what cases would the EPR parameter be useful should the client decide to send it and should the service decide to use it? Well, in the general case, we have found that it is tremendously useful (bordering on necessary) sometimes for a client to indicate to a resolution service that that client has already tried to communicate with a given binding (EPR) and that the resolution service might want to go to extra efforts (i.e., instead of just looking the binding up in a cache or table) to determine whether or not a more suitable EPR exists.

-Mark

...

Thanks, Frank.

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@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Andrew Grimshaw Sent: Friday, June 03, 2005 1:00 PM To: 'Frank Siebenlist'; ogsa-wg@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@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Frank Siebenlist Sent: Wednesday, June 01, 2005 8:55 PM To: ogsa-wg@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@mcs.anl.gov The Globus Alliance - Argonne National Laboratory

-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory

Hi Frank, I am not so sure if we have enough reasons to prohibit a parameter for a resolution service. (1) In OGSI era, there is HandleResolver portType and findByHandle operation has a target parameter. (2) Does your design cover all WS-addressing scenarios other than WS-resource? Thanks, ---- Hiro Kishimoto

-----Original Message----- From: Frank Siebenlist [mailto:franks@mcs.anl.gov] Sent: Saturday, June 04, 2005 3:39 PM To: Frank Siebenlist Cc: Mark Morgan; 'Andrew Grimshaw'; ogsa-wg@ggf.org; 'Hiro Kishimoto' Subject: Re: Resilient References? (Re: [ogsa-wg] ogsa London f2f minutes uploaded)

Sorry, there was a confusing typo in my last email: s/different EPRs/different resources/

For clarity I just restate my corrected message here:

------

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 accommodate 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 names/EPRs pointing at different RESOURCES, while the RR is truly tied to a single "resource", then you have the right picture.

-Frank.

----------------------------------------------------

Frank Siebenlist wrote:

...

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@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Andrew Grimshaw Sent: Friday, June 03, 2005 1:00 PM To: 'Frank Siebenlist'; ogsa-wg@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@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Frank Siebenlist Sent: Wednesday, June 01, 2005 8:55 PM To: ogsa-wg@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@mcs.anl.gov The Globus Alliance - Argonne National Laboratory

-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory

Hi Frank, Thank you very much for your explanation. I think I get a picture now. You are proposing a resolve portType for Resilient Reference resource which has no parameter. On the other hand, Mark is proposing a portType for generic resolver which has a parameter as an option (as shown in Figure 2). Your usecases and OGSA WSRF BP 1.0 indicate the farmer is more reasonable. Here, another question comes to my mind: if an abstract name is rendered by EPR, could this abstract name have a resolve portType with no parameter? I am just considering symmetry of both EPRs. Talk to you on Monday at naming-WG-BoF call. ---- Hiro Kishimoto

-----Original Message----- From: Frank Siebenlist [mailto:franks@mcs.anl.gov] Sent: Sunday, June 05, 2005 8:11 AM To: Hiro Kishimoto Cc: 'Mark Morgan'; 'Andrew Grimshaw'; ogsa-wg@ggf.org Subject: Re: Resilient References? (Re: [ogsa-wg] ogsa London f2f minutes uploaded)

Sorry Hiro, there must be a misunderstanding as I certainly do not want to prohibit a parameter for a resolution service as that will cater to a different set of use cases.

The RR-EPR can only be used in those use cases where the EPR creator/minter knows where it will update the resource's EPR in the case of changes. This allows the EPR-minter to create a resource-specific RR-EPR that points at a state element behind a resolver service that will hold the application's EPR.

However, in those cases where the EPR is created without the knowledge where the updated EPR will be stored exactly, then a generic resolver has to be used that has to be passed something-from or the-whole EPR as a parameter.

As far as I can tell, most EPR creators will normally know that they will have to cater for EPR changes, will know the resolver service that they will use to maintain the updated EPR, will therefor be able to create a RR-EPR, and will therefor be able to hide from the consumers of the EPR what name, what naming scheme or what convention is used for the RR=>EPR resolution.

So by having a Resilient Reference spec, we should be able to cater for the great majority of use cases where resource reference stability is an issue.

-Frank.

PS. In the good old days when all was simple, we had OGSI, GSHs and GSRs and life was good ;-) Conceptually, a GSH is a "name", a GSR is an EPR, and OGSI was very GSH/name centric: you always had a GSH, if you were lucky you had a GSH and a GSR, if you were a little less lucky you had a GSH and a resolver-GSR, and if you were out of luck you just had a GSH. In other words, you always had the standardized "name" already and therefor the resolver could be a generic service that expected the name=GSH as a parameter; there was no need for a RR-GSR to hide the use of the name/naming-scheme/convention.

Hiro Kishimoto wrote:

...

Hi Frank,

I am not so sure if we have enough reasons to prohibit a parameter for a resolution service.

(1) In OGSI era, there is HandleResolver portType and findByHandle operation has a target parameter.

(2) Does your design cover all WS-addressing scenarios other than WS-resource?

Thanks, ---- Hiro Kishimoto

...

-----Original Message----- From: Frank Siebenlist [mailto:franks@mcs.anl.gov] Sent: Saturday, June 04, 2005 3:39 PM To: Frank Siebenlist Cc: Mark Morgan; 'Andrew Grimshaw'; ogsa-wg@ggf.org; 'Hiro Kishimoto' Subject: Re: Resilient References? (Re: [ogsa-wg] ogsa London f2f minutes uploaded)

Sorry, there was a confusing typo in my last email: s/different EPRs/different resources/

For clarity I just restate my corrected message here:

------

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 accommodate 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 names/EPRs pointing at different RESOURCES, while the RR is truly tied to a single "resource", then you have the right picture.

-Frank.

----------------------------------------------------

Frank Siebenlist wrote:

...

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@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Andrew Grimshaw Sent: Friday, June 03, 2005 1:00 PM To: 'Frank Siebenlist'; ogsa-wg@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@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Frank Siebenlist Sent: Wednesday, June 01, 2005 8:55 PM To: ogsa-wg@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@mcs.anl.gov The Globus Alliance - Argonne National Laboratory

-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory

-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory