- ogsa-hpcp-wg - lists.ogf.org

Changes to factory attributes document
by Christopher Smith 06 Dec '06

06 Dec '06

Hi all, I just wanted to send out a couple of sample XML documents for discussion in tomorrow's call. The first attachment is an example of a factory attributes document, as is reflected with the current schema (including all the issues we've seen having to do with multiple xsd:any, etc). I've also added some sample "extensions" as placeholders. The second attachment reflects some schema changes that I'd like to propose. One is just a re-factoring to avoid the use of XML Schema extension as discussed in last week's call. I've also added a proposed new element to the basic resource (resource name) which I'd like to see added. -- Chris

1 0

On the use of WS-BaseFaults (raised in today's HPC Profile call)
by Marty Humphrey 29 Nov '06

29 Nov '06

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(a)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(a)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(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 <http://www.ci.uchicago.edu/> . Globus Alliance: www.globus.org <http://www.globus.org/> .

3 2

BES Faults
by Christopher Smith 29 Nov '06

29 Nov '06

Hi all, Just wanted to start some discussion on how to render faults for BES. The first thing to state is that I'm assuming the use of SOAP 1.1 for messaging, as this is the version referenced in the WS-I BP version 1.1. Please correct me if I'm wrong.... The second is that for now I'm ignoring WS-BaseFaults, as I think it would be very difficult to reach consensus on it's use in a short amount of time. The BES specification defines a few faults: (contained in SOAP Fault element in response) - NotAcceptingNewActivities - UnsupportedJSDLVersionFault - UnsupportedFeatureFault (contained in a response body) - ActivityDoesNotExistFault - CantApplyOperationToCurrentState <-- implied in doc as a todo We can render these in one of two ways: 1. We define new faultcode elements for these faults, and the detail can provide a higher level of information if needed. I'm not clear on how easy this is for most people from the tooling point of view. It would also require the WSDL to reflect the new fault codes (is this true?). 2. We define a set of fault elements that can either be used in the detail element, or on their own in some response elements. These fault elements wouldn't be "anyType", but would just be empty complexTypes. I prefer number 2 as this is quite straightforward from a tooling support point of view. Here are some examples of the various fault messages. Actual SOAP faults: <soap:Fault xmlns:soap="http://schemas.xmlsoap.org/soap/envelope"> <faultcode>soap:Server</faultcode> <faultstring>This BES is not accepting new activites now</faultstring> <detail> <bes:NotAcceptingNewActivities xmlns:bes="..."/> </detail> </soap:Fault> <soap:Fault xmlns:soap="http://schemas.xmlsoap.org/soap/envelope"> <faultcode>soap:Client</faultcode> <faultstring>Sorry ... I don't get it</faultstring> <detail> <bes:UnsupportedFeatureFault xmlns:bes="..."> <bes:UnsupportedElement name="jsdl-posix:POSIXApplication"/> </bes:UnsupportedFeatureFault> </detail> </soap:Fault> Faults in responses would be done using a type like: <xsd:complexType name="TerminateActivityResponseType"> <xsd:sequence> <xsd:element ref="bes-factory:ActivityIdentifier"/> <xsd:element name="Cancelled" type="xsd:boolean"/> <xsd:element ref="soap:Fault" minOccurs="0"/> <-- SOAP 1.1 fault </xsd:sequence> </xsd:complexType> So you'd get: <bes:TerminateActivityResponse xmlns:bes="..."> <bes:ActivityIdentifier>EPR</bes:ActivityIdentifier> <bes:Cancelled>false</bes:Cancelled> <soap:Fault> <faultcode>soap:Client</faultcode> <faultstring>That activity doesn't exist</faultstring> <detail><bes:ActivityDoesNotExistFault/></detail> </soap:Fault> </bes:TerminateActivityResponse> <bes:TerminateActivityResponse xmlns:bes="..."> <bes:ActivityIdentifier>EPR</bes:ActivityIdentifier> <bes:Cancelled>false</bes:Cancelled> <soap:Fault> <faultcode>soap:Client</faultcode> <faultstring>That activity doesn't exist</faultstring> <detail><bes:CantApplyOperationToCurrentState/></detail> </soap:Fault> </bes:TerminateActivityResponse> Comments? -- Chris

2 2

HPC Profile Call Minutes - 11/29
by Richard Ciapala 29 Nov '06

29 Nov '06

Attendees * Luigi * Andrew * Mark * Duane * Marty * Glenn * Chris * Joel * Vivian * Stephen * Peter * Rich Notes * We decided to work through the BES issues in Marty's email over the next couple of weeks with the goal of submitting BES to public comment before Christmas * Andrew will send Chris v27 of the BES specification which will include the changes from the last face-to-face. This is the version we will work from. * We will work from the Axis 1.4 BES WSDL from wiki * We discussed having FactoryResourceAttributesDocumentType encapsulate BasicFactoryResourceAttributesDocumentType instead of derive from it. No one had any issues with this. * We discussed having GetFactoryAttributesDocument take any type of filter to limit the amount of data returned. Rich will write up more detail on this and send it out to mailing list. If we go down this route, there should also be a way for the service to publish the filters it supports. * Chris start writing up solutions to the other BES issues mentioned and send them out to the mailing list * Discussed use of WS-BaseFaults. Need to research what the previous issues were. Thanks

1 0

Reminder: HPC Profile conf call Wed Nov 29 8am Pacific time: post-SC2006 discussion
by Marty Humphrey 29 Nov '06

29 Nov '06

Folks, A reminder: we'll have a call tomorrow at 8am Pacific to discuss what we learned from the implementations of the HPC Profile for SC2006. We'll shortly send out telephone call info... -- Marty Quoting Marty Humphrey <humphrey(a)cs.virginia.edu>: > Folks, > > First, I want to THANK EVERYBODY for their hard work leading up to and > including the SC2006 interop demofest! I think we made tremendous progress > and I want to continue the momentum inside the BES, JSDL, and HPC Profile > working groups!!!! > > I propose that we have a conference call on Wed Nov 29 at 8am US Pacific > time to discuss what we each learned while we implemented the HPC Profile, > and where we as a group go from here. Please let me know if you can make > this call (a few people said that Fridays were not good, so we're trying a > different day -- but note: this is not necessarily proposed as a weekly > call, this is just a "special" call to discuss things while SC is still in > our minds). > > Rich Ciapala, Chris Smith and I tried to identify the unresolved issues that > we either directly encountered or someone raised on the mailing list. We > have certainly tried to capture everything but we probably missed a few > things. > > > Audience > > Topic > > > HPCP WG > > Finalize security additions to profile > > > BES WG > > Finalize faults for all operations > > > BES WG > > Limit amount of data that can be returned from GetAttributesDocument > > > HPCP WG > > Tools for which the schemas should work cleanly with > > > JSDL WG > > RangeValue_Type element clarifications > > * If a single min value and a single max value are to be specified, > should it be done with Boundary_Type's or a single Range_Type? > > * I assume Exact takes precedence over any specified Boundary_Type > or Range_Type's since Exact is a MUST and the others are optional. > > > BES WG > > Finalize Fault element's type for multiple response operations. We changed > this from soap:Fault to xsd:anyType for the demo. > > > HPCP WG > > Finalize list of dependent WS-I specs > > > BES WG > > Use of QNAMEs in GetAttributesDocument response > > > HPCP WG > > Data staging support > > > BES WG > > Clarify operations semantics (i.e. TerminateActivity) > > So, please let me know if you can make this call on Wed Nov 29. Also, let's > start email discussions on the appropriate mailing lists to attempt to > resolve some of these (or at least prioritize these and identify new ones) > before the call next Wednesday. > > Thanks again -- I think everything's coming together really well!!! > > -- Marty > > > > > > > > > > > > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

2 1

HPC Profile conf call Wed Nov 29 8am Pacific time: post-SC2006 discussion
by Marty Humphrey 22 Nov '06

22 Nov '06

Folks, First, I want to THANK EVERYBODY for their hard work leading up to and including the SC2006 interop demofest! I think we made tremendous progress and I want to continue the momentum inside the BES, JSDL, and HPC Profile working groups!!!! I propose that we have a conference call on Wed Nov 29 at 8am US Pacific time to discuss what we each learned while we implemented the HPC Profile, and where we as a group go from here. Please let me know if you can make this call (a few people said that Fridays were not good, so we're trying a different day -- but note: this is not necessarily proposed as a weekly call, this is just a "special" call to discuss things while SC is still in our minds). Rich Ciapala, Chris Smith and I tried to identify the unresolved issues that we either directly encountered or someone raised on the mailing list. We have certainly tried to capture everything but we probably missed a few things. Audience Topic HPCP WG Finalize security additions to profile BES WG Finalize faults for all operations BES WG Limit amount of data that can be returned from GetAttributesDocument HPCP WG Tools for which the schemas should work cleanly with JSDL WG RangeValue_Type element clarifications . If a single min value and a single max value are to be specified, should it be done with Boundary_Type's or a single Range_Type? . I assume Exact takes precedence over any specified Boundary_Type or Range_Type's since Exact is a MUST and the others are optional. BES WG Finalize Fault element's type for multiple response operations. We changed this from soap:Fault to xsd:anyType for the demo. HPCP WG Finalize list of dependent WS-I specs BES WG Use of QNAMEs in GetAttributesDocument response HPCP WG Data staging support BES WG Clarify operations semantics (i.e. TerminateActivity) So, please let me know if you can make this call on Wed Nov 29. Also, let's start email discussions on the appropriate mailing lists to attempt to resolve some of these (or at least prioritize these and identify new ones) before the call next Wednesday. Thanks again -- I think everything's coming together really well!!! -- Marty

2 1

Re: [ogsa-hpcp-wg] [jsdl-wg] HPC Profile conf call Wed Nov 29 8am Pacific time: post-SC2006 discussion
by Andreas Savva 22 Nov '06

22 Nov '06

> I do not think that is a correct assumption. I am not familiar with > the "MUST" issue you are focusing on. What version of what document > are you referencing here? I think Marty is referring to the HPC Profile document. It has (if I remember correctly) a statement that 'exact' must be implemented by all HPC Profile compliant JSDL implementations while the other range elements are recommended. I was unsure why the table had "JSDL-WG" against this issue since I think it is an issue for the HPC Profile and not for the JSDL spe. Andreas Karl Czajkowski wrote: > On Nov 21, Marty Humphrey modulated: >> RangeValue_Type element clarifications >> >> -- If a single min value and a single max value are to be >> specified, should it be done with Boundary_Type’s or a single >> Range_Type? > > They are semantically equivalent. The boundary parts are for defining > semi-spaces, which cannot be expressed with the range pair. > > >> -- I assume Exact takes precedence over any specified >> Boundary_Type or Range_Type’s since Exact is a MUST and the others are >> optional. > > I do not think that is a correct assumption. I am not familiar with > the "MUST" issue you are focusing on. What version of what document > are you referencing here? > > The entire range-value element is meant to be expressing a disjunction > of simple semi-space, exact, or interval constraints. So, if I > expressed: > > OR [the combining logic of all range value elements] > x > 0 [as a boundary sub-element] > x = 4 [as an exact match sub-element] > 5 < x < 7 [as a range sub-element] > > it would be semantically equivalent to just the first constraint x > > 0. > > > karl >

1 0

Re: [ogsa-hpcp-wg] [ogsa-wg] HPC profile questionaire draft
by Subramaniam, Ravi 22 Nov '06

22 Nov '06

Hi Andrew, One question could be "Is the profile as it stands complete from your perspective? At least for the focus/business areas or types of customers that you plan to implement for?" The motivation is that depending on the verticals (e.g. financial, pharma) there may be some issue that may need to be resolved to be successful. In this way at least some target constituencies that can best benefit from what is currently there can be determined. We can also begin more targeted campaign at the OGF level towards consumers/customers/end-users and providers in that segments. Building traction in one of more specific segments may help build momentum for others. Ravi ________________________________ From: ogsa-wg-bounces(a)ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of Maguire_Tom(a)emc.com Sent: Friday, November 17, 2006 11:12 AM To: grimshaw(a)cs.virginia.edu; ogsa-wg(a)gridforum.org; ogsa-hpcp-wg(a)ggf.org; ogsa-bes-wg(a)ggf.org Subject: Re: [ogsa-wg] HPC profile questionaire draft Is there enough specificity in the profile for your engineers to successfully implement? If not what do you need? Tom _______________________________________________ Tom Maguire +1(845) 729-4806 ________________________________ From: ogsa-wg-bounces(a)ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of Andrew Grimshaw Sent: Friday, November 17, 2006 10:21 AM To: 'Ogsa-Wg'; ogsa-hpcp-wg(a)ggf.org; ogsa-bes-wg(a)ggf.org Subject: [ogsa-wg] HPC profile questionaire draft All, At the OGSA F2F I was tasked with coming up with a series of questions about the HPC profile experiences to go into a zoomerang, so that an experiences paper could be generated - either for HPC profile, JSDL, and/or BES. Here is a start. Note - comment on/add questions. Do NOT answer them!!! That will come later. 1) Will the HPC-Profile be useful to your organization/company? Explain. 2) Will you engineer your products to be hpc-profile compliant? 3) In your opinion, are there any unresolved ambiguities? Explain? 4) Thoughts on the next profile? Anything in particular from BES or JSDL (or other specification) that you would like to include. 5) Approximately how many person-days did it take you to implement the HPC-profile? 6) What would you change in the HPC-profile? Why? Remember this is a STRAWMAN ONLY for discussion! Please add, suggest removal, or modify the above. A Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw(a)cs.virginia.edu

7 12

Re: [ogsa-hpcp-wg] [OGSA-BES-WG] SC2006 was great! What Next?
by Steven Newhouse 18 Nov '06

18 Nov '06

> See attached. While I agree we need to think about next steps... I would like to see BES and the HPCP be submitted to the editor and go into public comment - if they are ready for that. Is there any work that needs to be done NOW as opposed to things we might want to do as further development? Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Mob:+44(0)7920489420 Tel:+44(0)23 80598789 Director, Open Middleware Infrastructure Institute-UK (OMII-UK) c/o Suite 6005, Faraday Building (B21), Highfield Campus, University of Southampton, Highfield, Southampton, SO17 1BJ, UK

2 1

HPC profile questionaire draft
by Andrew Grimshaw 17 Nov '06

17 Nov '06

All, At the OGSA F2F I was tasked with coming up with a series of questions about the HPC profile experiences to go into a zoomerang, so that an experiences paper could be generated - either for HPC profile, JSDL, and/or BES. Here is a start. Note - comment on/add questions. Do NOT answer them!!! That will come later. 1) Will the HPC-Profile be useful to your organization/company? Explain. 2) Will you engineer your products to be hpc-profile compliant? 3) In your opinion, are there any unresolved ambiguities? Explain? 4) Thoughts on the next profile? Anything in particular from BES or JSDL (or other specification) that you would like to include. 5) Approximately how many person-days did it take you to implement the HPC-profile? 6) What would you change in the HPC-profile? Why? Remember this is a STRAWMAN ONLY for discussion! Please add, suggest removal, or modify the above. A Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw(a)cs.virginia.edu

2 1