August 2006 - ogsa-bes-wg

Latest version of BES draft (v22)
by Marvin Theimer 31 Aug '06

31 Aug '06

Hi; Enclosed is the latest version of the BES draft. This is an updated version of the draft I sent out last week. This draft is essentially the same as last week's except for some cleanup and movement of the extension material out of the appendix and into the main document. I have not yet added Ellen's material to an appendix, but intend to still do so. Marvin.

1 0

RE: [ogsa-bes-wg] OGSA BES Meeting and WS-BaseFaults
by Ian Foster 31 Aug '06

31 Aug '06

Where do things stand with the WS-BF issue? At 04:14 AM 8/24/2006 -0700, Marvin Theimer wrote: >Hi; > >Apologies for not responding until now. I will try to cover the topic of >WS-BaseFaults and potential alternatives on today's BES telecon call. I >will also send out an email about the topic afterwards. > >Marvin. >________________________________ >From: owner-ogsa-bes-wg(a)ggf.org On Behalf Of Ian Foster >Sent: Wednesday, August 23, 2006 8:14 PM >To: Pulsipher_Darren(a)emc.com; ogsa-bes-wg(a)ggf.org >Subject: Re: [ogsa-bes-wg] OGSA BES Meeting > >I can't make the call tomorrow. It seems important to address the >WS-BaseFaults issue. I've proposed that we organize a call with the >Microsoft people who say that they cannot use WS-BS, so that we can >understand their concerns and also have an opportunity for a WS-BS >advocate to explain the benefits of WS-BS. I haven't seen a response to >that proposal. > > >At 05:23 AM 8/22/2006 -0400, Pulsipher_Darren(a)emc.com wrote: >When: Thursday, August 24, 2006 10:30 AM-11:30 AM (GMT-06:00) Central Time >(US & Canada). >Where: On Line > >*~*~*~*~*~*~*~*~*~* > >You are invited to join a meeting hosted by MR DARREN PULSIPHER. Meeting >details are listed below. > >Instant Meeting Details: >------------------------------- >Aug. 24, 2006 >11:30 am EDT >8:30 am PDT > >If you are unable to join with the above link, please dial in using one of >the phone numbers below: > >UNITED KINGDOM Toll Number: +44-20-7108-6316 >USA Toll Free Number: 866-880-0098 > >Participant Passcode: 3425861 > >Instant Net Conference Details: >------------------------------- >Meeting Number: SW124357 >Meeting Passcode: GGF >Meeting Host: MR DARREN PULSIPHER > >Join Instructions for Instant Net Conference: > >1. Join the meeting now: >http://www.mymeetings.com/emc/nc/join.php?i=SW124357&p=GGF&t=c >2. Enter the required fields. >3. Indicate that you have read the Privacy Policy. >4. Click on Proceed. > >EMC² >Darren Pulsipher >Director of Engineering >Grid Business Unit >501-442-9074 >Email: Pulsipher_Darren(a)emc.com <mailto:Pulsipher_Darren@emc.com> > >_______________________________________________________________ >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/> _______________________________________________________________ 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

3 2

RE: [ogsa-bes-wg] OGSA BES Meeting and WS-BaseFaults
by Ian Foster 31 Aug '06

31 Aug '06

Marvin: Sorry I missed that. This seems like a good solution. Ian. At 07:11 PM 8/30/2006 -0700, Marvin Theimer wrote: >Hi; > > > >My email from yesterday (see copy below) summarizes where I believe things >are. People should please speak up if they disagree with my perception of >things. J > > > >Marvin. > > > > > >Hi; > > > >Apologies for replying to this email thread so late. > > > >At the BES telecon call last week we decided to not require WS-BaseFaults >in the BES specification. As Tom Maguire pointed out in his emails >(below), there are issues with requiring that only WS-BF faults be >returned, including that one must be prepared to accept non WS-BF faults >from intermediaries in any case. I had made a statement in email and on >telecon calls that people I had queried at Microsoft had also raised >various concerns related to tooling. Included below is part of an email >from a colleague that sheds a bit more light on the issues that have >people concerned. > > > >----------------------------- > >Here is my quick skim through: > > > >Main goal of the spec is to introduce base type for detail element of the >fault > >1) Not clear what value base fault type provides over SOAP 1.2 Fault >, except for d) > >a. Originator EPR: > > i. > Originator EPR is always known via Addressing facilities. > > ii. Mix > in of infrastructure details into application message parts: application > may not know what its EPR is. > >b. ErrorCode: > > i. > Limited duplicate of SOAP1.2 fault codes and sub-codes. Uri associated > with fault should be represented by the wsa:Action > >c. Description: > > i. > duplicates SOAP 1.2 Fault reason > >d. FaultCause: > > i. > this is the only valuable piece IMHO common representation of nested > exceptions. > > ii. > This can be provided by using open content model for SOAP1.2 Fault detail . > > > >2) Child elements of Base fault are not namespace qualified this >leads to known threats of having unqualified elements. Does not map to >DataContract. > > > >3) Should not require name=faulton the message there is no need for >this and this blocks existing WSDL-generators. > > > >4) Folks need to define Action uris for individual fault messages, >since Addressing is assumed to be used. > > > >Our WSDLs generated by default for Faults will not adhere to 2 and 3. > >----------------------------------------------- > > > >Points 2 and 3 are the key issues: > >· Point 2 implies a security issue and Im leery about introducing >anything that even hints of a security problem. > >· Point 2 also references the fact that Microsoft (and others) >tooling is headed in the direction of generating (and analyzing) contracts >over web service protocols. Making a web service protocol into a >statically analyzable contract implies that you either explicitly expose >all the possible nested fault details implying that youve tightly coupled >things and made them brittle with respect to internal service behaviors >that might change over time or that you have protocol content that cant be >determined until runtime. > >· Point 3 is a good example of WS-BF breaking the tooling. > > > >Marvin. > > > > > >---------- >From: Ian Foster [mailto:foster@mcs.anl.gov] >Sent: Wednesday, August 30, 2006 7:03 PM >To: Marvin Theimer; Pulsipher_Darren(a)emc.com; ogsa-bes-wg(a)ggf.org >Subject: RE: [ogsa-bes-wg] OGSA BES Meeting and WS-BaseFaults > > > >Where do things stand with the WS-BF issue? > > >At 04:14 AM 8/24/2006 -0700, Marvin Theimer wrote: > >Hi; > >Apologies for not responding until now. I will try to cover the topic of >WS-BaseFaults and potential alternatives on today's BES telecon call. I >will also send out an email about the topic afterwards. > >Marvin. >________________________________ >From: owner-ogsa-bes-wg(a)ggf.org On Behalf Of Ian Foster >Sent: Wednesday, August 23, 2006 8:14 PM >To: Pulsipher_Darren(a)emc.com; ogsa-bes-wg(a)ggf.org >Subject: Re: [ogsa-bes-wg] OGSA BES Meeting > >I can't make the call tomorrow. It seems important to address the >WS-BaseFaults issue. I've proposed that we organize a call with the >Microsoft people who say that they cannot use WS-BS, so that we can >understand their concerns and also have an opportunity for a WS-BS >advocate to explain the benefits of WS-BS. I haven't seen a response to >that proposal. > > >At 05:23 AM 8/22/2006 -0400, Pulsipher_Darren(a)emc.com wrote: >When: Thursday, August 24, 2006 10:30 AM-11:30 AM (GMT-06:00) Central Time >(US & Canada). >Where: On Line > >*~*~*~*~*~*~*~*~*~* > >You are invited to join a meeting hosted by MR DARREN PULSIPHER. Meeting >details are listed below. > >Instant Meeting Details: >------------------------------- >Aug. 24, 2006 >11:30 am EDT >8:30 am PDT > >If you are unable to join with the above link, please dial in using one of >the phone numbers below: > >UNITED KINGDOM Toll Number: +44-20-7108-6316 >USA Toll Free Number: 866-880-0098 > >Participant Passcode: 3425861 > >Instant Net Conference Details: >------------------------------- >Meeting Number: SW124357 >Meeting Passcode: GGF >Meeting Host: MR DARREN PULSIPHER > >Join Instructions for Instant Net Conference: > >1. Join the meeting now: >http://www.mymeetings.com/emc/nc/join.php?i=SW124357&p=GGF&t=c >2. Enter the required fields. >3. Indicate that you have read the Privacy Policy. >4. Click on Proceed. > >EMC² >Darren Pulsipher >Director of Engineering >Grid Business Unit >501-442-9074 >Email: Pulsipher_Darren(a)emc.com <mailto:Pulsipher_Darren@emc.com> > >_______________________________________________________________ >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/> > >_______________________________________________________________ >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 > > _______________________________________________________________ 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

1 0

RE: [ogsa-bes-wg] Re: [ogsa-hpcp-wg] Minor BES issue
by Ian Foster 31 Aug '06

31 Aug '06

+1 At 06:59 PM 8/30/2006 -0700, Marvin Theimer wrote: >Hi; > > > >A question to address is what the interpretation is of having an operation >request receive only a subset of response elements in its reply. Consider >TerminateActivities: what are the failure semantics of having it succeed >(i.e. be successfully applied) to only a subset of activities? Presumably >the client wants back a vector of return information that describes >exactly what happened to each activity; i.e. they will want a vector that >contains either a success or a fault element for each activity that was >listed in the input vector rather than a vector containing just the >success elements or just the failure elements. For GetActivityStatus and >GetJSDLDocuments one might argue that its OK to get back information about >a subset of requested activities. But I would expect that clients would >still want to receive a failure element back explaining what happened for >each activity for which information could not be returned. > > > >Thus, it seems to me that in all cases clients will want to receive back a >vector response of the same length as the input vector. In particular, I >would advocate that they should expect one of the following responses back: > >· A fault response if the operation as a whole could not be handled >e.g. if the client is not authorized to make the request. > >· A response that consists of an info-set that contains a vector of >elements, where the number of elements equals the number of activities >specified in the input vector argument to the operation request. Each >element of the vector should be either a successelement or a fault >response element. Which input vector element the response element refers >to is unambiguously determined by the EPR returned in the response element >(as pointed out by Peter). An interesting question is whether the EPR >field is really needed since vector input arguments are only available for >operations on existing activities and one could request that the vector >order of the response message correspond to the vector order of the >request message. If we were to go down this path then we could simplify >the schema of the response messages. > > > >If BES were to take the approach outlined above then the HPC Profile >specification would contain a restriction that simply says that HPC >Profile-compliant services MUST support input vectors of length 1 and MAY >support vector lengths greater than 1 or MAY return an overall fault >response of not-implemented for vector lengths greater than 1. > > > >Thoughts? > > > >Marvin. > > > >-----Original Message----- >From: owner-ogsa-bes-wg(a)ggf.org [mailto:owner-ogsa-bes-wg@ggf.org] On >Behalf Of Peter G. Lane >Sent: Wednesday, August 30, 2006 8:27 AM >To: Donal K. Fellows >Cc: ogsa-bes-wg(a)ggf.org; ogsa-hpcp-wg(a)ggf.org >Subject: [ogsa-bes-wg] Re: [ogsa-hpcp-wg] Minor BES issue > > > >Donal K. Fellows wrote: > > > An issue came up recently during discussions in the HPC Profile WG, and > > > that was that the BES spec should require that the lengths of the input > > > vectors and output vectors in the operations GetActivitiesStatus, > > > TerminateActivities and GetJSDLDocuments should/must be the same length > > > (assuming no faults, naturally). Otherwise the responses might be a > > > subset of the expected ones. Maybe there are some other restrictions > > > that ought to be imposed (same order, referring to the same things thatt > > > the input referred to, etc.) but it was the length issue that came up > > > (since that's the aspect that's going to be profiled). We agreed that > > > this sort of restriction belongs in the base BES spec though; it's too > > > fundamental to belong in the Profile. > > > >The schema types for the output vector elements have EPR fields that >associate each element with an > >input vector element. So it doesn't really matter if the response is a >subset of the expected set or > >is out of order. I'm assuming that this is the point of including the EPR >fields. Is there a more > >fundamental reason for pushing for such a restriction? I don't have a >strong opinion either way. I'm > >just curious about how this is interpreted as "bad". > > > >Peter > > > > > > > > Donal. > > > > > _______________________________________________________________ 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

1 0

Minor BES issue
by Donal K. Fellows 31 Aug '06

31 Aug '06

An issue came up recently during discussions in the HPC Profile WG, and that was that the BES spec should require that the lengths of the input vectors and output vectors in the operations GetActivitiesStatus, TerminateActivities and GetJSDLDocuments should/must be the same length (assuming no faults, naturally). Otherwise the responses might be a subset of the expected ones. Maybe there are some other restrictions that ought to be imposed (same order, referring to the same things thatt the input referred to, etc.) but it was the length issue that came up (since that's the aspect that's going to be profiled). We agreed that this sort of restriction belongs in the base BES spec though; it's too fundamental to belong in the Profile. Donal.

3 2

Telecon at the usual time this week - Thursday 11:30 Eastern
by Andrew Grimshaw 30 Aug '06

30 Aug '06

All, A call at the usual time. Dial-in info to follow. Proposed agenda: Agenda bashing Approve minutes Trackers If another draft is forthcoming - discuss updates in call A Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw(a)cs.virginia.edu

1 0

Updated: OGSA BES Meeting
by Pulsipher_Darren＠emc.com 30 Aug '06

30 Aug '06

When: Thursday, August 31, 2006 11:30 AM-12:30 PM (GMT-05:00) Eastern Time (US & Canada). Where: On Line *~*~*~*~*~*~*~*~*~* You are invited to join a meeting hosted by MR DARREN PULSIPHER. Meeting details are listed below. Instant Meeting Details: ------------------------------- Aug. 31, 2006 11:30 am EDT 8:30 am PDT If you are unable to join with the above link, please dial in using one of the phone numbers below: UNITED KINGDOM Toll Number: +44-20-7108-6316 USA Toll Free Number: 866-880-0098 Participant Passcode: 3425861 Instant Net Conference Details: ------------------------------- Meeting Number: SW124357 Meeting Passcode: GGF Meeting Host: MR DARREN PULSIPHER Join Instructions for Instant Net Conference: 1. Join the meeting now: http://www.mymeetings.com/emc/nc/join.php?i=SW124357&p=GGF&t=c 2. Enter the required fields. 3. Indicate that you have read the Privacy Policy. 4. Click on Proceed. EMC² Darren Pulsipher Director of Engineering Grid Business Unit 501-442-9074 Email: Pulsipher_Darren(a)emc.com <mailto:Pulsipher_Darren@emc.com>

1 0

Is there a telecon call this week?
by Marvin Theimer 30 Aug '06

30 Aug '06

I haven't seen one announced. There are still topics and trackers to work through. Thanks, Marvin.

1 0

RE: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg
by Ian Foster 30 Aug '06

30 Aug '06

Marvin: David's proposal, which is realized in the current draft, is that we define BES to just have "GetStatus" and "GetProperties" operations (as well as CreateActivity etc.). We can then compose WS-Transfer operations or WSRF operations, if desired, in a particular BES implementation. This seems to me to be a really nice solution to the "problem" that we thought we had, in that it avoids the need for multiple renderings. The one tricky issue is the rendering of faults. In the current BES document, we use WS-BaseFaults. You report that the Microsoft WS team has problems with that. I don't think we should let this be a show stopper, as I don't think it is essential that we use WS-BaseFaults in BES. At the same time, WS-BaseFaults was introduced for a reason. Thus I'd like to propose that we proceed as follows: a) We set up a phone call with the Microsoft WS team and the WS-BaseFaults guys to talk this over, in case it turns out that we can in fact all agree that WS-BaseFaults is useful. b) In the (likely) case that the Microsoft WS team still doesn't want to see WS-BaseFaults included, we check with the BES team that it is ok to use a different fault model for the BES core vs. the specs that might be composed with the BES core, such as WSRF. Thoughts? Ian. At 05:17 PM 8/16/2006 -0700, Marvin Theimer wrote: >Hi; > > > >Another comment/question on Dave Snellings proposal: I dont really >understand how it avoids distinct renderings since it is still the case >that we have at least 3 different WSDLs, one per rendering option: > >· WSRF version that employs WS-ResourceProperties, etc. > >· WS-Transfer version that employs WS-Transfer, etc. > >· Resource model-free version that employs an explicit QueryStatus >operation (and potentially additional QueryFoo operations). > > > >It is certainly the case that there is a coreset of operations that is >common to all 3 interface choices and we should certainly write the spec >that way. But dont we still end up with 3 different rendering versions? > > > >Marvin. > > > >---------- >From: Ian Foster [mailto:foster@mcs.anl.gov] >Sent: Friday, August 04, 2006 2:20 PM >To: Marvin Theimer; ogsa-bes-wg(a)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. > _______________________________________________________________ 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

3 3

RE: [ogsa-wg] OGSA F2F meeting agenda on Sept. 14 & 15
by Marvin Theimer 29 Aug '06

29 Aug '06

Hi; I will only be able to attend the F2F meetings on Thursday as I have to be back in Redmond on Friday the 15th. I'd like to hold an HPC Profile session on Thursday, if possible. Parts of that session would very probably involve BES and JSDL matters as they relate to the HPC Profile. Thanks, Marvin. ________________________________________ From: owner-ogsa-wg(a)ggf.org On Behalf Of Hiro Kishimoto Sent: Tuesday, August 22, 2006 12:33 AM To: OGSA WG Subject: [ogsa-wg] OGSA F2F meeting agenda on Sept. 14 & 15 Hi all, GGF18 and back-to-back OGSA meeting are just around the corner and we need to finalize meeting agenda very soon. The following is current proposal and if you have any request or comment, please let me know ASAP. We will review and finalize meeting agenda at the upcoming Thursday call. Also, if you plan to come (or dial-in) but your name is not on the attendee list, please let me know. You should be on the list to enter facility. https://forge.gridforum.org/sf/go/wiki1555?nav=1 Thursday afternoon (2:30-6pm) * A joint EMS/Data session (Dave and Andreas, 1-2hr depending on people's availability) o Since many Data members will be leaving on Thursday it would be good to arrange some time early on Thursday. * Info Model (Ellen and Fred, 2H or half day) o agenda is overflow from work that will not get done during the 2 GGF sessions o first draft of base model objects for HPC/BES/JSDL o probably XQuery examples. Friday morning (8am-noon) * OGSA general session (Tom and Hiro, 2H) o OGSA direction and priority o document status review o winter F2F schedule o telecon schedule * JSDL session (Steve McGough, 1-2 hr) o Bashing out ideas for JSDL 2.0 Friday afternoon (1-4pm) * OGSA-DMI Update (Michel Drescher, 1hr) o This session is to update the OGSA-WG and all interested parties on the status of the OGSA-DMI work. It is expected that a first draft of the functional interface is drafted at GGF18. * OGSA-RSS (Donal Fellows, ??) o discuss the EPS and its relation to the rest of the EMS arch -- Hiro Kishimoto

2 5