Dave: My "proposal" was just a request that we have the "resolver EPR" in a separate specification. However, in a bit more detail, here are my opinions in this area: 1) The BES specification should just use EPRs, and not mandate the use of WS-Naming AbstractNames. Rationale: Such a requirement imposes a cost on BES users that they may not want to pay--for a benefit that they may not require. Mandating the use of WS-Naming names imposes an overhead in terms of both time (the cost of generating the AbstractName) and space (the storage that it requires). Yet: a) I may not need to perform the equivalence test that AbstractNames are introduced to allow. (E.g., I haven't thought deeply about this--but I can't recall that we've ever encountered that need.) b) I may need to perform an equivalence test, but not require the "globally unique in time and space" constraint that WS-Naming requires. [This constraint presumably constrains the form of the name that I can create, preventing me, for example, from using user-supplied strings.] c) I may need to perform an equivalence test, but want to do that at a different level: e.g., I may already maintain my own table of jobs for some other purpose, so the WS-Naming AbstractName just replicates unique data that I am already maintaining. If people WANT to pass around EPRs that have these AbstractNames in them (or other similar constructs with different constraints/semantics: e.g., "unique within my VO"), all power to them: but I don't see a reason to require this in BES or any other specification. 2) We should have a separate specification for the "resolver EPR" (and associated Resolver portType) and the "AbstractName" concept. Rationale: The "resolver" EPR is useful in a wide range of situations independent of the specific name syntax and semantics described in WS-Naming. I can imagine lots of places where I might use a resolver EPR. E.g., maybe in the BES case my jobs can migrate, and so I want the EPR that I get back to include a resolver EPR that I can use to determine its new location. But as noted above, I don't necessarily need an AbstractName in the BES case. Similarly for relocatable services: maybe I'll do a metadata query on a registry to get a service EPR (with a resolver EPR in it), then if the service is not where the registry says, contact the resolver to determine its new location. Again, I don't see that I will need AbstractName semantics here. Thus, given that we have two concepts that seem logically quite distinct, and that are certainly distinct in terms of when and how that will be used, I argue that they should be separated. 3) You also asked about three levels and about "human-oriented" vs. "abstract". These concepts are not in the WS-Naming spec, but for what it's worth, I don't see them as useful or relevant here. People use many sorts of "names" of different sorts, and they don't cleanly separate into three levels or into "human-oriented" or "abstract". E.g., if I'm implementing a replica location service, I often want to map first from a "logical file name" to a "site name" and then from there to a "physical location." Furthermore, if you build a system of this sort, you have to allow people to stick whatever names are convenient for them in at each level, because often these names come from elsewhere. Some users may make some of these names "human-oriented", others may not--it shouldn't matter to the service. Regards -- Ian. At 08:58 PM 8/30/2005 +0100, Dave Berry wrote:
Ian,
I wonder whether you or one of your team could write a note about the background to your proposals? It would help me to understand how they fit into the wider architecture. At present I don't feel able to make an informed contribution to the discussion.
The current shape of OGSA (if I can call it "current" without biasing the discussion) has three concepts relevant to this discussion:
1. Three levels of naming (human-oriented, abstract, and address). 2. An implementation of abstract names as an EPR containing a string and a resolver. 3. A service interface for BES that takes abstract names as parameters.
Each has associated questions raised by your concerns:
1. Do you want to have fewer levels of naming across the architecture or are you happy with the three listed here?
2a. Are you happy that abstract names should be represented in this way? 2b. What would a "resolver without an abstract name" resolve? When do you need it in addition to or instead of an abstract name? Does it fulfill a different function or is there some overlap?
3. What should the BES interface accept instead of or as well as abstract names? When do you need this functionality? How should the interface cope with the different types of entity?
I can make a guess at part of these answers but I'd rather read an explanation from the horse's mouth.
Best wishes,
Dave.
-----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Ian Foster Sent: 30 August 2005 04:02 To: Tom Maguire Cc: Andrew Grimshaw; ogsa-wg@ggf.org Subject: Re: [ogsa-wg] BES query
I'm interested in that question too. As I've said on quite a few occasions, I like the EPR + ResolverEPR (as in the original WS-RenewableReferences) -- that is a nice simple mechanism. I don't understand why we can't have this in a separate specification.
Ian.
So just to get some nomenclature correct. By WS-Names we mean an EPR that is profiled to contain both a ResolverEPR and an AbstractName. So what do we call an EPR which just contains a ResolverEPR?
Tom
Ian Foster wrote:
I believe that the opinion was expressed by some at the San Diego meeting (e.g., by Steve Tuecke) that WS-Names should NOT be mandated.
It certainly defines a nice way of using EPRs that will be useful in some situations. But it surely can't be the case that we always want to mandate this particular set of extensions to EPRs. That requirement certainly doesn't jibe with how we use them in all cases, for example.
Ian.
At 09:25 AM 8/29/2005 -0400, Andrew Grimshaw wrote:
All,
In the BES working group call last week the issue of naming came up. The current DRAFT specification calls for passing WS-Names in and out of
At 09:23 PM 8/29/2005 -0400, Tom Maguire wrote: the
various function calls. There was the question as to whether EPRs is all that should be specified. We thought this is an OGSA issue: mainly is
OGSA endorsing the use of WS-Names where appropriate. Clearly I think we should. But this should be discussed.
Andrew
_______________________________________________________________ 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/>
_______________________________________________________________ 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
_______________________________________________________________ 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
2-cents: It is my understanding that EPRs can't by themselves be guaranteed to be unique or that bit-wise comparisons are unreliable considering canonicalization and embedded metadata issues. If so, then a unique AbstractName is needed in order to accurately resolve EPRs, especially considering the potential service migration. Instead of mandating, perhaps the speficiations can recommended the use of WS-Naming? Specifications could still accept EPRs and implementations can check them for the presence of an AbstractName and take advantage of it if available (internal hash table, etc). Ian Foster wrote:
Dave:
My "proposal" was just a request that we have the "resolver EPR" in a separate specification.
However, in a bit more detail, here are my opinions in this area:
1) The BES specification should just use EPRs, and not mandate the use of WS-Naming AbstractNames.
Rationale: Such a requirement imposes a cost on BES users that they may not want to pay--for a benefit that they may not require.
Mandating the use of WS-Naming names imposes an overhead in terms of both time (the cost of generating the AbstractName) and space (the storage that it requires).
Yet:
a) I may not need to perform the equivalence test that AbstractNames are introduced to allow. (E.g., I haven't thought deeply about this--but I can't recall that we've ever encountered that need.)
b) I may need to perform an equivalence test, but not require the "globally unique in time and space" constraint that WS-Naming requires. [This constraint presumably constrains the form of the name that I can create, preventing me, for example, from using user-supplied strings.]
c) I may need to perform an equivalence test, but want to do that at a different level: e.g., I may already maintain my own table of jobs for some other purpose, so the WS-Naming AbstractName just replicates unique data that I am already maintaining.
If people WANT to pass around EPRs that have these AbstractNames in them (or other similar constructs with different constraints/semantics: e.g., "unique within my VO"), all power to them: but I don't see a reason to require this in BES or any other specification.
2) We should have a separate specification for the "resolver EPR" (and associated Resolver portType) and the "AbstractName" concept.
Rationale: The "resolver" EPR is useful in a wide range of situations independent of the specific name syntax and semantics described in WS-Naming.
I can imagine lots of places where I might use a resolver EPR. E.g., maybe in the BES case my jobs can migrate, and so I want the EPR that I get back to include a resolver EPR that I can use to determine its new location. But as noted above, I don't necessarily need an AbstractName in the BES case.
Similarly for relocatable services: maybe I'll do a metadata query on a registry to get a service EPR (with a resolver EPR in it), then if the service is not where the registry says, contact the resolver to determine its new location. Again, I don't see that I will need AbstractName semantics here.
Thus, given that we have two concepts that seem logically quite distinct, and that are certainly distinct in terms of when and how that will be used, I argue that they should be separated.
3) You also asked about three levels and about "human-oriented" vs. "abstract". These concepts are not in the WS-Naming spec, but for what it's worth, I don't see them as useful or relevant here. People use many sorts of "names" of different sorts, and they don't cleanly separate into three levels or into "human-oriented" or "abstract". E.g., if I'm implementing a replica location service, I often want to map first from a "logical file name" to a "site name" and then from there to a "physical location." Furthermore, if you build a system of this sort, you have to allow people to stick whatever names are convenient for them in at each level, because often these names come from elsewhere. Some users may make some of these names "human-oriented", others may not--it shouldn't matter to the service.
Regards -- Ian.
At 08:58 PM 8/30/2005 +0100, Dave Berry wrote:
Ian,
I wonder whether you or one of your team could write a note about the background to your proposals? It would help me to understand how they fit into the wider architecture. At present I don't feel able to make an informed contribution to the discussion.
The current shape of OGSA (if I can call it "current" without biasing the discussion) has three concepts relevant to this discussion:
1. Three levels of naming (human-oriented, abstract, and address). 2. An implementation of abstract names as an EPR containing a string and a resolver. 3. A service interface for BES that takes abstract names as parameters.
Each has associated questions raised by your concerns:
1. Do you want to have fewer levels of naming across the architecture or are you happy with the three listed here?
2a. Are you happy that abstract names should be represented in this way? 2b. What would a "resolver without an abstract name" resolve? When do you need it in addition to or instead of an abstract name? Does it fulfill a different function or is there some overlap?
3. What should the BES interface accept instead of or as well as abstract names? When do you need this functionality? How should the interface cope with the different types of entity?
I can make a guess at part of these answers but I'd rather read an explanation from the horse's mouth.
Best wishes,
Dave.
-----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Ian Foster Sent: 30 August 2005 04:02 To: Tom Maguire Cc: Andrew Grimshaw; ogsa-wg@ggf.org Subject: Re: [ogsa-wg] BES query
I'm interested in that question too. As I've said on quite a few occasions, I like the EPR + ResolverEPR (as in the original WS-RenewableReferences) -- that is a nice simple mechanism. I don't understand why we can't have this in a separate specification.
Ian.
So just to get some nomenclature correct. By WS-Names we mean an EPR that is profiled to contain both a ResolverEPR and an AbstractName. So what do we call an EPR which just contains a ResolverEPR?
Tom
Ian Foster wrote:
I believe that the opinion was expressed by some at the San Diego meeting (e.g., by Steve Tuecke) that WS-Names should NOT be mandated.
It certainly defines a nice way of using EPRs that will be useful in some situations. But it surely can't be the case that we always want to mandate this particular set of extensions to EPRs. That requirement certainly doesn't jibe with how we use them in all cases, for example.
Ian.
At 09:25 AM 8/29/2005 -0400, Andrew Grimshaw wrote:
All,
In the BES working group call last week the issue of naming came up. The current DRAFT specification calls for passing WS-Names in and out of
At 09:23 PM 8/29/2005 -0400, Tom Maguire wrote: the
various function calls. There was the question as to whether EPRs is all that should be specified. We thought this is an OGSA issue: mainly is
OGSA endorsing the use of WS-Names where appropriate. Clearly I think we should. But this should be discussed.
Andrew
_______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster <http://www.mcs.anl.gov/%7Efoster> <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/> <http://www.globus.org/>
_______________________________________________________________ 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/>
_______________________________________________________________ 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/>
-- Michael Behrens R2AD, LLC (571) 594-3008 (cell) *new* (703) 714-0442 (land)
On Aug 31, Michael Behrens modulated:
2-cents: It is my understanding that EPRs can't by themselves be guaranteed to be unique or that bit-wise comparisons are unreliable considering canonicalization and embedded metadata issues. If so, then a unique AbstractName is needed in order to accurately resolve EPRs, especially considering the potential service migration. Instead of mandating, perhaps the speficiations can recommended the use of WS-Naming? Specifications could still accept EPRs and implementations can check them for the presence of an AbstractName and take advantage of it if available (internal hash table, etc).
I have to admit, I may not entirely understanding the different viewpoints in this ongoing discussion (ongoing at least since OGSI was unveiled in Toronto?)... but, there are many separable aspects to these notions of uniqueness and naming, and I get the impression that there are at least two camps who prioritize these aspects in different ways. I want to emphasize that I am personally sitting on the fence, but trying to reinterpret what everyone is saying! I would love to see comments on whether I am fairly portraying the different positions here... The major aspects are: 1. whether a reference avoids aliasing for all time, e.g. it either addresses a specific service/resource identity or nothing at all 2. whether a stale reference can be renewed to address a specific service/resource identity after migration etc. 3. whether references can be compared for a remote service/resource identity predicate 4. whether references can be remotely mapped or projected to a unique AbstractName I hesitated to use the word "reference" but cannot think of a more neutral term right now. I think that all the camps feel that (1) should be mandated for the Grid. I think (less certainly) that everyone feels that (2) should be optional for the Grid. This is what was proposed in the "renewable reference" draft. This is, for example, an EPR containing a resolver EPR. The major point of division falls on (3) and (4): There is one camp who place a high priority on having a global one-to-one mapping of AbstractName to service/resource identity. Such identity must be tied up in the stateful semantics of the service/resource. The opposing camp continues to argue two things: 1) that this is not really very important, and 2) that perhaps it is even misleading or impossible to have one universal notion of identity across different application domains, communities, or implementation technologies. The other major camp places a high priority on implementor and application freedom to use different reference formats. It considers that references always exist in some implicit relational model (maintained by applications, communities, etc.) where interesting or important identity attributes are maintained. As such, the references themselves do not need to express identity for interop. I note that there is an underlying clash in "worldviews" here between the camps. One camp considers AbstractName to be central to architecture with other reference/addressing data to be secondary implementation requirements---the reference/address data is to be resolved, refreshed, or discarded at will. The other camp considers reference/addressing data to be central to architecture with AbstractName or other identifying attributes to be secondary, domain-specific associations that might apply in one community or another. What I am struggling to answer for myself is: is there a sensible third camp that puts these two views on equal (neutral) footing, or do we have to adopt one view to make standards for interoperability? karl -- Karl Czajkowski karlcz@univa.com
owner-ogsa-wg@ggf.org wrote on 08/31/2005 01:32:59 AM:
On Aug 31, Michael Behrens modulated:
The major aspects are:
1. whether a reference avoids aliasing for all time, e.g. it either addresses a specific service/resource identity or nothing at all
2. whether a stale reference can be renewed to address a specific service/resource identity after migration etc.
3. whether references can be compared for a remote service/resource identity predicate
4. whether references can be remotely mapped or projected to a unique AbstractName
I hesitated to use the word "reference" but cannot think of a more neutral term right now.
I think that all the camps feel that (1) should be mandated for the Grid.
I think (less certainly) that everyone feels that (2) should be optional for the Grid. This is what was proposed in the "renewable reference" draft. This is, for example, an EPR containing a resolver EPR.
I agree that (1) and (2) as stated are generally agreed upon as necessary traits. What I am less certain about is the likelihood that WS-Naming (as a profile) will address (2). If not, then I believe we need another profile that would address this need. In fact this is where we started with OGSA Basic Profile (BP). The "renewable" requirements were redacted from the BP after several discussions with the WS-Naming WG.
The major point of division falls on (3) and (4):
There is one camp who place a high priority on having a global one-to-one mapping of AbstractName to service/resource identity. Such identity must be tied up in the stateful semantics of the service/resource. The opposing camp continues to argue two things: 1) that this is not really very important, and 2) that perhaps it is even misleading or impossible to have one universal notion of identity across different application domains, communities, or implementation technologies.
I guess I am in the opposing camp :-).
The other major camp places a high priority on implementer and application freedom to use different reference formats. It considers that references always exist in some implicit relational model (maintained by applications, communities, etc.) where interesting or important identity attributes are maintained. As such, the references themselves do not need to express identity for interop.
Yes, Distributed Computing 101. If you authoritatively want to test if two things are the same you MUST ask the things. Placing the identity in the reference is an "interesting" optimization technique. The real difficulty for me (and implementers) is the "universal" context in which these identities live. One of the reasons that hierarchical namespace lookups exist is because they are capable of massively scaling. Logically flat identity spaces do not scale. There may be ways of making AbstractNames scale but I am not suitably well versed to understand how.
I note that there is an underlying clash in "worldviews" here between the camps. One camp considers AbstractName to be central to architecture with other reference/addressing data to be secondary implementation requirements---the reference/address data is to be resolved, refreshed, or discarded at will. The other camp considers reference/addressing data to be central to architecture with AbstractName or other identifying attributes to be secondary, domain-specific associations that might apply in one community or another.
What I am struggling to answer for myself is: is there a sensible third camp that puts these two views on equal (neutral) footing, or do we have to adopt one view to make standards for interoperability?
Perhaps but I am not clear on how you would do this.....
karl
-- Karl Czajkowski karlcz@univa.com
Tom Maguire wrote:
owner-ogsa-wg@ggf.org wrote on 08/31/2005 01:32:59 AM:
The other major camp places a high priority on implementer and application freedom to use different reference formats. It considers that references always exist in some implicit relational model (maintained by applications, communities, etc.) where interesting or important identity attributes are maintained. As such, the references themselves do not need to express identity for interop.
Yes, Distributed Computing 101. If you authoritatively want to test if two things are the same you MUST ask the things. Placing the identity in the reference is an "interesting" optimization technique. The real difficulty for me (and implementers) is the "universal" context in which these identities live. One of the reasons that hierarchical namespace lookups exist is because they are capable of massively scaling. Logically flat identity spaces do not scale. There may be ways of making AbstractNames scale but I am not suitably well versed to understand how.
1. WSDM has a ResourceId (case?) property that is required to be unique. If you do a WSDM-compliant endpoint then anything can ask for the resource and all is well. 2. Having just submitted something to the editor, I am reluctant to keep chasing the moving targets that are the OGSA set of requirements. You cannot keep adding more and more unstable specifications to the requirement list if you ever want to see a working implementation ship. I actually had a lot of fun in the CDDLM trying to deal with the problem of fault tolerance (=different EPRs for things), and resource lifetime (=operations to delete resources at the end of the wire), and to address things consistently. The original WS-* specification (and functional implementation) used simple unique IDs to identify things. You pass the UID down to the endpoints with your requests, you got answers back. There was no need to have uniqe EPRs; any endpoint that acted as a portal to the set of nodes you were deploying onto should be able to handle requests related to the UID. Its only once you add the notion of state-as-described-by-a-remote-reference into the equation that suddenly we are left with the problem that that you cant do fault tolerance in a resolvable address without extra magic in the system. Maybe this is a good argument for not using URLs/WS-A addresses in this way. -Steve
owner-ogsa-wg@ggf.org wrote on 09/05/2005 01:10:24 PM:
Tom Maguire wrote:
owner-ogsa-wg@ggf.org wrote on 08/31/2005 01:32:59 AM:
The other major camp places a high priority on implementer and application freedom to use different reference formats. It considers that references always exist in some implicit relational model (maintained by applications, communities, etc.) where interesting or important identity attributes are maintained. As such, the references themselves do not need to express identity for interop.
Yes, Distributed Computing 101. If you authoritatively want to test if two things are the same you MUST ask the things. Placing the identity in the reference is an "interesting" optimization technique. The real difficulty for me (and implementers) is the "universal" context in which these identities live. One of the reasons that hierarchical namespace lookups exist is because they are capable of massively scaling. Logically flat identity spaces do not scale. There may be ways of making AbstractNames scale but I am not suitably well versed to understand how.
1. WSDM has a ResourceId (case?) property that is required to be unique. If you do a WSDM-compliant endpoint then anything can ask for the resource and all is well.
Yes, WSDM has a ResourceId property. There is little guidance on how to create the ID for a resource. Still less is said about what happens when multiple endpoints are available for a given resource. And if a ResourceId is identical then you know something; if they are different you don't know much. This is why coorelatable properties where introduced into the model. To allow a client to interogate multilple properties that allow for coorelation of differing endpoints to the same resource.
2. Having just submitted something to the editor, I am reluctant to keep chasing the moving targets that are the OGSA set of requirements. You cannot keep adding more and more unstable specifications to the requirement list if you ever want to see a working implementation ship.
So I understand your point but the question is "Does OGSA need an interoperable way to specify AbstractNames (read identity)"? I am fairly confident that AbstractNames/Identity has been an OGSA requirement for quite some time. Granted the latest incarnation is still unstable. The intent is to have composable specifications. To that end I think I am in the camp that say use WS-Addressing and keep moving. Any client that expects an EPR should continue to work even after WS-Naming is introduced.
I actually had a lot of fun in the CDDLM trying to deal with the problem of fault tolerance (=different EPRs for things), and resource lifetime (=operations to delete resources at the end of the wire), and to address things consistently. The original WS-* specification (and functional implementation) used simple unique IDs to identify things. You pass the UID down to the endpoints with your requests, you got answers back. There was no need to have uniqe EPRs; any endpoint that acted as a portal to the set of nodes you were deploying onto should be able to handle requests related to the UID.
Its only once you add the notion of state-as-described-by-a-remote-reference into the equation that suddenly we are left with the problem that that you cant do fault tolerance in a resolvable address without extra magic in the system. Maybe this is a good argument for not using URLs/WS-A addresses in this way.
I disagree with this statement. If what you mean is that by having a separation of a UID and an endpoint that this magically gives you some better ability to be fault tolerant. I don't see it. This model just pushes the fault tolerance out of the architecture and into the lap of the clients. Tom
Tom Maguire wrote:
owner-ogsa-wg@ggf.org wrote on 09/05/2005 01:10:24 PM:
Tom Maguire wrote:
owner-ogsa-wg@ggf.org wrote on 08/31/2005 01:32:59 AM:
The other major camp places a high priority on implementer and application freedom to use different reference formats. It considers that references always exist in some implicit relational model (maintained by applications, communities, etc.) where interesting or important identity attributes are maintained. As such, the references themselves do not need to express identity for interop.
Yes, Distributed Computing 101. If you authoritatively want to test if two things are the same you MUST ask the things. Placing the identity in the reference is an "interesting" optimization technique. The real difficulty for me (and implementers) is the "universal" context in which these identities live. One of the reasons that hierarchical namespace lookups exist is because they are capable of massively scaling. Logically flat identity spaces do not scale. There may be ways of making AbstractNames scale but I am not suitably well versed to understand how.
1. WSDM has a ResourceId (case?) property that is required to be unique. If you do a WSDM-compliant endpoint then anything can ask for the resource and all is well.
Yes, WSDM has a ResourceId property. There is little guidance on how to create the ID for a resource. Still less is said about what happens when multiple endpoints are available for a given resource. And if a ResourceId is identical then you know something; if they are different you don't know much. This is why coorelatable properties where introduced into the model. To allow a client to interogate multilple properties that allow for coorelation of differing endpoints to the same resource.
maybe, but by putting identity information into the metadata of an address, we would be ignoring the bit of the WS-A spec that says "while embedded metadata is necessarily valid at the time the EPR is initially created it may become stale at a later point in time." The nice thing about interrogating things at the far end for identity is you are interrogating them there and then, not some time previously and hoping that things havent changed. Furthermore, if there is uncertainty about the semantics of WSDM resourceids, then that uncertainty must be clarified. It would seem superfluous just to add more stuff just because we havent nailed down the notion of WSDM identity. Which, I believe must implicity refers to the resource, not to the address you use to access it, because of course it is the resource that responds to the request.
2. Having just submitted something to the editor, I am reluctant to keep chasing the moving targets that are the OGSA set of requirements. You cannot keep adding more and more unstable specifications to the requirement list if you ever want to see a working implementation ship.
So I understand your point but the question is "Does OGSA need an interoperable way to specify AbstractNames (read identity)"? I am fairly confident that AbstractNames/Identity has been an OGSA requirement for quite some time. Granted the latest incarnation is still unstable. The intent is to have composable specifications. To that end I think I am in the camp that say use WS-Addressing and keep moving. Any client that expects an EPR should continue to work even after WS-Naming is introduced
fine
I actually had a lot of fun in the CDDLM trying to deal with the problem of fault tolerance (=different EPRs for things), and resource lifetime (=operations to delete resources at the end of the wire), and to address things consistently. The original WS-* specification (and functional implementation) used simple unique IDs to identify things. You pass the UID down to the endpoints with your requests, you got answers back. There was no need to have uniqe EPRs; any endpoint that acted as a portal to the set of nodes you were deploying onto should be able to handle requests related to the UID.
Its only once you add the notion of state-as-described-by-a-remote-reference into the equation that suddenly we are left with the problem that that you cant do fault tolerance in a resolvable address without extra magic in the system. Maybe this is a good argument for not using URLs/WS-A addresses in this way.
I disagree with this statement. If what you mean is that by having a separation of a UID and an endpoint that this magically gives you some better ability to be fault tolerant. I don't see it. This model just pushes the fault tolerance out of the architecture and into the lap of the clients.
fault tolerance is always pushed out to the clients. 1. Take a URL that never, ever fails - http//www.amazon.com/ 2. write an app that hits it every 15 seconds, halting with a timestamp when the fetch fails. 3. Put that app on your laptop, start it running, and leave it running as you move around from LAN to WLAN, net to VPN, home to work to travel. 4. check if the application is still running, and if not, how long it survived.
Tom, Keep in mind that this is email and tone is not carried well. You state below that " Yes, Distributed Computing 101. If you authoritatively want to test if two things are the same you MUST ask the things. Placing the identity in the reference is an "interesting" optimization technique. The real difficulty for me (and implementers) is the "universal" context in which these identities live. One of the reasons that hierarchical namespace lookups exist is because they are capable of massively scaling. Logically flat identity spaces do not scale. There may be ways of making AbstractNames scale but I am not suitably well versed to understand how." So actually I have taught (and been taught) "Distributed Systems 101". :-) It is not the case that you MUST ask the things if they are the same. That is the lesson of the strength of good naming systems. If the minter of the names ASSERTS that if the two strings are the same - they are the same, then you don't have to go to the service itself. (With respect to the spoofing problem, see my mail to Karl a few minutes ago.) Systems such as Amoeba (Tannenbaum), Globe (), Clouds, and others have this property. Going back to the first ACM workshop on Distributed Systems in Tromso (1988, Sape Mullender), and in particular to the short exposition by Roger Needham in the Second ACM Workshop on Distributed System, pp 312-327, the use of abstract names (called pure names by Needham) to be able to determine if the endpoint is the same endpoint has been used. There are issues of alias', and one to many bindings of course, but the key concept is that the client does not need to be aware of those usually. So to me it is more than an optimization technique. As to the scaling - there are many ways to scale "flat" names spaces. Keep in mind that a hierarchical name space can be represented in a flat name space - and vice versa (with no loops - i.e., DAGS). As an aside I want to re-iterate that I am not proposing that WS-Names be mandatory for all OGSA interactions - only that they be used were appropriate - i.e., were one can reasonably assume that clients may need to be able to know if to endpoints are the same. I would argue that BES fits this description. Andrew -----Original Message----- From: Tom Maguire [mailto:tmaguire@us.ibm.com] Sent: Wednesday, August 31, 2005 9:51 AM To: Karl Czajkowski Cc: Michael Behrens; Dave Berry; Ian Foster; Andrew Grimshaw; ogsa-wg@ggf.org; owner-ogsa-wg@ggf.org; Tom Maguire Subject: Re: [ogsa-wg] BES query owner-ogsa-wg@ggf.org wrote on 08/31/2005 01:32:59 AM:
On Aug 31, Michael Behrens modulated:
The major aspects are:
1. whether a reference avoids aliasing for all time, e.g. it either addresses a specific service/resource identity or nothing at all
2. whether a stale reference can be renewed to address a specific service/resource identity after migration etc.
3. whether references can be compared for a remote service/resource identity predicate
4. whether references can be remotely mapped or projected to a unique AbstractName
I hesitated to use the word "reference" but cannot think of a more neutral term right now.
I think that all the camps feel that (1) should be mandated for the Grid.
I think (less certainly) that everyone feels that (2) should be optional for the Grid. This is what was proposed in the "renewable reference" draft. This is, for example, an EPR containing a resolver EPR.
I agree that (1) and (2) as stated are generally agreed upon as necessary traits. What I am less certain about is the likelihood that WS-Naming (as a profile) will address (2). If not, then I believe we need another profile that would address this need. In fact this is where we started with OGSA Basic Profile (BP). The "renewable" requirements were redacted from the BP after several discussions with the WS-Naming WG.
The major point of division falls on (3) and (4):
There is one camp who place a high priority on having a global one-to-one mapping of AbstractName to service/resource identity. Such identity must be tied up in the stateful semantics of the service/resource. The opposing camp continues to argue two things: 1) that this is not really very important, and 2) that perhaps it is even misleading or impossible to have one universal notion of identity across different application domains, communities, or implementation technologies.
I guess I am in the opposing camp :-).
The other major camp places a high priority on implementer and application freedom to use different reference formats. It considers that references always exist in some implicit relational model (maintained by applications, communities, etc.) where interesting or important identity attributes are maintained. As such, the references themselves do not need to express identity for interop.
Yes, Distributed Computing 101. If you authoritatively want to test if two things are the same you MUST ask the things. Placing the identity in the reference is an "interesting" optimization technique. The real difficulty for me (and implementers) is the "universal" context in which these identities live. One of the reasons that hierarchical namespace lookups exist is because they are capable of massively scaling. Logically flat identity spaces do not scale. There may be ways of making AbstractNames scale but I am not suitably well versed to understand how.
I note that there is an underlying clash in "worldviews" here between the camps. One camp considers AbstractName to be central to architecture with other reference/addressing data to be secondary implementation requirements---the reference/address data is to be resolved, refreshed, or discarded at will. The other camp considers reference/addressing data to be central to architecture with AbstractName or other identifying attributes to be secondary, domain-specific associations that might apply in one community or another.
What I am struggling to answer for myself is: is there a sensible third camp that puts these two views on equal (neutral) footing, or do we have to adopt one view to make standards for interoperability?
Perhaps but I am not clear on how you would do this.....
karl
-- Karl Czajkowski karlcz@univa.com
On Sep 15, Andrew Grimshaw modulated: ...
As an aside I want to re-iterate that I am not proposing that WS-Names be mandatory for all OGSA interactions - only that they be used were appropriate - i.e., were one can reasonably assume that clients may need to be able to know if to endpoints are the same. I would argue that BES fits this description.
Andrew
Thanks, Andrew. This seems a good stepping point to raise the "architectural" issue that came up on a prior BES call and I think (?) precipitated this discussion. I have no real issues w/ the idea of abstract names, although I do think some of the details raised by Frank are interesting. E.g. should "abstract name" be a syntax in EPRs or actually more of a design pattern that could be encoded through a number of different EPR extensions. In some sense, all that matters is that a client can recognize that an EPR uses *any* of the "key" encodings that it understands, at which point comparison is possible. This seems to be no more or less onerous than having to handle extensible ("arbitrary") content inside an AbstractName element. What concerns me is the continued polarity on the whole concept of the abstract name pattern. My worry is that abstract naming is a poison pill that will hurt adoption of BES. I disagree only with the importance you place on abstract naming for job management... I agree it can be a nice convenience. I know from experience w/ WS-GRAM that we can do job management without abstract names, by leaving identity tracking to the client(s) of the service. Basically, we just store and forward whole EPRs. At the same time, our GT4 WSRF implementation does embed resource identity in the EPR and we could trivially copy it into an AbstractName field or use a method like Frank advocates to just highlight, "hey, feel free to compare such and such in this EPR." The only place, to my knowledge, that we currently looks inside EPRs is actually in a vile hack to mint them from partial addressing parameters to our command-line tool... a hack I am certainly not advocating for interop. :-) karl -- Karl Czajkowski karlcz@univa.com
owner-ogsa-wg@ggf.org wrote on 08/31/2005 12:11:00 AM:
2-cents: It is my understanding that EPRs can't by themselves be guaranteed to be unique or that bit-wise comparisons are unreliable considering canonicalization and embedded metadata issues.
That is correct
If so, then a unique AbstractName is needed in order to accurately resolve EPRs, especially considering the potential service migration.
I think that AbstractName is certainly one approach to solving this problem. Remember that ReferenceParameters are used to provide information to the RECEIVER(wsa:to) to disambiguate the resource for dispatch. Obviously, in order for the refParams to be useful they should be unique (in some context). The wsa:to provides the context in this case. I can envision lots of service migration scenarios that could take advantage of the above fact and would ensure that the ResolverEPR was correctly informed of the migration (change in wsa:to URI).
Instead of mandating, perhaps the speficiations can recommended the use of WS-Naming? Specifications could still accept EPRs and implementations can check them for the presence of an AbstractName and take advantage of it if available (internal hash table, etc).
Agree with this statement. In essence, if a service requires the ws-naming claim it can check for it...
Ian Foster wrote: Dave:
My "proposal" was just a request that we have the "resolver EPR" in a separate specification.
However, in a bit more detail, here are my opinions in this area:
1) The BES specification should just use EPRs, and not mandate the use of WS-Naming AbstractNames.
Rationale: Such a requirement imposes a cost on BES users that they may not want to pay--for a benefit that they may not require.
Mandating the use of WS-Naming names imposes an overhead in terms of both time (the cost of generating the AbstractName) and space (the storage that it requires).
Yet:
a) I may not need to perform the equivalence test that AbstractNames are introduced to allow. (E.g., I haven't thought deeply about this--but I can't recall that we've ever encountered that need.)
b) I may need to perform an equivalence test, but not require the "globally unique in time and space" constraint that WS-Naming requires. [This constraint presumably constrains the form of the name that I can create, preventing me, for example, from using user- supplied strings.]
c) I may need to perform an equivalence test, but want to do that at a different level: e.g., I may already maintain my own table of jobs for some other purpose, so the WS-Naming AbstractName just replicates unique data that I am already maintaining.
If people WANT to pass around EPRs that have these AbstractNames in them (or other similar constructs with different constraints/semantics: e.g., "unique within my VO"), all power to them: but I don't see a reason to require this in BES or any other specification.
2) We should have a separate specification for the "resolver EPR" (and associated Resolver portType) and the "AbstractName" concept.
Rationale: The "resolver" EPR is useful in a wide range of situations independent of the specific name syntax and semantics described in WS-Naming.
I can imagine lots of places where I might use a resolver EPR. E.g., maybe in the BES case my jobs can migrate, and so I want the EPR that I get back to include a resolver EPR that I can use to determine its new location. But as noted above, I don't necessarily need an AbstractName in the BES case.
Similarly for relocatable services: maybe I'll do a metadata query on a registry to get a service EPR (with a resolver EPR in it), then if the service is not where the registry says, contact the resolver to determine its new location. Again, I don't see that I will need AbstractName semantics here.
Thus, given that we have two concepts that seem logically quite distinct, and that are certainly distinct in terms of when and how that will be used, I argue that they should be separated.
3) You also asked about three levels and about "human-oriented" vs. "abstract". These concepts are not in the WS-Naming spec, but for what it's worth, I don't see them as useful or relevant here. People use many sorts of "names" of different sorts, and they don't cleanly separate into three levels or into "human-oriented" or "abstract". E.g., if I'm implementing a replica location service, I often want to map first from a "logical file name" to a "site name" and then from there to a "physical location." Furthermore, if you build a system of this sort, you have to allow people to stick whatever names are convenient for them in at each level, because often these names come from elsewhere. Some users may make some of these names "human-oriented", others may not--it shouldn't matter to the service.
Regards -- Ian.
At 08:58 PM 8/30/2005 +0100, Dave Berry wrote: Ian,
I wonder whether you or one of your team could write a note about the background to your proposals? It would help me to understand how they fit into the wider architecture. At present I don't feel able to make an informed contribution to the discussion.
The current shape of OGSA (if I can call it "current" without biasing the discussion) has three concepts relevant to this discussion:
1. Three levels of naming (human-oriented, abstract, and address). 2. An implementation of abstract names as an EPR containing a string and a resolver. 3. A service interface for BES that takes abstract names as parameters.
Each has associated questions raised by your concerns:
1. Do you want to have fewer levels of naming across the architecture or are you happy with the three listed here?
2a. Are you happy that abstract names should be represented in this way? 2b. What would a "resolver without an abstract name" resolve? When do you need it in addition to or instead of an abstract name? Does it fulfill a different function or is there some overlap?
3. What should the BES interface accept instead of or as well as abstract names? When do you need this functionality? How should the interface cope with the different types of entity?
I can make a guess at part of these answers but I'd rather read an explanation from the horse's mouth.
Best wishes,
Dave.
-----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Ian Foster Sent: 30 August 2005 04:02 To: Tom Maguire Cc: Andrew Grimshaw; ogsa-wg@ggf.org Subject: Re: [ogsa-wg] BES query
I'm interested in that question too. As I've said on quite a few occasions, I like the EPR + ResolverEPR (as in the original WS-RenewableReferences) -- that is a nice simple mechanism. I don't understand why we can't have this in a separate specification.
Ian.
So just to get some nomenclature correct. By WS-Names we mean an EPR that is profiled to contain both a ResolverEPR and an AbstractName. So what do we call an EPR which just contains a ResolverEPR?
Tom
Ian Foster wrote:
I believe that the opinion was expressed by some at the San Diego meeting (e.g., by Steve Tuecke) that WS-Names should NOT be mandated.
It certainly defines a nice way of using EPRs that will be useful in some situations. But it surely can't be the case that we always want to mandate this particular set of extensions to EPRs. That requirement certainly doesn't jibe with how we use them in all cases, for example.
Ian.
At 09:25 AM 8/29/2005 -0400, Andrew Grimshaw wrote:
All,
In the BES working group call last week the issue of naming came up. The current DRAFT specification calls for passing WS-Names in and out of
At 09:23 PM 8/29/2005 -0400, Tom Maguire wrote: the
various function calls. There was the question as to whether EPRs is all that should be specified. We thought this is an OGSA issue: mainly is
OGSA endorsing the use of WS-Names where appropriate. Clearly I think we should. But this should be discussed.
Andrew
_______________________________________________________________ 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/>
_______________________________________________________________ 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 _______________________________________________________________ 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
-- Michael Behrens R2AD, LLC (571) 594-3008 (cell) *new* (703) 714-0442 (land)
Hi Tom,
If so, then a unique AbstractName is needed in order to accurately resolve EPRs, especially considering the potential service migration.
I think that AbstractName is certainly one approach to solving this problem. Remember that ReferenceParameters are used to provide information to the RECEIVER(wsa:to) to disambiguate the resource for dispatch.
I am confused by this - according to the WS-Addressing working group ReferenceParameters are designed to support stateful interactions (similar to the use of cookies with HTTP) - not to identify resources. They CAN be used to identify resources but this is not best practice according to the working group. see http://www.w3.org/2002/ws/addr/wd-issues/#i001 and http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0051 thanks Mark
Mark McKeown <zzalsmm3@nessie.mcc.ac.uk> wrote on 08/31/2005 09:53:39 AM:
Hi Tom,
If so, then a unique AbstractName is needed in order to accurately resolve EPRs, especially considering the potential service migration.
I think that AbstractName is certainly one approach to solving this problem. Remember that ReferenceParameters are used to provide
information
to the RECEIVER(wsa:to) to disambiguate the resource for dispatch.
I am confused by this - according to the WS-Addressing working group ReferenceParameters are designed to support stateful interactions (similar to the use of cookies with HTTP) - not to identify resources. They CAN be used to identify resources but this is not best practice according to the working group.
Ok, so what is confusing you is the use of 'disambiguate the resource for dispatch'. So, change that sentence to: Remember that ReferenceParameters are used to provide required information to the RECEIVER(wsa:to) interaction. And the spec ultimately wound up saying: [reference parameters] : xs:any (0..unbounded). A reference may contain a number of individual parameters that are associated with the endpoint to facilitate a particular interaction. Reference parameters are namespace-qualified element information items that are required to properly interact with the endpoint. Reference parameters are provided by the issuer of the endpoint reference and are assumed to be opaque to other users of an endpoint refernce. The binding of reference parameters to messages depends upon the protocol binding used to interact with the endpoint - Web Services Addressing 1.0 - SOAP Binding[WS-Addressing-SOAP] describes the default binding for the SOAP protocol. and additionally says: 2.3 Endpoint Reference Comparison This specification provides no concept of endpoint identity and therefore does not provide any mechanism to determine equality or inequality of EPRs and does not specify the consequences of their equality or inequality. However, note that it is possible for other specifications to provide a comparison function that is applicable within a limited scope.
see http://www.w3.org/2002/ws/addr/wd-issues/#i001 and http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0051
thanks Mark
Hi Tom, Thanks for the response - just to make I am understanding everything correctly. ReferenceParameters are used to "facilitate a particular interaction" with an endpoint - Hugo Hass compared them to HTTP Cookies. Taking an example of a WS-Resource with an associated ResourceProperties document. The WS-Resource could have an endpoint: <wsa:EndpointReference> <wsa:address>http://vermont.mvc.mcc.ac.uk/<wsa:address> </wsa:EndpointReference> Now supposing the WS-Resource provider wanted to povide leases for providing a write lock on the ResourceProperties document, to support this the WS-Resource needs to support stateful interactions, ie. the WS-Resource needs to be able to identify which client holds the lease. (Cookies are designed to support stateful interactions over HTTP so we should be able to use ReferenceParameters) The WS-Resource provider could do this by providing a new EPR that contained ReferenceParameters to the client when he requests the lease (other options are WS-Context and WS-Coordintation) - the EPR could look like <wsa:EndpointReference> <wsa:address>http://vermont.mvc.mcc.ac.uk/<wsa:address> <wsa:ReferenceParameters> <my:Lease>345...56</my:Lease> </wsa:ReferenceParameters> </wsa:EndpointReference> The client who presents <my:Lease>345...56</my:Lease> in the SOAP Header has the write lock - effectively the ReferenceParameters are used to indentify a client in this case. (Of course some people object to stateful interactions - not as scalable, not as fault tolerent etc, http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm) Once the lease expires the EPR is invalid - the client has to get a new one. (Another approach is to give each client a different EPR with different ReferenceParameters - then clients don't have to get a new EPR when they request a lease and you can track what each client does, similar to how HTTP cookies can track browsers as they move around a site) So resolving an EPR could be needed for two reasons: the endpoint has moved (similar to 301 in HTTP ) or the client wants to start a new stateful interaction (similar to deleting your cookies from you browser). Is this example the correct use of ReferenceParameters? thanks Mark ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Mc Keown RSS Mark.McKeown@man.ac.uk Manchester Computing +44 161 275 0601 University of Manchester ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On Wed, 31 Aug 2005, Tom Maguire wrote:
Mark McKeown <zzalsmm3@nessie.mcc.ac.uk> wrote on 08/31/2005 09:53:39 AM:
Hi Tom,
If so, then a unique AbstractName is needed in order to accurately resolve EPRs, especially considering the potential service migration.
I think that AbstractName is certainly one approach to solving this problem. Remember that ReferenceParameters are used to provide
information
to the RECEIVER(wsa:to) to disambiguate the resource for dispatch.
I am confused by this - according to the WS-Addressing working group ReferenceParameters are designed to support stateful interactions (similar to the use of cookies with HTTP) - not to identify resources. They CAN be used to identify resources but this is not best practice according to the working group.
Ok, so what is confusing you is the use of 'disambiguate the resource for dispatch'. So, change that sentence to: Remember that ReferenceParameters are used to provide required information to the RECEIVER(wsa:to) interaction.
And the spec ultimately wound up saying: [reference parameters] : xs:any (0..unbounded). A reference may contain a number of individual parameters that are associated with the endpoint to facilitate a particular interaction. Reference parameters are namespace-qualified element information items that are required to properly interact with the endpoint. Reference parameters are provided by the issuer of the endpoint reference and are assumed to be opaque to other users of an endpoint refernce. The binding of reference parameters to messages depends upon the protocol binding used to interact with the endpoint - Web Services Addressing 1.0 - SOAP Binding[WS-Addressing-SOAP] describes the default binding for the SOAP protocol.
and additionally says:
2.3 Endpoint Reference Comparison
This specification provides no concept of endpoint identity and therefore does not provide any mechanism to determine equality or inequality of EPRs and does not specify the consequences of their equality or inequality. However, note that it is possible for other specifications to provide a comparison function that is applicable within a limited scope.
see http://www.w3.org/2002/ws/addr/wd-issues/#i001 and http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0051
thanks Mark
It is a correct use of ReferenceParameters. That is not to say that other uses are incorrect. Tom Mark McKeown <zzalsmm3@nessie.mcc.ac.uk> wrote on 09/02/2005 06:24:09 AM:
Hi Tom, Thanks for the response - just to make I am understanding everything correctly.
ReferenceParameters are used to "facilitate a particular interaction" with an endpoint - Hugo Hass compared them to HTTP Cookies.
Taking an example of a WS-Resource with an associated ResourceProperties document. The WS-Resource could have an endpoint:
<wsa:EndpointReference> <wsa:address>http://vermont.mvc.mcc.ac.uk/<wsa:address> </wsa:EndpointReference>
Now supposing the WS-Resource provider wanted to povide leases for providing a write lock on the ResourceProperties document, to support this the WS-Resource needs to support stateful interactions, ie. the WS-Resource needs to be able to identify which client holds the lease. (Cookies are designed to support stateful interactions over HTTP so we should be able to use ReferenceParameters) The WS-Resource provider could do this by providing a new EPR that contained ReferenceParameters to the client when he requests the lease (other options are WS-Context and WS-Coordintation) - the EPR could look like
<wsa:EndpointReference> <wsa:address>http://vermont.mvc.mcc.ac.uk/<wsa:address> <wsa:ReferenceParameters> <my:Lease>345...56</my:Lease> </wsa:ReferenceParameters> </wsa:EndpointReference>
The client who presents <my:Lease>345...56</my:Lease> in the SOAP Header has the write lock - effectively the ReferenceParameters are used to indentify a client in this case. (Of course some people object to stateful interactions - not as scalable, not as fault tolerent etc, http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)
Once the lease expires the EPR is invalid - the client has to get a new one.
(Another approach is to give each client a different EPR with different ReferenceParameters - then clients don't have to get a new EPR when they request a lease and you can track what each client does, similar to how HTTP cookies can track browsers as they move around a site)
So resolving an EPR could be needed for two reasons: the endpoint has moved (similar to 301 in HTTP ) or the client wants to start a new stateful interaction (similar to deleting your cookies from you browser).
Is this example the correct use of ReferenceParameters?
thanks Mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Mc Keown RSS Mark.McKeown@man.ac.uk Manchester Computing +44 161 275 0601 University of Manchester ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Wed, 31 Aug 2005, Tom Maguire wrote:
Mark McKeown <zzalsmm3@nessie.mcc.ac.uk> wrote on 08/31/2005 09:53:39
Hi Tom,
If so, then a unique AbstractName is needed in order to accurately
resolve
EPRs, especially considering the potential service migration.
I think that AbstractName is certainly one approach to solving this problem. Remember that ReferenceParameters are used to provide information to the RECEIVER(wsa:to) to disambiguate the resource for dispatch.
I am confused by this - according to the WS-Addressing working group ReferenceParameters are designed to support stateful interactions (similar to the use of cookies with HTTP) - not to identify resources. They CAN be used to identify resources but this is not best practice according to the working group.
Ok, so what is confusing you is the use of 'disambiguate the resource for dispatch'. So, change that sentence to: Remember that ReferenceParameters are used to provide required information to the RECEIVER(wsa:to) interaction.
And the spec ultimately wound up saying: [reference parameters] : xs:any (0..unbounded). A reference may contain a number of individual parameters that are associated with the endpoint to facilitate a particular interaction. Reference parameters are namespace-qualified element information items that are required to properly interact with the endpoint. Reference parameters are provided by the issuer of the endpoint reference and are assumed to be opaque to other users of an endpoint refernce. The binding of reference parameters to messages depends upon the protocol binding used to interact with the endpoint - Web Services Addressing 1.0 - SOAP Binding[WS-Addressing-SOAP] describes the default binding for the SOAP protocol.
and additionally says:
2.3 Endpoint Reference Comparison
This specification provides no concept of endpoint identity and
AM: therefore
does not provide any mechanism to determine equality or inequality of EPRs and does not specify the consequences of their equality or inequality. However, note that it is possible for other specifications to provide a comparison function that is applicable within a limited scope.
see http://www.w3.org/2002/ws/addr/wd-issues/#i001 and http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0051
thanks Mark
Hi Tom, Taking the discussion to the next stage. I have shown a case where ReferenceParameters could be used to provide a mechanism to support locking of WS-Resources, ie using stateful interactions. Now if a service provider gives me a EPR containing ReferenceParameters then I should NOT put that EPR into any sort of public registry where other clients might find that EPR and use it. I cannot tell what the ReferenceParameters are being used for, they could be used to track one of my particular client activities so I don't want any other client to use that EPR and associated ReferenceParameters. In the case of the lock, if the WS-Resource provider was using the ReferenceParameters to track which client has the lock - then putting the EPR into a registry for other clients to find would lead to major problems. Effectively a client should not publicise/share EPRs that contain ReferenceParameters. Therefore I think it is a mistake for WS-Resource providers to use ReferenceParameters to associate a message with a particular piece of state - I think that is why the WS-Addressing WG discourages this use of ReferenceParameters. cheers Mark ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Mc Keown RSS Mark.McKeown@man.ac.uk Manchester Computing +44 161 275 0601 University of Manchester ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On Fri, 2 Sep 2005, Tom Maguire wrote:
It is a correct use of ReferenceParameters. That is not to say that other uses are incorrect.
Tom
Mark McKeown <zzalsmm3@nessie.mcc.ac.uk> wrote on 09/02/2005 06:24:09 AM:
Hi Tom, Thanks for the response - just to make I am understanding everything correctly.
ReferenceParameters are used to "facilitate a particular interaction" with an endpoint - Hugo Hass compared them to HTTP Cookies.
Taking an example of a WS-Resource with an associated ResourceProperties document. The WS-Resource could have an endpoint:
<wsa:EndpointReference> <wsa:address>http://vermont.mvc.mcc.ac.uk/<wsa:address> </wsa:EndpointReference>
Now supposing the WS-Resource provider wanted to povide leases for providing a write lock on the ResourceProperties document, to support this the WS-Resource needs to support stateful interactions, ie. the WS-Resource needs to be able to identify which client holds the lease. (Cookies are designed to support stateful interactions over HTTP so we should be able to use ReferenceParameters) The WS-Resource provider could do this by providing a new EPR that contained ReferenceParameters to the client when he requests the lease (other options are WS-Context and WS-Coordintation) - the EPR could look like
<wsa:EndpointReference> <wsa:address>http://vermont.mvc.mcc.ac.uk/<wsa:address> <wsa:ReferenceParameters> <my:Lease>345...56</my:Lease> </wsa:ReferenceParameters> </wsa:EndpointReference>
The client who presents <my:Lease>345...56</my:Lease> in the SOAP Header has the write lock - effectively the ReferenceParameters are used to indentify a client in this case. (Of course some people object to stateful interactions - not as scalable, not as fault tolerent etc, http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)
Once the lease expires the EPR is invalid - the client has to get a new one.
(Another approach is to give each client a different EPR with different ReferenceParameters - then clients don't have to get a new EPR when they request a lease and you can track what each client does, similar to how HTTP cookies can track browsers as they move around a site)
So resolving an EPR could be needed for two reasons: the endpoint has moved (similar to 301 in HTTP ) or the client wants to start a new stateful interaction (similar to deleting your cookies from you browser).
Is this example the correct use of ReferenceParameters?
thanks Mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Mc Keown RSS Mark.McKeown@man.ac.uk Manchester Computing +44 161 275 0601 University of Manchester ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Wed, 31 Aug 2005, Tom Maguire wrote:
Mark McKeown <zzalsmm3@nessie.mcc.ac.uk> wrote on 08/31/2005 09:53:39
Hi Tom,
If so, then a unique AbstractName is needed in order to accurately
resolve
EPRs, especially considering the potential service migration.
I think that AbstractName is certainly one approach to solving this problem. Remember that ReferenceParameters are used to provide information to the RECEIVER(wsa:to) to disambiguate the resource for dispatch.
I am confused by this - according to the WS-Addressing working group ReferenceParameters are designed to support stateful interactions (similar to the use of cookies with HTTP) - not to identify resources. They CAN be used to identify resources but this is not best practice according to the working group.
Ok, so what is confusing you is the use of 'disambiguate the resource for dispatch'. So, change that sentence to: Remember that ReferenceParameters are used to provide required information to the RECEIVER(wsa:to) interaction.
And the spec ultimately wound up saying: [reference parameters] : xs:any (0..unbounded). A reference may contain a number of individual parameters that are associated with the endpoint to facilitate a particular interaction. Reference parameters are namespace-qualified element information items that are required to properly interact with the endpoint. Reference parameters are provided by the issuer of the endpoint reference and are assumed to be opaque to other users of an endpoint refernce. The binding of reference parameters to messages depends upon the protocol binding used to interact with the endpoint - Web Services Addressing 1.0 - SOAP Binding[WS-Addressing-SOAP] describes the default binding for the SOAP protocol.
and additionally says:
2.3 Endpoint Reference Comparison
This specification provides no concept of endpoint identity and
AM: therefore
does not provide any mechanism to determine equality or inequality of EPRs and does not specify the consequences of their equality or inequality. However, note that it is possible for other specifications to provide a comparison function that is applicable within a limited scope.
see http://www.w3.org/2002/ws/addr/wd-issues/#i001 and http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0051
thanks Mark
I have to admit that I am confused as to what makes adding an abstract name to an EPR so much of a burden. I know that Andrew and I are talking about something very lightweight (perhaps just generating a GUID when the EPR is generated). So, in the technical sense, it's extra work that needs to be done, but in my mind it's far less honerous then writing good comments for your code and I think everyone would agree that the benefits of doing so far outweight the burden. In this case, AbstractNames give a potentially huge benefit for a line or two of code. Why is this such a big deal? -Mark
-----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Mark McKeown Sent: Wednesday, August 31, 2005 9:54 AM To: Tom Maguire Cc: Michael Behrens; Dave Berry; Ian Foster; Andrew Grimshaw; ogsa-wg@ggf.org; owner-ogsa-wg@ggf.org; Tom Maguire Subject: Re: [ogsa-wg] BES query
Hi Tom,
If so, then a unique AbstractName is needed in order to accurately resolve EPRs, especially considering the potential service migration.
I think that AbstractName is certainly one approach to solving this problem. Remember that ReferenceParameters are used to provide information to the RECEIVER(wsa:to) to disambiguate the resource for dispatch.
I am confused by this - according to the WS-Addressing working group ReferenceParameters are designed to support stateful interactions (similar to the use of cookies with HTTP) - not to identify resources. They CAN be used to identify resources but this is not best practice according to the working group.
see http://www.w3.org/2002/ws/addr/wd-issues/#i001 and http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0051
thanks Mark
On Aug 31, Mark Morgan modulated:
I have to admit that I am confused as to what makes adding an abstract name to an EPR so much of a burden. I know that Andrew and I are talking about something very lightweight (perhaps just generating a GUID when the EPR is generated). So, in the technical sense, it's extra work that needs to be done, but in my mind it's far less honerous then writing good comments for your code and I think everyone would agree that the benefits of doing so far outweight the burden. In this case, AbstractNames give a potentially huge benefit for a line or two of code. Why is this such a big deal?
-Mark
Mark: In reflecting on this a bit, I personally would like to hear comments from the security crowd. It sounds like the main difference in having this GUID is, as I tried to summarize earlier, that someone can compare EPRs or otherwise reason about service identities without consulting the referenced service. What are the ramifications for security and system stability? What happens if someone uses a poor implementation or malicously puts GUIDs into EPRs such that they alias other services? Do we have signature validation for EPRs? I guess this depends on the "culture" that would emerge around consumption and use of these GUIDs... I wonder if there are unspoken architectural assumptions here that are at the heart of the debate? karl -- Karl Czajkowski karlcz@univa.com
Karl, You raise an interesting point - the point "What are the ramifications for security and system stability? What happens if someone uses a poor implementation or malicously puts GUIDs into EPRs such that they alias other services? Do we have signature validation for EPRs? " This was discussed in the design team over a year ago and the consensus was that being able to strongly tie identity to the name, e.g., cryptographically, was not a requirement - but rather an option. (I agreed it should not be required - but felt strongly that we must be able to accommodate such linkage). As you may know the Legion implementation of abstract names (called LOID's) include a public key so that clients can ensure that only the holder of the corresponding private key can read the message. Similarly in the "Secure Grid Naming Protocol" (SGNP) that Avaki took to GGF there were keys in the names. That may have persisted into LSID's - which were derived off of SGNP - I am not sure. As the WS-naming DRAFT currently stands there is nothing to prevent a name generator (minter?) from placing keys, signed certs, or anything else in the AbstractName component. For example I might include the GUID and a signed hash along with the cert that signed it. Or ... there are lots of options that all fit in the purview of WS-Naming. As to malicious name generation of spoofing - without some additional mechanism it can happen - that's life. It is not the way I would prefer it, but getting agreement on "how" would be difficult. My guess is that if we are successful, that AbstractName "types" will be developed that allow clients to verify the AbstractName. Andrew -----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Karl Czajkowski Sent: Thursday, September 01, 2005 12:11 AM To: Mark Morgan Cc: ogsa-wg@ggf.org Subject: Re: [ogsa-wg] BES query On Aug 31, Mark Morgan modulated:
I have to admit that I am confused as to what makes adding an abstract name to an EPR so much of a burden. I know that Andrew and I are talking about something very lightweight (perhaps just generating a GUID when the EPR is generated). So, in the technical sense, it's extra work that needs to be done, but in my mind it's far less honerous then writing good comments for your code and I think everyone would agree that the benefits of doing so far outweight the burden. In this case, AbstractNames give a potentially huge benefit for a line or two of code. Why is this such a big deal?
-Mark
Mark: In reflecting on this a bit, I personally would like to hear comments from the security crowd. It sounds like the main difference in having this GUID is, as I tried to summarize earlier, that someone can compare EPRs or otherwise reason about service identities without consulting the referenced service. What are the ramifications for security and system stability? What happens if someone uses a poor implementation or malicously puts GUIDs into EPRs such that they alias other services? Do we have signature validation for EPRs? I guess this depends on the "culture" that would emerge around consumption and use of these GUIDs... I wonder if there are unspoken architectural assumptions here that are at the heart of the debate? karl -- Karl Czajkowski karlcz@univa.com
participants (8)
-
Andrew Grimshaw -
Ian Foster -
Karl Czajkowski -
Mark McKeown -
Mark Morgan -
Michael Behrens -
Steve Loughran -
Tom Maguire