[ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg

[Peter G. Lane]

Marvin Theimer wrote:
> 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.

Out of curiosity, how then does Microsoft render it's faults? I looked at the WS-Transfer spec and 
it appears to not have any way of communicating faults at all, so that wasn't very helpful.

Peter

> 
>  
> 
> Sorry to be the bearer of bad news,
> 
> Marvin.
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Ian Foster [mailto:foster at mcs.anl.gov]
> *Sent:* Friday, August 04, 2006 2:20 PM
> *To:* Marvin Theimer; ogsa-bes-wg at 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/>.
>        
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3804 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060817/c59dca08/attachment.bin