- ogsa-bes-wg - lists.ogf.org

[Fwd: [ogsa-wg] BES Comments]
by Hiro Kishimoto 28 Nov '06

28 Nov '06

Hi all, Paul Strong, you may remember him as GGF18 keynote speaker, asks me to forward his comments on BES spec to OGSA-BES-WG list. Thanks, -- Hiro Kishimoto -------- Original Message -------- Subject: [ogsa-wg] BES Comments Date: Tue, 21 Nov 2006 11:18:25 -0700 From: Strong, Paul <pstrong(a)ebay.com> To: <ogsa-bes-wg(a)ogf.org>, <ogsa-wg(a)ogf.org> All, I have been attempting to catch up on BES and was reading the v1.0 document. I have some questions and comments. Please note that I have no context from meetings or discussions about BES so please forgive my ignorance, I may be missing important context or details :o) i) Why are there 2 client focused interfaces (3 interfaces in total)? It is very natural for there to be 2 interfaces to a service/component, one focused on delivering client functionality and one for manageability. It is also natural to minimize the number of interfaces and the calls across them so as to aid maintainability. It would appear to me that the difference between the two BES client interfaces is that one allows activities to be created and for collections of activities to be monitored and managed. The other is focused on individual activities, but includes very similar functionality. There seems to be a lot of commonality. What are the reasons for them not being combined? Indeed as I read further I note that BES-Activity exposes no operations, so perhaps this interface is being deprecated and the document is in the process of being edited? ii) Why does the state model not end in one terminated state? Are there any real differences between the 3 enumerated end states other than how the activity ended up in the state? iii) Also it seems somewhat counter intuitive that if one is going to have three termination states, one should end up in the one state which reflects both success and failure (Finished) and a separate one for failures that prevent the activity from exiting in a controlled fashion. It seems like the transitions to the terminated state should be something like - a. Completed Successfully b. Failed c. Cancelled iv) Is there any notion of a retry, given that the state machine captures failure? Or perhaps rescheduling? For example one could imagine additional useful transitions - a. Pending to Pending - i.e. rescheduling b. Running to Pending - i.e. failed/retrying Having these in the base profile or basic model would enable greater flexibility in implementing future profiles where one could request that the BES container implement retries or allow rescheduling. Or are you categorically stating that users will never be able to reschedule or request automatic retries. Again if this is the case, it should probably be explicitly stated. I would actually urge you to make the base specification as broad as possible in terms of the acceptable state changes at this level to avoid unnecessarily constraining yourself down the line. I think this is especially important given what is stated in 4.2. v) Labeling of the state transitions would be most helpful, together with the adoption of standard UML statechart representation. Included is a state transition diagram which includes a few additional transitions which may, or may not be helpful/appropriate. :o) vi) 4.2 - State Specialization really seems to be indicating that this specification makes no assumptions with respect to sub-states that may be incorporated within an implementation but that such sub-states are acceptable as long as they do not introduce new state transitions between the standard, specified states. It would be very helpful to simply state this before all of the examples. vii) Do you expect to extend the BES model to activities that are not binaries running on operating systems? Regards Paul -- ogsa-wg mailing list ogsa-wg(a)ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg

2 1

Re: [OGSA-BES-WG] [ogsa-wg] BES Comments
by Donal K. Fellows 24 Nov '06

24 Nov '06

Strong, Paul wrote: > vii) Do you expect to extend the BES model to activities > that are not binaries running on operating systems? Such activity extensions do fit some of the ideas that have been floating around in the JSDL group for a few years now. In particular, activities might include things like database queries, webservice invokations, and data transfers. None of those three have had any serious effort into design of a real JSDL extension though, and there are some complexities in the understanding of the meaning of the concept of a resource in some of the cases. Given that, and the fact that BES is a JSDL enactment engine spec, I'd say that extending in the way you suggest is distinctly possible. The priority of what gets done when depends on who turns up to do the work, as always... :-) Donal.

1 0

Paul Strong's HPC usecase DAG
by Hiro Kishimoto 24 Nov '06

24 Nov '06

Hi all, I've upload Paul's DAG and State Transition UML diagram to the GridForege which was reviewed on Nov. 20th call. https://forge.gridforum.org/sf/go/doc14034 > 1) Powerpoint of one (of several) possible DAGs for > HPC. This is one of potentially several different renderings. > > 2) HPC State Transition In UML - UML representation of > the diagram in the BES v1.0 doc > > 3) HPC State Transition 2 In UML - UML pulling this > together with EGA Ref Model showing an implied state (Defined) and > implied transitions. Thanks, -- Hiro Kishimoto

1 0

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

4 3

Re: [OGSA-BES-WG] [ogsa-wg] HPC profile questionaire draft
by Ian Foster 22 Nov '06

22 Nov '06

I want to understand what people think we need for real interop. The HPC Profile as currently defined seems far from adequate for that purpose. We've mention staging and security as two issues. There are presumably others. Ian. Subramaniam, Ravi wrote: > > 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 > > > > ------------------------------------------------------------------------ > > -- > ogsa-wg mailing list > ogsa-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/ogsa-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.

5 10

SC2006 was great! What Next?
by Andrew Grimshaw 18 Nov '06

18 Nov '06

All, See attached. A Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw(a)cs.virginia.edu

2 2

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

3 2

about the username and password of other Endpoints
by Liang Zhong 01 Nov '06

01 Nov '06

Dear All, We have implemented all the interfaces defined in the BES draft v26. Now we want to test the interoperation between other BES implementation and our client. Could you all kindly tell me the username and the password of your endpoint? Thank you very much~ Best Regards, Liang ZHONG Grid Computing Research Group Institute of Advanced Computing Technology, Beihang University Tel: +86 10 8231 6262 Fax: +86 10 8231 6796 Addr: Room 507, Building G,The New Main Building, 37# Xueyuan Rd., Haidian District, Beijing 100083, PRC

1 0

Some type questions
by Christopher Smith 28 Oct '06

28 Oct '06

Hi all, I'm wondering about some of the element types in FactoryResourceAttributesDocumentType. Specifically, should LocalResourceManagerType and NamingProfile be changed to xsd:string? I guess I'm not sure whether to put QNames, or an "expanded name" (I believe it's called). Should it be: <NamingProfile xmlns:besnaming="http://schemas.ggf.org/bes/2006/08/bes/naming"> besnaming:BasicWSAddressing </NamingProfile> or <NamingProfile> {http://schemas.ggf.org/bes/2006/08/bes/naming}BasicWSAddressing </NamingProfile> If it's supposed to be the second, then we can't use a QName, since it doesn't fit the proper syntax. I don't think there is an actual default type for expanded name, so xsd:string should suffice. Comments? -- Chris

2 1

Re: [OGSA-BES-WG] BES schema/wsdl
by Vivian Li 26 Oct '06

26 Oct '06

> -----Original Message----- > From: Peter G. Lane [mailto:lane@mcs.anl.gov] > Sent: 26 October 2006 15:20 > To: Vivian Li > Cc: ogsa-bes-wg(a)ogf.org > Subject: Re: BES schema/wsdl > > Vivian Li wrote: > > Its only a matter of convention, and, it surly make life easier when > > talking about debug the tooling, (of course you can say this is out of > > the scope for now), but for the long run, it is a better practice, and > > the modification - only a cut/paste job. > > I don't see how it makes debugging tooling easier. I also haven't seen a > compelling argument to be > able to say it is inherently a better practice. But as I said, if it's a > trend that the working > group wants to follow, fine. Regardless, until I see a convincing argument > to the contrary, I'm > sticking with my belief that it's better from an organizational point of > view (think object > oriented) to encapsulate in the WSDL document the set of schema types and > elements that have no > relevance outside of that WSDL. Exactly - all the data types, including WSDL message types, (complexType & elements) that potentially will be generated as objects, should all go to the schema, WSDL document is only for messages and portTypes. I think that is a better organization. Its your call. > Peter > > > Vivian > >> -----Original Message----- > >> From: Peter G. Lane [mailto:lane@mcs.anl.gov] > >> Sent: 24 October 2006 16:55 > >> To: Vivian Li > >> Cc: ogsa-bes-wg(a)ogf.org > >> Subject: Re: BES schema/wsdl > >> > >> I argued against this, actually, because the types that are in the > > WSDL > >> don't have any applicability > >> outside of the WSDL. That said, if the rest of the group thinks that > >> convention is enough to > >> overlook that, I'm not going to complain. We're trying to avoid large > >> changes like this so we can > >> release the spec for public review, so my vote would still be to leave > > it > >> alone regardless. > >> > >> Peter > >> > >> Vivian Li wrote: > >>> Another suggestion while browsing the BES schema/wsdl, it might be > >>> easier to maintain if the data types in the schema and the wsdl are > >>> separated completely, e.g. move the "Message Types" in the schema > >>> section from the wsdl to the schema file, it has been kind of > > convention > >>> in all the other WGs. > >>> > >>> Vivian > >>> > >

4 3