I'm having a lot of trouble understanding why certain decisions were made with respect to tracker resolution. The most verbose the descriptions seem to get are "assigned to so-and-so for clarification". There's no context, and since I've missed a few phone calls that dealt with objections I've had, I have no idea why the decisions were made. Could whoever is resolving these trackers kindly make an effort to include more context so people don't have to ask later why certain things are the way they are? I don't think it's appropriate to expect that everybody interested in BES should be able to attend every single telecon just to get information on tracker resolution. That's why Gridforge allows comments to be attached to trackers, IMHO. I'm not trying to be mean here. I just think we could do better from the "open process" point of view in explaining what we're doing and why. That said, I have a couple of questions about tracker resolutions that. I'd be grateful if anybody attending the associated telecon could answer them. 1) What was the reason for keeping ContainedResourceAttributes and not including attributes like ContainedStatuses and ContainedActivityDocuments? Was there a concensus on why the problems associated with aggregation of activity attributes should be ignored? 2) Why are we still essentially advocating WS-Transfer's attribute model by having the GetAttributesDocument operation? In my opinion it is not necessary for minimal interop, and makes WS-Transfer's Get operation redundant. Is part of the problem that we haven't defined any interop standards yet? Thanks! Peter
Has Peter's comment been discussed? He advocates (I believe) that we should not include the GetAttributesDocument operation. Instead, any particular BES should choose (if they wish) to provide access to attributes via an appropriate resource model-specific operations. * A WS-Transfer-based BES would use GET * A WSRF-based BES would use WS-ResourceProperties * A resource-model-free BES might define a GetAttributesDocument operation * etc. This seems a good proposal to me. Ian. At 03:09 PM 9/2/2006 -0600, Peter G. Lane wrote:
2) Why are we still essentially advocating WS-Transfer's attribute model by having the GetAttributesDocument operation? In my opinion it is not necessary for minimal interop, and makes WS-Transfer's Get operation redundant. Is part of the problem that we haven't defined any interop standards yet?
_______________________________________________________________ Ian Foster -- Weblog: http://ianfoster.typepad.com Computation Institute: www.ci.uchicago.edu & www.ci.anl.gov Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org
I'm not sure what level of "addressing" is meant here, but my recollection/belief was that it was addressed in the group in so much as the topic was discussed at the last face-to-face and that the appearance of the GetAttributesDocument was the result of that discussion. We haven't as a group discussed the email that Peter sent out yet but it is my belief that doing so is essentially a rehash of discussions previously had. -Mark
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster Sent: Tuesday, September 05, 2006 1:42 PM To: Mail list for ogsa-bes-wg working group; ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Has Peter's comment been discussed?
He advocates (I believe) that we should not include the GetAttributesDocument operation. Instead, any particular BES should choose (if they wish) to provide access to attributes via an appropriate resource model-specific operations.
* A WS-Transfer-based BES would use GET * A WSRF-based BES would use WS-ResourceProperties * A resource-model-free BES might define a GetAttributesDocument operation * etc.
This seems a good proposal to me.
Ian.
At 03:09 PM 9/2/2006 -0600, Peter G. Lane wrote:
2) Why are we still essentially advocating WS-Transfer's attribute model by having the GetAttributesDocument operation? In my opinion it is not necessary for minimal interop, and makes WS-Transfer's Get operation redundant. Is part of the problem that we haven't defined any interop standards yet?
_______________________________________________________________ Ian Foster -- Weblog: http://ianfoster.typepad.com <http://ianfoster.typepad.com/> Computation Institute: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> & www.ci.anl.gov <http://www.ci.anl.gov/> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org <http://www.globus.org/>
Mark: I guess that I am asking that we re-open the issue, then. Ian. At 07:47 PM 9/5/2006 -0400, Mark Morgan wrote:
I'm not sure what level of "addressing" is meant here, but my recollection/belief was that it was addressed in the group in so much as the topic was discussed at the last face-to-face and that the appearance of the GetAttributesDocument was the result of that discussion. We haven't as a group discussed the email that Peter sent out yet but it is my belief that doing so is essentially a rehash of discussions previously had.
-Mark
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster Sent: Tuesday, September 05, 2006 1:42 PM To: Mail list for ogsa-bes-wg working group; ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Has Peter's comment been discussed?
He advocates (I believe) that we should not include the GetAttributesDocument operation. Instead, any particular BES should choose (if they wish) to provide access to attributes via an appropriate resource model-specific operations.
* A WS-Transfer-based BES would use GET * A WSRF-based BES would use WS-ResourceProperties * A resource-model-free BES might define a GetAttributesDocument operation * etc.
This seems a good proposal to me.
Ian.
At 03:09 PM 9/2/2006 -0600, Peter G. Lane wrote:
2) Why are we still essentially advocating WS-Transfer's attribute model by having the GetAttributesDocument operation? In my opinion it is not necessary for minimal interop, and makes WS-Transfer's Get operation redundant. Is part of the problem that we haven't defined any interop standards yet?
_______________________________________________________________ Ian Foster -- Weblog: http://ianfoster.typepad.com <http://ianfoster.typepad.com/> Computation Institute: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> & www.ci.anl.gov <http://www.ci.anl.gov/> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org <http://www.globus.org/>
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
_______________________________________________________________ Ian Foster -- Weblog: http://ianfoster.typepad.com Computation Institute: www.ci.uchicago.edu & www.ci.anl.gov Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org
Well, I guess the thing that confuses me is whether or not it is SOP to re-open an issue that was discussed previously because a new person has re-raised that issue. I'll bow to whatever the majority thinks is best of course, but it seems to me that you can't reopen an issue everytime a new person re-raises it or you risk the possibility of continuously cycling on it. New information should always be considered, but if an issue gets re-raised that has already been discussed fully and voted on, then it doesn't make sense to re-discuss it. Just my 2 cents worth... -Mark
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster Sent: Tuesday, September 05, 2006 9:39 PM To: Mail list for ogsa-bes-wg working group; 'Mail list for ogsa-bes-wg working group'; ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Mark:
I guess that I am asking that we re-open the issue, then.
Ian.
At 07:47 PM 9/5/2006 -0400, Mark Morgan wrote:
I'm not sure what level of "addressing" is meant here, but my recollection/belief was that it was addressed in the group in so much as the topic was discussed at the last face-to-face and that the appearance of the GetAttributesDocument was the result of that discussion. We haven't as a group discussed the email that Peter sent out yet but it is my belief that doing so is essentially a rehash of discussions previously had.
-Mark
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster Sent: Tuesday, September 05, 2006 1:42 PM To: Mail list for ogsa-bes-wg working group; ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Has Peter's comment been discussed?
He advocates (I believe) that we should not include the GetAttributesDocument operation. Instead, any particular BES should choose (if they wish) to provide access to attributes via an appropriate resource model-specific operations.
* A WS-Transfer-based BES would use GET * A WSRF-based BES would use WS-ResourceProperties * A resource-model-free BES might define a GetAttributesDocument operation * etc.
This seems a good proposal to me.
Ian.
At 03:09 PM 9/2/2006 -0600, Peter G. Lane wrote:
2) Why are we still essentially advocating WS-Transfer's attribute model by having the GetAttributesDocument operation? In my opinion it is not necessary for minimal interop, and makes WS-Transfer's Get operation redundant. Is part of the problem that we haven't defined any interop standards yet?
_______________________________________________________________
Ian Foster -- Weblog: http://ianfoster.typepad.com <http://ianfoster.typepad.com/> <http://ianfoster.typepad.com/> Computation Institute: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> <http://www.ci.uchicago.edu/> & www.ci.anl.gov <http://www.ci.anl.gov/> <http://www.ci.anl.gov/> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org <http://www.globus.org/> <http://www.globus.org/>
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
_______________________________________________________________ Ian Foster -- Weblog: http://ianfoster.typepad.com <http://ianfoster.typepad.com/> Computation Institute: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> & www.ci.anl.gov <http://www.ci.anl.gov/> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org <http://www.globus.org/>
If it's about fear of reopening the dialog, then I'd appreciate if someone could at least add comments to the two trackers addressing the issues raised. Ian can push for reopening this particular issue if he wants; but I just want to know why we're advocating WS-Transfer in spirit if not in name, and why aggregation of resource attributes is not a concern to anyone else. As long as someone has a reason for these issues that I raised in the tracker, I'm fine. I don't expect to get everything to go my way, and I'm open to being convinced of alternate points of view. I just don't like being ignorant, especially when I'll have to implement the spec someday. On the other hand, if nobody has a good answer for the issues, I think Ian is perfectly valid in asking for it to be reopened as apparently the issues weren't actually addressed as they should have been. Peter Mark Morgan wrote:
Well, I guess the thing that confuses me is whether or not it is SOP to re-open an issue that was discussed previously because a new person has re-raised that issue. I'll bow to whatever the majority thinks is best of course, but it seems to me that you can't reopen an issue everytime a new person re-raises it or you risk the possibility of continuously cycling on it. New information should always be considered, but if an issue gets re-raised that has already been discussed fully and voted on, then it doesn't make sense to re-discuss it. Just my 2 cents worth...
-Mark
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster Sent: Tuesday, September 05, 2006 9:39 PM To: Mail list for ogsa-bes-wg working group; 'Mail list for ogsa-bes-wg working group'; ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Mark:
I guess that I am asking that we re-open the issue, then.
Ian.
At 07:47 PM 9/5/2006 -0400, Mark Morgan wrote:
I'm not sure what level of "addressing" is meant here, but my recollection/belief was that it was addressed in the group in so much as the topic was discussed at the last face-to-face and that the appearance of the GetAttributesDocument was the result of that discussion. We haven't as a group discussed the email that Peter sent out yet but it is my belief that doing so is essentially a rehash of discussions previously had.
-Mark
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster Sent: Tuesday, September 05, 2006 1:42 PM To: Mail list for ogsa-bes-wg working group; ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Has Peter's comment been discussed?
He advocates (I believe) that we should not include the GetAttributesDocument operation. Instead, any particular BES should choose (if they wish) to provide access to attributes via an appropriate resource model-specific operations.
* A WS-Transfer-based BES would use GET * A WSRF-based BES would use WS-ResourceProperties * A resource-model-free BES might define a GetAttributesDocument operation * etc.
This seems a good proposal to me.
Ian.
At 03:09 PM 9/2/2006 -0600, Peter G. Lane wrote:
2) Why are we still essentially advocating WS-Transfer's attribute model by having the GetAttributesDocument operation? In my opinion it is not necessary for minimal interop, and makes WS-Transfer's Get operation redundant. Is part of the problem that we haven't defined any interop standards yet?
_______________________________________________________________
Ian Foster -- Weblog: http://ianfoster.typepad.com <http://ianfoster.typepad.com/> <http://ianfoster.typepad.com/> Computation Institute: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> <http://www.ci.uchicago.edu/> & www.ci.anl.gov <http://www.ci.anl.gov/> <http://www.ci.anl.gov/> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org <http://www.globus.org/> <http://www.globus.org/>
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
_______________________________________________________________ Ian Foster -- Weblog: http://ianfoster.typepad.com <http://ianfoster.typepad.com/> Computation Institute: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> & www.ci.anl.gov <http://www.ci.anl.gov/> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org <http://www.globus.org/>
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
Characterizing this issue as WS-RF vs WS-Transfer is misleading. I can't recall any discussions within this group where anybody advocated doing a WS-Transfer rendering for the BES interface. Well ... other than the WS-RF proponents who wrongly assumed that because some (like myself) were against the use of WS-RF, that must mean we were in favour of WS-Transfer. I also don't recall anybody advocating operations for modification, etc such as defined within WS-Transfer. To me this is a discussion of a resource modelling approach (built on WS-RF) vs a non resource modelling approach. My main reason for not wanting to make use of one of the resource modelling approaches has to do with the burden of implementation. If Platform buys into one of these resource models, we no longer have to implement one simple spec and test compliance of that specification, but we need to implement and test compliance on a suite of specifications, for (in my opinion) no extra benefit. You might say that once you've implemented a resource modelling suite of specifications, you can use it over and over and thus amortize the cost of this implementation. But even at a small cost, it's not one that I'm willing to take, as the implementation of standards specifications is one feature in a sea of features that we implement from product release to product release. -- Chris On 06/9/06 07:56, "Peter G. Lane" <lane@mcs.anl.gov> wrote:
If it's about fear of reopening the dialog, then I'd appreciate if someone could at least add comments to the two trackers addressing the issues raised.
Ian can push for reopening this particular issue if he wants; but I just want to know why we're advocating WS-Transfer in spirit if not in name, and why aggregation of resource attributes is not a concern to anyone else. As long as someone has a reason for these issues that I raised in the tracker, I'm fine. I don't expect to get everything to go my way, and I'm open to being convinced of alternate points of view. I just don't like being ignorant, especially when I'll have to implement the spec someday.
On the other hand, if nobody has a good answer for the issues, I think Ian is perfectly valid in asking for it to be reopened as apparently the issues weren't actually addressed as they should have been.
Peter
Mark Morgan wrote:
Well, I guess the thing that confuses me is whether or not it is SOP to re-open an issue that was discussed previously because a new person has re-raised that issue. I'll bow to whatever the majority thinks is best of course, but it seems to me that you can't reopen an issue everytime a new person re-raises it or you risk the possibility of continuously cycling on it. New information should always be considered, but if an issue gets re-raised that has already been discussed fully and voted on, then it doesn't make sense to re-discuss it. Just my 2 cents worth...
-Mark
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster Sent: Tuesday, September 05, 2006 9:39 PM To: Mail list for ogsa-bes-wg working group; 'Mail list for ogsa-bes-wg working group'; ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Mark:
I guess that I am asking that we re-open the issue, then.
Ian.
At 07:47 PM 9/5/2006 -0400, Mark Morgan wrote:
I'm not sure what level of "addressing" is meant here, but my recollection/belief was that it was addressed in the group in so much as the topic was discussed at the last face-to-face and that the appearance of the GetAttributesDocument was the result of that discussion. We haven't as a group discussed the email that Peter sent out yet but it is my belief that doing so is essentially a rehash of discussions previously had.
-Mark
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster Sent: Tuesday, September 05, 2006 1:42 PM To: Mail list for ogsa-bes-wg working group; ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Has Peter's comment been discussed?
He advocates (I believe) that we should not include the GetAttributesDocument operation. Instead, any particular BES should choose (if they wish) to provide access to attributes via an appropriate resource model-specific operations.
* A WS-Transfer-based BES would use GET * A WSRF-based BES would use WS-ResourceProperties * A resource-model-free BES might define a GetAttributesDocument operation * etc.
This seems a good proposal to me.
Ian.
At 03:09 PM 9/2/2006 -0600, Peter G. Lane wrote:
2) Why are we still essentially advocating WS-Transfer's attribute model by having the GetAttributesDocument operation? In my opinion it is not necessary for minimal interop, and makes WS-Transfer's Get operation redundant. Is part of the problem that we haven't defined any interop standards yet?
_______________________________________________________________
Ian Foster -- Weblog: http://ianfoster.typepad.com <http://ianfoster.typepad.com/> <http://ianfoster.typepad.com/> Computation Institute: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> <http://www.ci.uchicago.edu/> & www.ci.anl.gov <http://www.ci.anl.gov/> <http://www.ci.anl.gov/> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org <http://www.globus.org/> <http://www.globus.org/>
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
_______________________________________________________________ Ian Foster -- Weblog: http://ianfoster.typepad.com <http://ianfoster.typepad.com/> Computation Institute: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> & www.ci.anl.gov <http://www.ci.anl.gov/> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org <http://www.globus.org/>
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
I agree with Chris - I never thought of this as a WS-RF versus anything else issue - more an issue with trying to be resource model agnostic. A
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Christopher Smith Sent: Wednesday, September 06, 2006 1:17 PM To: Mail list for ogsa-bes-wg working group Cc: ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Characterizing this issue as WS-RF vs WS-Transfer is misleading. I can't recall any discussions within this group where anybody advocated doing a WS-Transfer rendering for the BES interface. Well ... other than the WS- RF proponents who wrongly assumed that because some (like myself) were against the use of WS-RF, that must mean we were in favour of WS-Transfer. I also don't recall anybody advocating operations for modification, etc such as defined within WS-Transfer. To me this is a discussion of a resource modelling approach (built on WS-RF) vs a non resource modelling approach.
My main reason for not wanting to make use of one of the resource modelling approaches has to do with the burden of implementation. If Platform buys into one of these resource models, we no longer have to implement one simple spec and test compliance of that specification, but we need to implement and test compliance on a suite of specifications, for (in my opinion) no extra benefit. You might say that once you've implemented a resource modelling suite of specifications, you can use it over and over and thus amortize the cost of this implementation. But even at a small cost, it's not one that I'm willing to take, as the implementation of standards specifications is one feature in a sea of features that we implement from product release to product release.
-- Chris
On 06/9/06 07:56, "Peter G. Lane" <lane@mcs.anl.gov> wrote:
If it's about fear of reopening the dialog, then I'd appreciate if someone could at least add comments to the two trackers addressing the issues raised.
Ian can push for reopening this particular issue if he wants; but I just want to know why we're advocating WS-Transfer in spirit if not in name, and why aggregation of resource attributes is not a concern to anyone else. As long as someone has a reason for these issues that I raised in the tracker, I'm fine. I don't expect to get everything to go my way, and I'm open to being convinced of alternate points of view. I just don't like being ignorant, especially when I'll have to implement the spec someday.
On the other hand, if nobody has a good answer for the issues, I think Ian is perfectly valid in asking for it to be reopened as apparently the issues weren't actually addressed as they should have been.
Peter
Mark Morgan wrote:
Well, I guess the thing that confuses me is whether or not it is SOP to re-open an issue that was discussed previously because a new person has re-raised that issue. I'll bow to whatever the majority thinks is best of course, but it seems to me that you can't reopen an issue everytime a new person re-raises it or you risk the possibility of continuously cycling on it. New information should always be considered, but if an issue gets re-raised that has already been discussed fully and voted on, then it doesn't make sense to re-discuss it. Just my 2 cents worth...
-Mark
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster Sent: Tuesday, September 05, 2006 9:39 PM To: Mail list for ogsa-bes-wg working group; 'Mail list for ogsa-bes-wg working group'; ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Mark:
I guess that I am asking that we re-open the issue, then.
Ian.
At 07:47 PM 9/5/2006 -0400, Mark Morgan wrote:
I'm not sure what level of "addressing" is meant here, but my recollection/belief was that it was addressed in the group in so much as the topic was discussed at the last face-to-face and that the appearance of the GetAttributesDocument was the result of that discussion. We haven't as a group discussed the email that Peter sent out yet but it is my belief that doing so is essentially a rehash of discussions previously had.
-Mark
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster Sent: Tuesday, September 05, 2006 1:42 PM To: Mail list for ogsa-bes-wg working group; ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Has Peter's comment been discussed?
He advocates (I believe) that we should not include the GetAttributesDocument operation. Instead, any particular BES should choose (if they wish) to provide access to attributes via an appropriate resource model-specific operations.
* A WS-Transfer-based BES would use GET * A WSRF-based BES would use WS-ResourceProperties * A resource-model-free BES might define a GetAttributesDocument operation * etc.
This seems a good proposal to me.
Ian.
At 03:09 PM 9/2/2006 -0600, Peter G. Lane wrote:
2) Why are we still essentially advocating WS-Transfer's attribute model by having the GetAttributesDocument operation? In my opinion it is not necessary for minimal interop, and makes WS-Transfer's Get operation redundant. Is part of the problem that we haven't defined any interop standards yet?
_______________________________________________________________
Ian Foster -- Weblog: http://ianfoster.typepad.com <http://ianfoster.typepad.com/> <http://ianfoster.typepad.com/> Computation Institute: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> <http://www.ci.uchicago.edu/> & www.ci.anl.gov <http://www.ci.anl.gov/> <http://www.ci.anl.gov/> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org <http://www.globus.org/> <http://www.globus.org/>
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
_______________________________________________________________ Ian Foster -- Weblog: http://ianfoster.typepad.com <http://ianfoster.typepad.com/> Computation Institute: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> & www.ci.anl.gov <http://www.ci.anl.gov/> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org <http://www.globus.org/>
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
But the only reason we were resource agnostic was because there was conflict. We didn't choose to be resource agnostic just because it seemed like a good idea (did we?). There certainly was (are) some who argue against any resource model (eg. Purely stateless services), vs those who would encode some resource identity into an addressing scheme (WS-RF and WS-Transfer). In the end most (all) of this discussion is about whether we should encode identity of state in parameters in the body of the request or we should encode identity of state in the headers not whether there is state or not. Personally, I think that WS-Addressing makes all of this pretty moot, but if shouting at the wind makes us feel better, feel free.... Tom _______________________________________________ Tom Maguire +1(845) 729-4806 -----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Andrew Grimshaw Sent: Wednesday, September 06, 2006 1:48 PM To: 'Mail list for ogsa-bes-wg working group' Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions I agree with Chris - I never thought of this as a WS-RF versus anything else issue - more an issue with trying to be resource model agnostic. A
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Christopher Smith Sent: Wednesday, September 06, 2006 1:17 PM To: Mail list for ogsa-bes-wg working group Cc: ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Characterizing this issue as WS-RF vs WS-Transfer is misleading. I can't recall any discussions within this group where anybody advocated doing a WS-Transfer rendering for the BES interface. Well ... other than the WS- RF proponents who wrongly assumed that because some (like myself) were against the use of WS-RF, that must mean we were in favour of WS-Transfer. I also don't recall anybody advocating operations for modification, etc such as defined within WS-Transfer. To me this is a discussion of a resource modelling approach (built on WS-RF) vs a non resource modelling approach.
My main reason for not wanting to make use of one of the resource modelling approaches has to do with the burden of implementation. If Platform buys into one of these resource models, we no longer have to implement one simple spec and test compliance of that specification, but we need to implement and test compliance on a suite of specifications, for (in my opinion) no extra benefit. You might say that once you've implemented a resource modelling suite of specifications, you can use it over and over and thus amortize the cost of this implementation. But even at a small cost, it's not one that I'm willing to take, as the implementation of standards specifications is one feature in a sea of features that we implement from product release to product release.
-- Chris
On 06/9/06 07:56, "Peter G. Lane" <lane@mcs.anl.gov> wrote:
If it's about fear of reopening the dialog, then I'd appreciate if someone could at least add comments to the two trackers addressing the issues raised.
Ian can push for reopening this particular issue if he wants; but I just want to know why we're advocating WS-Transfer in spirit if not in name, and why aggregation of resource attributes is not a concern to anyone else. As long as someone has a reason for these issues that I raised in the tracker, I'm fine. I don't expect to get everything to go my way, and I'm open to being convinced of alternate points of view. I just don't like being ignorant, especially when I'll have to implement the spec someday.
On the other hand, if nobody has a good answer for the issues, I think Ian is perfectly valid in asking for it to be reopened as apparently the issues weren't actually addressed as they should have been.
Peter
Mark Morgan wrote:
Well, I guess the thing that confuses me is whether or not it is SOP to re-open an issue that was discussed previously because a new person has re-raised that issue. I'll bow to whatever the majority thinks is best of course, but it seems to me that you can't reopen an issue everytime a new person re-raises it or you risk the possibility of continuously cycling on it. New information should always be considered, but if an issue gets re-raised that has already been discussed fully and voted on, then it doesn't make sense to re-discuss it. Just my 2 cents worth...
-Mark
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster Sent: Tuesday, September 05, 2006 9:39 PM To: Mail list for ogsa-bes-wg working group; 'Mail list for ogsa-bes-wg working group'; ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Mark:
I guess that I am asking that we re-open the issue, then.
Ian.
At 07:47 PM 9/5/2006 -0400, Mark Morgan wrote:
I'm not sure what level of "addressing" is meant here, but my recollection/belief was that it was addressed in the group in so much as the topic was discussed at the last face-to-face and that the appearance of the GetAttributesDocument was the result of that discussion. We haven't as a group discussed the email that Peter sent out yet but it is my belief that doing so is essentially a rehash of discussions previously had.
-Mark
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster Sent: Tuesday, September 05, 2006 1:42 PM To: Mail list for ogsa-bes-wg working group; ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Has Peter's comment been discussed?
He advocates (I believe) that we should not include the GetAttributesDocument operation. Instead, any particular BES should choose (if they wish) to provide access to attributes via an appropriate resource model-specific operations.
* A WS-Transfer-based BES would use GET * A WSRF-based BES would use WS-ResourceProperties * A resource-model-free BES might define a GetAttributesDocument operation * etc.
This seems a good proposal to me.
Ian.
At 03:09 PM 9/2/2006 -0600, Peter G. Lane wrote:
2) Why are we still essentially advocating WS-Transfer's attribute model by having the GetAttributesDocument operation? In my opinion it is not necessary for minimal interop, and makes WS-Transfer's Get operation redundant. Is part of the problem that we haven't defined any interop standards yet?
_______________________________________________________________
Ian Foster -- Weblog: http://ianfoster.typepad.com <http://ianfoster.typepad.com/> <http://ianfoster.typepad.com/> Computation Institute: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> <http://www.ci.uchicago.edu/> & www.ci.anl.gov <http://www.ci.anl.gov/> <http://www.ci.anl.gov/> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org <http://www.globus.org/> <http://www.globus.org/>
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
_______________________________________________________________ Ian Foster -- Weblog: http://ianfoster.typepad.com <http://ianfoster.typepad.com/> Computation Institute: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> & www.ci.anl.gov <http://www.ci.anl.gov/> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org <http://www.globus.org/>
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
Tom is right - we choose to be agnostic to avoid the conflict - not because we thought it was a good idea. My only concern with re-opening this can of worms is the additional delay. I am personally not against using the merged model - though I certainly cannot claim to speak for the group. W.R.T. the merged specification I have a proposal. Perhaps we should get the document to public comment NOW with a comment in the document that we are going over to the merged model - and solicit feedback on that. We have got to get this document into public comment or we will spin endlessly. A
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Maguire_Tom@emc.com Sent: Wednesday, September 06, 2006 2:26 PM To: ogsa-bes-wg@ogf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
But the only reason we were resource agnostic was because there was conflict. We didn't choose to be resource agnostic just because it seemed like a good idea (did we?). There certainly was (are) some who argue against any resource model (eg. Purely stateless services), vs those who would encode some resource identity into an addressing scheme (WS-RF and WS-Transfer). In the end most (all) of this discussion is about whether we should encode identity of state in parameters in the body of the request or we should encode identity of state in the headers not whether there is state or not. Personally, I think that WS-Addressing makes all of this pretty moot, but if shouting at the wind makes us feel better, feel free....
Tom
_______________________________________________ Tom Maguire +1(845) 729-4806
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Andrew Grimshaw Sent: Wednesday, September 06, 2006 1:48 PM To: 'Mail list for ogsa-bes-wg working group' Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
I agree with Chris - I never thought of this as a WS-RF versus anything else issue - more an issue with trying to be resource model agnostic.
A
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Christopher Smith Sent: Wednesday, September 06, 2006 1:17 PM To: Mail list for ogsa-bes-wg working group Cc: ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Characterizing this issue as WS-RF vs WS-Transfer is misleading. I can't recall any discussions within this group where anybody advocated doing a WS-Transfer rendering for the BES interface. Well ... other than the WS- RF proponents who wrongly assumed that because some (like myself) were against the use of WS-RF, that must mean we were in favour of WS-Transfer. I also don't recall anybody advocating operations for modification, etc such as defined within WS-Transfer. To me this is a discussion of a resource modelling approach (built on WS-RF) vs a non resource modelling approach.
My main reason for not wanting to make use of one of the resource modelling approaches has to do with the burden of implementation. If Platform buys into one of these resource models, we no longer have to implement one simple spec and test compliance of that specification, but we need to implement and test compliance on a suite of specifications, for (in my opinion) no extra benefit. You might say that once you've implemented a resource modelling suite of specifications, you can use it over and over and thus amortize the cost of this implementation. But even at a small cost, it's not one that I'm willing to take, as the implementation of standards specifications is one feature in a sea of features that we implement from product release to product release.
-- Chris
On 06/9/06 07:56, "Peter G. Lane" <lane@mcs.anl.gov> wrote:
If it's about fear of reopening the dialog, then I'd appreciate if someone could at least add comments to the two trackers addressing the issues raised.
Ian can push for reopening this particular issue if he wants; but I just want to know why we're advocating WS-Transfer in spirit if not in name, and why aggregation of resource attributes is not a concern to anyone else. As long as someone has a reason for these issues that I raised in the tracker, I'm fine. I don't expect to get everything to go my way, and I'm open to being convinced of alternate points of view. I just don't like being ignorant, especially when I'll have to implement the spec someday.
On the other hand, if nobody has a good answer for the issues, I think Ian is perfectly valid in asking for it to be reopened as apparently the issues weren't actually addressed as they should have been.
Peter
Mark Morgan wrote:
Well, I guess the thing that confuses me is whether or not it is SOP to re-open an issue that was discussed previously because a new person has re-raised that issue. I'll bow to whatever the majority thinks is best of course, but it seems to me that you can't reopen an issue everytime a new person re-raises it or you risk the possibility of continuously cycling on it. New information should always be considered, but if an issue gets re-raised that has already been discussed fully and voted on, then it doesn't make sense to re-discuss it. Just my 2 cents worth...
-Mark
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster Sent: Tuesday, September 05, 2006 9:39 PM To: Mail list for ogsa-bes-wg working group; 'Mail list for ogsa-bes-wg working group'; ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Mark:
I guess that I am asking that we re-open the issue, then.
Ian.
At 07:47 PM 9/5/2006 -0400, Mark Morgan wrote:
I'm not sure what level of "addressing" is meant here, but my recollection/belief was that it was addressed in the group in so much as the topic was discussed at the last face-to-face and that the appearance of the GetAttributesDocument was the result of that discussion. We haven't as a group discussed the email that Peter sent out yet but it is my belief that doing so is essentially a rehash of discussions previously had.
-Mark
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster Sent: Tuesday, September 05, 2006 1:42 PM To: Mail list for ogsa-bes-wg working group; ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Has Peter's comment been discussed?
He advocates (I believe) that we should not include the GetAttributesDocument operation. Instead, any particular BES should choose (if they wish) to provide access to attributes via an appropriate resource model-specific operations.
* A WS-Transfer-based BES would use GET * A WSRF-based BES would use WS-ResourceProperties * A resource-model-free BES might define a GetAttributesDocument operation * etc.
This seems a good proposal to me.
Ian.
At 03:09 PM 9/2/2006 -0600, Peter G. Lane wrote:
2) Why are we still essentially advocating WS-Transfer's attribute model by having the GetAttributesDocument operation? In my opinion it is not necessary for minimal interop, and makes WS-Transfer's Get operation redundant. Is part of the problem that we haven't defined any interop standards yet?
_______________________________________________________________
Ian Foster -- Weblog: http://ianfoster.typepad.com <http://ianfoster.typepad.com/> <http://ianfoster.typepad.com/> Computation Institute: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> <http://www.ci.uchicago.edu/> & www.ci.anl.gov <http://www.ci.anl.gov/> <http://www.ci.anl.gov/> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org <http://www.globus.org/> <http://www.globus.org/>
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
_______________________________________________________________ Ian Foster -- Weblog: http://ianfoster.typepad.com <http://ianfoster.typepad.com/> Computation Institute: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> & www.ci.anl.gov <http://www.ci.anl.gov/> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org <http://www.globus.org/>
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
Christopher Smith wrote:
Characterizing this issue as WS-RF vs WS-Transfer is misleading. I can't recall any discussions within this group where anybody advocated doing a WS-Transfer rendering for the BES interface. Well ... other than the WS-RF proponents who wrongly assumed that because some (like myself) were against the use of WS-RF, that must mean we were in favour of WS-Transfer. I also don't recall anybody advocating operations for modification, etc such as defined within WS-Transfer. To me this is a discussion of a resource modelling approach (built on WS-RF) vs a non resource modelling approach.
Just for the record, I wasn't trying to make this into a fairness issue between WSRF and WS-Transfer just because WSRF isn't being equally represented and I'm from the WSRF camp. If some WSRF-like operation was included I would have asked the same question. I also did bring this up before the tracker existed, but nobody seemed interested in discussing it then. That said, whether a discussion was had or not, having this operation makes WS-Transfer partly redundant. That's my main point in all of this. It seemed silly to have two operations doing the exact same thing when minimal interop IMHO doesn't warrant it. In other words, it was a cosmetic gripe.
My main reason for not wanting to make use of one of the resource modelling approaches has to do with the burden of implementation. If Platform buys into one of these resource models, we no longer have to implement one simple spec and test compliance of that specification, but we need to implement and test compliance on a suite of specifications, for (in my opinion) no extra benefit. You might say that once you've implemented a resource modelling suite of specifications, you can use it over and over and thus amortize the cost of this implementation. But even at a small cost, it's not one that I'm willing to take, as the implementation of standards specifications is one feature in a sea of features that we implement from product release to product release.
Fair enough. Out of curiosity, though, if WSRF and WS-Transfer get reconciled, does this mean Platform will still opt not to implement a second spec? If on the other hand they would be willing to implement such a spec, would they be ok with deprecating the GetAttributesDocument operation at that time? Peter
-- Chris
On 06/9/06 07:56, "Peter G. Lane" <lane@mcs.anl.gov> wrote:
If it's about fear of reopening the dialog, then I'd appreciate if someone could at least add comments to the two trackers addressing the issues raised.
Ian can push for reopening this particular issue if he wants; but I just want to know why we're advocating WS-Transfer in spirit if not in name, and why aggregation of resource attributes is not a concern to anyone else. As long as someone has a reason for these issues that I raised in the tracker, I'm fine. I don't expect to get everything to go my way, and I'm open to being convinced of alternate points of view. I just don't like being ignorant, especially when I'll have to implement the spec someday.
On the other hand, if nobody has a good answer for the issues, I think Ian is perfectly valid in asking for it to be reopened as apparently the issues weren't actually addressed as they should have been.
Peter
Mark Morgan wrote:
Well, I guess the thing that confuses me is whether or not it is SOP to re-open an issue that was discussed previously because a new person has re-raised that issue. I'll bow to whatever the majority thinks is best of course, but it seems to me that you can't reopen an issue everytime a new person re-raises it or you risk the possibility of continuously cycling on it. New information should always be considered, but if an issue gets re-raised that has already been discussed fully and voted on, then it doesn't make sense to re-discuss it. Just my 2 cents worth...
-Mark
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster Sent: Tuesday, September 05, 2006 9:39 PM To: Mail list for ogsa-bes-wg working group; 'Mail list for ogsa-bes-wg working group'; ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Mark:
I guess that I am asking that we re-open the issue, then.
Ian.
At 07:47 PM 9/5/2006 -0400, Mark Morgan wrote:
I'm not sure what level of "addressing" is meant here, but my recollection/belief was that it was addressed in the group in so much as the topic was discussed at the last face-to-face and that the appearance of the GetAttributesDocument was the result of that discussion. We haven't as a group discussed the email that Peter sent out yet but it is my belief that doing so is essentially a rehash of discussions previously had.
-Mark
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster Sent: Tuesday, September 05, 2006 1:42 PM To: Mail list for ogsa-bes-wg working group; ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Has Peter's comment been discussed?
He advocates (I believe) that we should not include the GetAttributesDocument operation. Instead, any particular BES should choose (if they wish) to provide access to attributes via an appropriate resource model-specific operations.
* A WS-Transfer-based BES would use GET * A WSRF-based BES would use WS-ResourceProperties * A resource-model-free BES might define a GetAttributesDocument operation * etc.
This seems a good proposal to me.
Ian.
At 03:09 PM 9/2/2006 -0600, Peter G. Lane wrote:
2) Why are we still essentially advocating WS-Transfer's attribute model by having the GetAttributesDocument operation? In my opinion it is not necessary for minimal interop, and makes WS-Transfer's Get operation redundant. Is part of the problem that we haven't defined any interop standards yet?
_______________________________________________________________
Ian Foster -- Weblog: http://ianfoster.typepad.com <http://ianfoster.typepad.com/> <http://ianfoster.typepad.com/> Computation Institute: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> <http://www.ci.uchicago.edu/> & www.ci.anl.gov <http://www.ci.anl.gov/> <http://www.ci.anl.gov/> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org <http://www.globus.org/> <http://www.globus.org/>
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
_______________________________________________________________ Ian Foster -- Weblog: http://ianfoster.typepad.com <http://ianfoster.typepad.com/> Computation Institute: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> & www.ci.anl.gov <http://www.ci.anl.gov/> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org <http://www.globus.org/>
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
On 06/9/06 10:50, "Peter G. Lane" <lane@mcs.anl.gov> wrote:
My main reason for not wanting to make use of one of the resource modelling approaches has to do with the burden of implementation. If Platform buys into one of these resource models, we no longer have to implement one simple spec and test compliance of that specification, but we need to implement and test compliance on a suite of specifications, for (in my opinion) no extra benefit. You might say that once you've implemented a resource modelling suite of specifications, you can use it over and over and thus amortize the cost of this implementation. But even at a small cost, it's not one that I'm willing to take, as the implementation of standards specifications is one feature in a sea of features that we implement from product release to product release.
Fair enough. Out of curiosity, though, if WSRF and WS-Transfer get reconciled, does this mean Platform will still opt not to implement a second spec? If on the other hand they would be willing to implement such a spec, would they be ok with deprecating the GetAttributesDocument operation at that time?
I believe that the reconciliation will have a positive effect, in that it will give tooling vendors a better feeling about these specifications, and hopefully they will implement some abstractions that we can use. My position is that I want to stay out of the WS tools business. I have no problem with updating specs later, including the deprecation of operations, etc. I see it as the natural evolution of the standard. -- Chris
My main reason for not wanting to make use of one of the resource
modelling
approaches has to do with the burden of implementation. If Platform buys into one of these resource models, we no longer have to implement one simple spec and test compliance of that specification, but we need to implement and test compliance on a suite of specifications, for (in my opinion) no extra benefit. You might say that once you've implemented a resource modelling suite of specifications, you can use it over and over and thus amortize
Just for the record WS-RF and WS-Transfer convergence has been published. It is called WS-ResourceTransfer and it was published 8/31/06... http://devresource.hp.com/drc/specifications/wsrt/index.jsp http://www-128.ibm.com/developerworks/library/specification/ws-wsrt/ http://msdn.microsoft.com/webservices/webservices/understanding/specs/defaul t.aspx?pull=/library/en-us/dnglobspec/html/wsmgmtspecindex.asp?frame=true#ws mgmtspecindex_ws-rt Tom _______________________________________________ Tom Maguire +1(845) 729-4806 -----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Christopher Smith Sent: Wednesday, September 06, 2006 1:53 PM To: Mail list for ogsa-bes-wg working group Cc: ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions On 06/9/06 10:50, "Peter G. Lane" <lane@mcs.anl.gov> wrote: the
cost of this implementation. But even at a small cost, it's not one that I'm willing to take, as the implementation of standards specifications is one feature in a sea of features that we implement from product release to product release.
Fair enough. Out of curiosity, though, if WSRF and WS-Transfer get reconciled, does this mean Platform will still opt not to implement a second spec? If on the other hand they would be willing to implement such a spec, would they be ok with deprecating the GetAttributesDocument operation at that time?
I believe that the reconciliation will have a positive effect, in that it will give tooling vendors a better feeling about these specifications, and hopefully they will implement some abstractions that we can use. My position is that I want to stay out of the WS tools business. I have no problem with updating specs later, including the deprecation of operations, etc. I see it as the natural evolution of the standard. -- Chris -- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
Hi; This topic got discussed at today's BES conference call and the reasoning for having a GetAttributesDocument operation in the core BES interface was re-derived from the previous time(s) that the topic was discussed. The argument goes like this: * Clients will want to retrieve some or all of the attributes that a BES exposes. If GetAttributesDocument is in a separate "rendering" port type that composes with the BES-Factory and BES-Management port types then clients will need to determine which rendering port type is actually available from any given BES. * In order to determine which renderings a BES implements you have to query it. That requires that there be some operation in the core client BES interface (i.e. BES-Factory) that will retrieve the attribute that describes which renderings are available by some means or another. (I can't actually find an attribute in the spec that exports that information, by-the-way.) * If that operation just returns the attribute that describes which renderings are available then the normal case behavior for a client querying multiple BESes in order to see what state they are in (e.g. to decide which is most lightly loaded) will involve two message round trips: one to retrieve the rendering information and one to then retrieve the desired attributes. That seems like a bad design from a software and systems engineering point-of-view. One might argue that clients will be written to amortize the cost of the rendering query over multiple attribute retrievals, but that presumes a fairly heavy-weight client model that may not be appropriate in all cases. Note also that BES service implementers will be implementing a retrieval operation of some sort that is rendering-independent in any case. So from an implementation complexity point-of-view, they have to pay the development cost of implementing some sort of retrieval operation in the BES-Factory port type in any case. * The only way to make this common case into a single message exchange is to have a single rendering that is universally implemented. Tom Maguire has pointed out that WS-ResourceTransfer has now been published and could be considered a candidate for such a universal rendering interface. But using this rendering interface implies that BES implementers must implement ALL of that interface in order to be able to employ its Get operation. Furthermore, they must do so in a manner that complies with the standard and its compliance requirements and tests (have those been published yet?). So, in order to get a simple Get operation, a BES implementer must also implement Put and Create operations, whose semantics are potentially controversial (I haven't read the new spec to see how they deal with atomicity questions of creating/updating multiple properties) and, in general, a spec that is 30 pages long - 46 pages if you count the appendices. That's arguably substantially more work than simply implementing a single GetAttributesDocument operation that is unencumbered by any other spec's requirements. * So, in order to enable BES clients to efficiently (i.e. using only a single message exchange) retrieve all the attributes of a BES without having to require BES service implementers to implement a non-trivially sized second spec, most of which is not necessary for BES, it was decided to include a GetAttributesDocument operation in the BES-Factory port type. * Inclusion of this operation makes the BES specification inherently resource model-free, but it does not preclude a BES from redundantly exporting its attribute information by means of other (composed) rendering port types, such as WSRF, WS-Transfer, or WS-ResourceTransfer as well. This would allow clients that wish to exploit the reuse possibilities of such renderings to do so while imposing only a very minor additional service implementation burden for BES implementers - namely to implement the GetAttributesDocument operation instead of a GetRenderingAttribute operation. Marvin. -----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Peter G. Lane Sent: Wednesday, September 06, 2006 10:51 AM To: Mail list for ogsa-bes-wg working group Cc: ogsa-bes-wg@ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions Christopher Smith wrote:
Characterizing this issue as WS-RF vs WS-Transfer is misleading. I can't
recall any discussions within this group where anybody advocated doing a
WS-Transfer rendering for the BES interface. Well ... other than the WS-RF
proponents who wrongly assumed that because some (like myself) were against
the use of WS-RF, that must mean we were in favour of WS-Transfer. I also
don't recall anybody advocating operations for modification, etc such as
defined within WS-Transfer. To me this is a discussion of a resource
modelling approach (built on WS-RF) vs a non resource modelling approach.
Just for the record, I wasn't trying to make this into a fairness issue between WSRF and WS-Transfer just because WSRF isn't being equally represented and I'm from the WSRF camp. If some WSRF-like operation was included I would have asked the same question. I also did bring this up before the tracker existed, but nobody seemed interested in discussing it then. That said, whether a discussion was had or not, having this operation makes WS-Transfer partly redundant. That's my main point in all of this. It seemed silly to have two operations doing the exact same thing when minimal interop IMHO doesn't warrant it. In other words, it was a cosmetic gripe.
My main reason for not wanting to make use of one of the resource modelling
approaches has to do with the burden of implementation. If Platform buys
into one of these resource models, we no longer have to implement one simple
spec and test compliance of that specification, but we need to implement and
test compliance on a suite of specifications, for (in my opinion) no extra
benefit. You might say that once you've implemented a resource modelling
suite of specifications, you can use it over and over and thus amortize the
cost of this implementation. But even at a small cost, it's not one that I'm
willing to take, as the implementation of standards specifications is one
feature in a sea of features that we implement from product release to
product release.
Fair enough. Out of curiosity, though, if WSRF and WS-Transfer get reconciled, does this mean Platform will still opt not to implement a second spec? If on the other hand they would be willing to implement such a spec, would they be ok with deprecating the GetAttributesDocument operation at that time? Peter
-- Chris
On 06/9/06 07:56, "Peter G. Lane" <lane@mcs.anl.gov> wrote:
If it's about fear of reopening the dialog, then I'd appreciate if someone
could at least add
comments to the two trackers addressing the issues raised.
Ian can push for reopening this particular issue if he wants; but I just want
to know why we're
advocating WS-Transfer in spirit if not in name, and why aggregation of
resource attributes is not a
concern to anyone else. As long as someone has a reason for these issues that
I raised in the
tracker, I'm fine. I don't expect to get everything to go my way, and I'm open
to being convinced of
alternate points of view. I just don't like being ignorant, especially when
I'll have to implement
the spec someday.
On the other hand, if nobody has a good answer for the issues, I think Ian is
perfectly valid in
asking for it to be reopened as apparently the issues weren't actually
addressed as they should have
been.
Peter
Mark Morgan wrote:
Well, I guess the thing that confuses me is whether or not it is SOP to
re-open an issue that was discussed previously because a new person has
re-raised that issue. I'll bow to whatever the majority thinks is best of
course, but it seems to me that you can't reopen an issue everytime a new
person re-raises it or you risk the possibility of continuously cycling on
it. New information should always be considered, but if an issue gets
re-raised that has already been discussed fully and voted on, then it
doesn't make sense to re-discuss it. Just my 2 cents worth...
-Mark
-----Original Message-----
From: ogsa-bes-wg-bounces@ogf.org
[mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster
Sent: Tuesday, September 05, 2006 9:39 PM
To: Mail list for ogsa-bes-wg working group; 'Mail list for
ogsa-bes-wg working group'; ogsa-bes-wg@ggf.org
Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Mark:
I guess that I am asking that we re-open the issue, then.
Ian.
At 07:47 PM 9/5/2006 -0400, Mark Morgan wrote:
I'm not sure what level of "addressing" is meant here, but my
recollection/belief was that it was addressed in the
group in so much as the
topic was discussed at the last face-to-face and that
the appearance of the
GetAttributesDocument was the result of that
discussion. We haven't as a
group discussed the email that Peter sent out yet but
it is my belief that
doing so is essentially a rehash of discussions previously had.
-Mark
-----Original Message-----
From: ogsa-bes-wg-bounces@ogf.org
[mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster
Sent: Tuesday, September 05, 2006 1:42 PM
To: Mail list for ogsa-bes-wg working group;
ogsa-bes-wg@ggf.org
Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
Has Peter's comment been discussed?
He advocates (I believe) that we should not include the
GetAttributesDocument operation. Instead, any particular BES
should choose (if they wish) to provide access to attributes
via an appropriate resource model-specific operations.
* A WS-Transfer-based BES would use GET
* A WSRF-based BES would use WS-ResourceProperties
* A resource-model-free BES might define a
GetAttributesDocument operation
* etc.
This seems a good proposal to me.
Ian.
At 03:09 PM 9/2/2006 -0600, Peter G. Lane wrote:
2) Why are we still essentially advocating
WS-Transfer's attribute model by having the
GetAttributesDocument operation? In my opinion it is not
necessary for minimal interop, and makes WS-Transfer's Get
operation redundant. Is part of the problem that we haven't
defined any interop standards yet?
_______________________________________________________________
Ian Foster -- Weblog: http://ianfoster.typepad.com
<http://ianfoster.typepad.com/> Computation Institute:
www.ci.uchicago.edu <http://www.ci.uchicago.edu/>
www.ci.anl.gov <http://www.ci.anl.gov/>
Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439
Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637
Tel: +1 630 252 4619 --- Globus Alliance:
www.globus.org <http://www.globus.org/>
--
ogsa-bes-wg mailing list
ogsa-bes-wg@ogf.org
_______________________________________________________________
Ian Foster -- Weblog: http://ianfoster.typepad.com
<http://ianfoster.typepad.com/> Computation Institute:
www.ci.uchicago.edu <http://www.ci.uchicago.edu/> &
www.ci.anl.gov <http://www.ci.anl.gov/>
Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439
Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637
Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org
--
ogsa-bes-wg mailing list
ogsa-bes-wg@ogf.org
--
ogsa-bes-wg mailing list
ogsa-bes-wg@ogf.org
--
ogsa-bes-wg mailing list
ogsa-bes-wg@ogf.org
Marvin: Isn't this ignoring the very real possibility that multiple renderings exist because clients are not willing to support one rendering or the other? So, they may not care in practice what rendering a BES service is using, because the resource selection process would have already chosen a service instance that is compatible with the client's abilities. There isn't an "extra" round-trip if you assume that discovery included type discovery. And I personally have a hard time imagining that you would want to do discovery and selection without having resolved the actual message compatibility question, since it is one of the most basic "viability" questions for whether this client's job can go there... It sounds to me that people still want to define two different classes of rendering. One that does not take advantage of any newer web service frameworks, and one that does. Saying we've merged these renderings by making one that doesn't use the frameworks is not addressing this conflict in goals, but pre-supposing that people do not actually care to build systems using the frameworks. karl -- Karl Czajkowski karlcz@univa.com
participants (8)
-
Andrew Grimshaw -
Christopher Smith -
Ian Foster -
Karl Czajkowski -
Maguire_Tom＠emc.com -
Mark Morgan -
Marvin Theimer -
Peter G. Lane