On the use of WS-BaseFaults (raised in today's HPC Profile call)
Folks, FYI: Here's the relevant info from Marvin Theimer on the subject of WS-BaseFaults (dated Aug 16). -- Marty _____ From: owner-ogsa-bes-wg@ggf.org [mailto:owner-ogsa-bes-wg@ggf.org] On Behalf Of Marvin Theimer Sent: Wednesday, August 16, 2006 8:12 PM To: Ian Foster; ogsa-bes-wg@ggf.org Subject: RE: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg Ian, I've asked the relevant people in Microsoft about the issue of using WS-BaseFaults and their response has been essentially that its use would cause problems with our tooling and that in any case the current WS-Transfer doesn't use it. So, trying to standardize all the renderings of BES to use WS-BaseFaults would NOT be a good idea. I think we're stuck with having each rendering employ its own notion of how to handle faults. Sorry to be the bearer of bad news, Marvin. _____ From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: Friday, August 04, 2006 2:20 PM To: Marvin Theimer; ogsa-bes-wg@ggf.org Subject: Re: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg Marvin: I've claimed the pen on the document, but have been finding it hard to find time to make a lot of progress. I will try to do some work on it tomorrow morning. That said, I want to mention an important development that Dave Snelling may or may not have mentioned on calls. Dave argues that we can avoid the need for distinct renderings by defining our interfaces carefully. The basic idea, as I understand it, is that: a) the "core interface" has the basic operations for creating jobs, modifying their status, etc., and an operation for grabbing all of the factory state; b) then, if desired, a WSRF service (for example) can also implement the WS-ResourceProperties, WS-ResourceLifetime, WS-BaseNotification, operations; c) while a WS-Resource service would implement the WS-Resource equivalents of those. So we exploit the power of interface composition to avoid the need for separate bindings. The only problematic issue, as I understand it, is that of faults. The question is how we render faults. The WSRF binding must (by the spec) use WS-BaseFaults. If we can all agree to use that, then we are ok. If not, then we still have problems. Ian. At 01:29 PM 8/4/2006 -0700, Marvin Theimer wrote: x-ms-exchange-organization-recipient-p2-type: To Content-Type: text/plain; charset="us-ascii" Hi; The HPC Profile (HPCP) work depends critically on BES. The recent face-to-face meeting at Argonne made substantial progress in terms of reshaping the proposed BES specification in a way that would make it suitable for supporting the HPCP on top of it. Are there plans to generate a new revision of the BES specification draft in the near future? As soon as the revised version comes into existence we'll be able to seriously start doing the actual HPCP work (which will take place on the hpcp-ogsa-wg mailing list and in weekly telecom calls that will be starting shortly). Since the HPCP WG is effectively gated on this revised spec, having a draft of a revised spec sometime in the next week or so would be really helpful. I would be willing to help rewrite the BES spec if that would be useful to the BES WG. Marvin. _______________________________________________________________ Ian Foster, Director, Computation Institute Argonne National Laboratory & University of Chicago 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. Web: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> . Globus Alliance: www.globus.org <http://www.globus.org/> .
Following that exchange, I talked to various other people who I thought might care about this (e.g., Globus people) and everyone seemed happy with not using WS-BaseFaults. Marty Humphrey wrote:
Folks,
FYI: Here's the relevant info from Marvin Theimer on the subject of WS-BaseFaults (dated Aug 16).
-- Marty
------------------------------------------------------------------------
*From:* owner-ogsa-bes-wg@ggf.org [mailto:owner-ogsa-bes-wg@ggf.org] *On Behalf Of *Marvin Theimer *Sent:* Wednesday, August 16, 2006 8:12 PM *To:* Ian Foster; ogsa-bes-wg@ggf.org *Subject:* RE: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg
Ian,
I've asked the relevant people in Microsoft about the issue of using WS-BaseFaults and their response has been essentially that its use would cause problems with our tooling and that in any case the current WS-Transfer doesn't use it. So, trying to standardize all the renderings of BES to use WS-BaseFaults would NOT be a good idea. I think we're stuck with having each rendering employ its own notion of how to handle faults.
Sorry to be the bearer of bad news,
Marvin.
------------------------------------------------------------------------
*From:* Ian Foster [mailto:foster@mcs.anl.gov] *Sent:* Friday, August 04, 2006 2:20 PM *To:* Marvin Theimer; ogsa-bes-wg@ggf.org *Subject:* Re: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg
Marvin:
I've claimed the pen on the document, but have been finding it hard to find time to make a lot of progress. I will try to do some work on it tomorrow morning.
That said, I want to mention an important development that Dave Snelling may or may not have mentioned on calls. Dave argues that we can avoid the need for distinct renderings by defining our interfaces carefully. The basic idea, as I understand it, is that:
a) the "core interface" has the basic operations for creating jobs, modifying their status, etc., and an operation for grabbing all of the factory state;
b) then, if desired, a WSRF service (for example) can also implement the WS-ResourceProperties, WS-ResourceLifetime, WS-BaseNotification, operations;
c) while a WS-Resource service would implement the WS-Resource equivalents of those.
So we exploit the power of interface composition to avoid the need for separate bindings.
The only problematic issue, as I understand it, is that of faults. The question is how we render faults. The WSRF binding must (by the spec) use WS-BaseFaults. If we can all agree to use that, then we are ok. If not, then we still have problems.
Ian.
At 01:29 PM 8/4/2006 -0700, Marvin Theimer wrote:
x-ms-exchange-organization-recipient-p2-type: To Content-Type: text/plain; charset="us-ascii"
Hi;
The HPC Profile (HPCP) work depends critically on BES. The recent face-to-face meeting at Argonne made substantial progress in terms of reshaping the proposed BES specification in a way that would make it suitable for supporting the HPCP on top of it. Are there plans to generate a new revision of the BES specification draft in the near future? As soon as the revised version comes into existence we'll be able to seriously start doing the actual HPCP work (which will take place on the hpcp-ogsa-wg mailing list and in weekly telecom calls that will be starting shortly).
Since the HPCP WG is effectively gated on this revised spec, having a draft of a revised spec sometime in the next week or so would be really helpful. I would be willing to help rewrite the BES spec if that would be useful to the BES WG.
Marvin.
_______________________________________________________________ Ian Foster, Director, Computation Institute Argonne National Laboratory & University of Chicago 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. Web: www.ci.uchicago.edu <http://www.ci.uchicago.edu/>. Globus Alliance: www.globus.org <http://www.globus.org/>.
------------------------------------------------------------------------
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
-- Ian Foster, Director, Computation Institute Argonne National Laboratory & University of Chicago 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. Web: www.ci.uchicago.edu. Globus Alliance: www.globus.org.
"Not use WS-BaseFaults" is different than having "each rendering employ its own notion of how to handle faults". Chucking WS- BaseFaults is fine. But BES still needs to concisely define faults for its various operations in an interoperable way. Unless you view it as acceptable that BES implementations are only interoperable when everything goes perfectly... -Steve On Nov 29, 2006, at 5:02 PM, Ian Foster wrote:
Following that exchange, I talked to various other people who I thought might care about this (e.g., Globus people) and everyone seemed happy with not using WS-BaseFaults.
Marty Humphrey wrote:
Folks,
FYI: Here’s the relevant info from Marvin Theimer on the subject of WS-BaseFaults (dated Aug 16).
-- Marty
From: owner-ogsa-bes-wg@ggf.org [mailto:owner-ogsa-bes-wg@ggf.org] On Behalf Of Marvin Theimer Sent: Wednesday, August 16, 2006 8:12 PM To: Ian Foster; ogsa-bes-wg@ggf.org Subject: RE: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg
Ian,
I’ve asked the relevant people in Microsoft about the issue of using WS-BaseFaults and their response has been essentially that its use would cause problems with our tooling and that in any case the current WS-Transfer doesn’t use it. So, trying to standardize all the renderings of BES to use WS-BaseFaults would NOT be a good idea. I think we’re stuck with having each rendering employ its own notion of how to handle faults.
Sorry to be the bearer of bad news,
Marvin.
From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: Friday, August 04, 2006 2:20 PM To: Marvin Theimer; ogsa-bes-wg@ggf.org Subject: Re: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg
Marvin:
I've claimed the pen on the document, but have been finding it hard to find time to make a lot of progress. I will try to do some work on it tomorrow morning.
That said, I want to mention an important development that Dave Snelling may or may not have mentioned on calls. Dave argues that we can avoid the need for distinct renderings by defining our interfaces carefully. The basic idea, as I understand it, is that:
a) the "core interface" has the basic operations for creating jobs, modifying their status, etc., and an operation for grabbing all of the factory state;
b) then, if desired, a WSRF service (for example) can also implement the WS-ResourceProperties, WS-ResourceLifetime, WS- BaseNotification, operations;
c) while a WS-Resource service would implement the WS-Resource equivalents of those.
So we exploit the power of interface composition to avoid the need for separate bindings.
The only problematic issue, as I understand it, is that of faults. The question is how we render faults. The WSRF binding must (by the spec) use WS-BaseFaults. If we can all agree to use that, then we are ok. If not, then we still have problems.
Ian.
At 01:29 PM 8/4/2006 -0700, Marvin Theimer wrote:
x-ms-exchange-organization-recipient-p2-type: To Content-Type: text/plain; charset="us-ascii"
Hi;
The HPC Profile (HPCP) work depends critically on BES. The recent face-to-face meeting at Argonne made substantial progress in terms of reshaping the proposed BES specification in a way that would make it suitable for supporting the HPCP on top of it. Are there plans to generate a new revision of the BES specification draft in the near future? As soon as the revised version comes into existence we'll be able to seriously start doing the actual HPCP work (which will take place on the hpcp-ogsa-wg mailing list and in weekly telecom calls that will be starting shortly).
Since the HPCP WG is effectively gated on this revised spec, having a draft of a revised spec sometime in the next week or so would be really helpful. I would be willing to help rewrite the BES spec if that would be useful to the BES WG.
Marvin.
_______________________________________________________________ Ian Foster, Director, Computation Institute Argonne National Laboratory & University of Chicago 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. Web: www.ci.uchicago.edu. Globus Alliance: www.globus.org.
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http:// www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
-- Ian Foster, Director, Computation Institute Argonne National Laboratory & University of Chicago 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. Web: www.ci.uchicago.edu. Globus Alliance: www.globus.org. -- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
participants (3)
-
Ian Foster -
Marty Humphrey -
Steve Tuecke