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

The up-to-date specification?
by Piotr Domagalski 20 Feb '08

20 Feb '08

Hi all, I'm implementing an OGSA-BES service and I've encountered some requirements that are unfortunately not clear to me: 1. The BES-Management port doesn't allow any faults to be throwed - so how should I notify the client that he is not authorized to perform this call? 2. Generally, the fault semantics are unclear to me, i.e. when should I use the fault directly in SOAP response and when should I put it into the response message. My questions are almost exactly the same as in https://forge.gridforum.org/sf/go/artf6066?nav=1 Any chance on getting answers to that? 3. I'm willing to extend the state model. Where should I add appropriate operations then (e.g. to suspend an activity)? BES-Factory? Is there any guidelines on that? 4. Finally, where should I look for the most up-to-date specification? Is the GFD.108.pdf at ogf.org the only source of the latest specification? As far as I can see in the tracker, there were some changes scheduled, but it seems to me they haven't gone into the pdf doc. -- Piotr Domagalski

5 13

***SPAM*** Incorrect state name in GFD.108
by Steven Newhouse 04 Nov '07

04 Nov '07

FYI - We can pick up on this before final publishing. Tracker: BES V1.0 Title: Incorrect state name in GFD 108 Description: In section 4 we describe the BES state model - including the terminal state. In the bes-factory.xsd we talk instead of the Cancelled state. Need to change GFD 108 from Terminated to Cancelled. Editorial change only.

1 0

Fodder for tomorrows discussion
by Andrew Grimshaw 31 Oct '07

31 Oct '07

1 0

error responses from BES
by Glenn Wasson 29 Oct '07

29 Oct '07

Hey all, I'm trying to interpret the BES document's text on throwing errors in cases where the input vector is of length 1 (all that is required by HPCBP). Section 6.2 of the BES v1.0 spec says: The GetActivityStatuses, TerminateActivities, and GetActivityDocuments operations take a vector of activity EPRs as input and operate on all the referenced activities. Since an input vector may contain EPRs that are either unknown to a BES or for which the BES cannot execute the requested operation, the following failure semantics MUST be provided by a compliant BES: . If a request fails for some reason that applies to all the specified activities-e.g., due to an authorization fault-then the BES MUST respond with an appropriate fault response message. . If a request can succeed for one or more of the specified activities then the BES MUST respond with a vector of response elements, where each element corresponds to the equivalent activity designated in the input EPR vector. Each response element MUST be either an element describing the results of the request, as applied to the designated activity, or a SOAP-1.1 fault element describing why the request could not be applied to the designated activity (e.g., because the EPR could not be resolved to any known activity within the BES). My interpretation of this is that if one of these operations takes a vector of length 1, the first bullet says that a failure (which by definition applies to all specified activities) allows me to simply return a soap fault. However, reading the text of the actual sections for those methods (6.2.2, 6.2.3, 6.2.4) it seems that even for vectors of length 1, I should return any fault information inside a, for example, GetActivityStatusesResponse message. Further, the WSDL shown in the BES spec for (we'll again use this as an example) GetActivityStatuses is: <wsdl:operation name="GetActivityStatuses"> <soap:operation soapAction="http://schemas.ggf.org/bes/2006/08/besfactory/BESFactoryPortType /GetActivityStatuses" /> <wsdl:input name="GetActivityStatuses"> <soap:body use="literal" /> </wsdl:input> <wsdl:output name="GetActivityStatusesResponse"> <soap:body use="literal" /> </wsdl:output> <wsdl:fault name="UnknownActivityIdentifierFault"> <soap:fault name="UnknownActivityIdentifierFault" use="literal" /> </wsdl:fault> </wsdl:operation> To me, the <wsdl:fault> element indicates that it is legitimate to throw an UnknownActivityIdentifierFault "directly", i.e. not inside the Fault element of a GetActivityStatusesResponse message. So, my questions are: 1. should it be the case that the only permissible response from a BES for the GetActivityStatuses (or similar) method is a GetActivityStatusesResponse message (which would then contain appropriate faults)? - in this case, it seems that the WSDL should be changed and the text in 6.2 clarified 2. or should we allow cases where faults can be returned directly? - in which case the text of 6.2.2 (and 6.2.3 and 6.2.4) should be clarified 3. or is the UnknownActivityIdentifierFault special and so that one can be thrown directly, while faults of other types need to be inside a GetActivityStatusResponse message? - this seems like a strange option to me. Not sure what our ability is to change the BES text based on its point in the OGF document pipeline, but at this point I'm trying to figure out what to do for interop. Glenn

2 1

JSDL Survey - Feedback request
by Andreas Savva 28 Sep '07

28 Sep '07

[Apologies for cross-posting... again] The JSDL-WG has started a survey to collect feedback from JSDL implementators. This survey is part of an effort that we expect to lead to an experience document---required by OGF to take GFD.56 from proposed recommendation to recommendation. If you have implemented JSDL 1.0 and would like to provide us with feedback could you please download the survey template (MS Word file), fill it in and email it to either Steve McGough <asm(a)doc.ic.ac.uk> or myself. Please feel free to contact us if you have any questions or comments on the survey. Your help is appreciated. Survey template: https://forge.gridforum.org/sf/go/doc14644?nav=1 The experience report will be one of the topics we'll be discussing at OGF21. Thanks. -- Andreas Savva Fujitsu Laboratories Ltd

1 0

JSDL-WG - Activity schema requirements session at OGF21
by Andreas Savva 19 Sep '07

19 Sep '07

[With apologies for the massive cross-post... Do forward if I have missed anyone.] At OGF21 the JSDL-WG is planning a session on Activity schema requirements. JSDL addresses submission-time requirements but there is clearly a need for more. BES has taken a step forward in defining an ActivityDocument element that encapsulates a JSDL document; for use, for example, in the BES CreateActivity operation. In this session we'd like to explore current work and requirements and discuss how to move forward. So this session will be along the lines of an ad-hoc bof---presentations followed by discussion. We already have some presentations lined up but probably have room for more. If you would like to present at this session please send an email to either Steven McGough <asm(a)doc.ic.ac.uk> or myself. This session is scheduled for Wednesday (10/17) evening. http://www.ogf.org/gf/event_schedule/index.php?id=950 -- Andreas Savva Fujitsu Laboratories Ltd

1 0

JSDL Implementations at OGF21
by A.S.McGough 05 Sep '07

05 Sep '07

Dear All, Apologies for cross-posting. At OGF21 we plan to hold a session where groups/organizations who have implemented JSDL can present their products and provide feed-back on the standard. This is one of the stages we are taking towards making JSDL a full standard. If you would like to present at this session (all our sessions are on Wednesday though exactly which session we use for this will be decided based on people's availability) could they please contact either Andreas Savva <andreas.savva(a)jp.fujitsu.com> or myself. Many thanks, steve.. -- ------------------------------------------------------------------------ Dr A. Stephen McGough http://www.doc.ic.ac.uk/~asm ------------------------------------------------------------------------ Technical Coordinator, London e-Science Centre, Imperial College London, Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK tel: +44 (0)207-594-8409 fax: +44 (0)207-581-8024 ------------------------------------------------------------------------

1 0

OGF docs for your review
by Ellen Stokes 14 Aug '07

14 Aug '07

Folks, These documents describe OGSA approach to Information Modeling (e.g. describing resources). They are in public comment now and your input is welcome. Even a comment that says, 'This was a helpful document.' can be very helpful. See: http://www.ogf.org/Public_Comment_Docs/Documents/Aug-2007/ogsa-bes-model-v1… http://www.ogf.org/Public_Comment_Docs/Documents/Aus-2007/ogsa-modeling-gui… Post comments no later than Sep 10 at: http://www.ogf.org/gf/docs/?public_comment Regards, Ellen Stokes STSM, STG System Software Strategy & Standards Member, IBM Academy of Technology Austin, Texas Tel: +1 512 838 0552

1 0

Integration of GLUE 2 and OGSA-BES
by Sergio Andreozzi 09 Aug '07

09 Aug '07

I'm resending this to the OGSA-BES list because the previous message was bounced. Sergio -------- Original Message -------- Subject: Integration of GLUE 2 and OGSA-BES Date: Thu, 09 Aug 2007 18:09:30 +0200 From: Sergio Andreozzi <sergio.andreozzi(a)cnaf.infn.it> To: ogsa-wg(a)ogf.org, glue-wg(a)ogf.org, rm-wg(a)ogf.org, ogsa-bes-wg(a)ogf.org Hi everybody, in the context of the OMII-Europe project, we are preparing to contribute an implementation of GLUE 2 to be integrated into OGSA-BES implementations (info providers will be available for the OMII-Europe partners, nevertheless the work can be leveraged for other platforms). The idea is to implement the GLUE 2 specification draft that will be available by OGF 21. The aim is to have a prototype implementation to be showed during SuperComputing 2007. Here is a draft document of the possible implementation approaches. You are invited to have a look and contribute for suggestions: http://omii-europe.forge.cnaf.infn.it/jra2/glue/bes-glue-integration Last notice, I will be on holiday for the coming two weeks, therefore we will resume this topic starting from 27 Aug. Cheers, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

1 0

BES 1.0 Published
by Steven Newhouse 08 Aug '07

08 Aug '07

At last... BES v1.0 is done and available as a draft recommendation for your implementing pleasure - http://www.ogf.org/documents/GFD.112.pdf. Many thanks to the whole community that have contributed to this over the years. On behalf of the BES chairs (Steven, Andrew & Darren - if he's still out there!) - Thank you. PS - No doubt we will meet again soon for an 'Execution Service' that is beyond basic... but not advanced!

1 1