April 2006 - ogsa-bes-wg

Meeting for Wednesday April 19, 2006
by darren＠pulsipher.org 18 Apr '06

18 Apr '06

Meeting Date: 04/19/2006 Meeting Time: 9:00 AM EDT, 6:00 AM PDT, 1400 BST, 1300 GMT Instant Meeting Details: ------------------------------- USA Toll Number: +1-517-444-3907 USA Toll Free Number: 866-878-0811 Participant Passcode: 8512027 Instant Net Conference Details: ------------------------------- Meeting Number: SW113223 Meeting Passcode: 25861 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=SW113223&p=25861&t=c 2. Enter the required fields. 3. Indicate that you have read the Privacy Policy. 4. Click on Proceed.

1 0

ESI Document
by Steven Newhouse 17 Apr '06

17 Apr '06

The ESI document is presented as a 'new' specification and makes little reference to the current BES drafts. It is therefore difficult to explicitly identify the differences, between this document and the BES specification. The following appear to be the significant differences (ignoring rendering related issues) that appear from reading the document and discussions with Dave Snelling during the EMS session at the OGSA F2F a few weeks ago. I'd suggest the priority of the telecon this week would be to capture any additional issues (before getting bogged down in details) as many of these issues have already been discussed previously but not included in the specification due to a lack of group consensus on these issues. * Unique Identifier on submission This has discussed several times in the past and has appeared and disappeared from the BES specification - currently out - as BES probably thought it could go into JSDL. The JSDL gurus at the F2F felt that this did not belong in the JSDL document itself (their argument - it has nothing to do with describing the job) but sat within the message body of the create activity (or equivalent) operation. There was some discussion at the F2F about the failure semantics of the lower-level layers (beneath the webs ervice) that should be included here. [Expansion of the WS-Addressing comment on ESI page 3 would be welcome.] * State Model The main difference (at first glance) is a distinct Hold state for each primary state - although BES records the proceeding state so the BES generic Hold is qualified with where it came from. Dave Snelling stated that the state model was still under discussion so no further comment will be made here. However, it appears to be clear that different state models may be associated with different activities - and in many cases may be simpler that either the BES or ESI document. Perhaps linking the state model to the JSDL application type (e.g. POSIX) may be a way forward? This would allow (say) a WebServiceApplication type in the JSDL document to have a very simple model (running/not running). * Activity Interface Once the job has started in ESI it presents an interface that can be used to control the job. BES does not require or exclude the presence of such an interface, as activity specific control is done through the interface. Indeed, there is a probably a case to be made for 'any' interface to be described here - the job control interface described in the ESI document, and activity specific interfaces. There was some discussion in BES-WG of the POSIX JSDL job type being linked to a POSIX Activity Interface for control purposes. This generic capability would seem worth pursuing. * Information Model Again, there has been much discussion with BES-WG and the OGSA-WG on the 'right' way to describe the BES container and the activities within it - picking up on CIM, GLUE and JSDL work. These segments of the ESI document should be compared to the work done in this area to date. If the inclusion of supported applications/libraries is important this should probably be modeled here. * Notification I don't think there is any particular issue that it should be possible for a something to subscribe to state changes. Mandating WS-Notification mechanisms with the WS-RF rendering is obviously one route. As is WS-Eventing in other renderings. BES does not mandate one mechanism over another. * Notification on Submit BES supports something approaching this by submitting into a suspended state at which point notification is set up. There is a gap here between BES and ESI functionality. These are the major items from my scan of the documents and my notes from the F2F. There may be others... please add to them. -- ---------------------------------------------------------------- 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, Southampton University, Highfield, Southampton, SO17 1BJ, UK

1 0

ESI Draft Document for April 19th meeting.
by Darren Pulsipher 11 Apr '06

11 Apr '06

Here is the ESI document. Please look at this and have comments ready for April 19th Meeting at 9:00 am EDT. I will send teleconference and web conference information in the next couple of days. Darren

1 0

Next Meeting: ESI Proposal
by Darren Pulsipher 10 Apr '06

10 Apr '06

We need to discuss the ESI proposal that has been brought forth. The plan is to have this meeting at 1:00 pm GMT, 9:00 am EDT, 6 am PDT, 10:00 pm Tokyo. Wednesday April 19, 2006. Please be prepared to discuss the ESI proposal and how it effect BES 1.0 and 2.0 roadmap. I will be sending the ESI proposal later. Thanks. Darren

1 0

Next Telecom: ESI discussion
by Darren Pulsipher 10 Apr '06

10 Apr '06

We need to discuss the ESI proposal that has been brought forth. The plan is to have this meeting at 1:00 pm GMT, 9:00 am EDT, 6 am PDT, 10:00 pm Tokyo. Please be prepared to discuss the ESI proposal and how it effect BES 1.0 and 2.0 roadmap. I will be sending the ESI proposal later. Thanks. Darren

1 0

Draft Execution Service Interface Specification
by David Snelling 04 Apr '06

04 Apr '06

Folks, With my Unicore hat on, I have been working with some of the Globus people to see if we (Unicore and Globus) can agree on a joint Job submit and management interface specification. The progress has been very good, but we are by no means finished. However, the spec is mature enough to open it for your input. Ian and I are acting as editors, so please send issues and comments at least to us. To put this work in the current OGSA context, I see this specification as the WSRF OGSA Base Profile rendering of a fairly complete execution service interface. I don't believe it is much more complicated than the minimal set of capabilities needed to address the HPC use cases posted by Marvin. This might therefore also be the WSRF BP rendering of that as well (given suitable optionality at strategic places) , but more analysis is needed. With respect to the OGSA-BES work, we see this as a possible next step for BES-like services. The corresponding factory operation in this specification is slightly more complex than the BES create activity operation, but is not intended to replace it. I realize that the schema and WSDL sections are missing. I assure you that drafts of these exist, but are grossly out of phase with the main document. We will be working over the coming weeks to develop these. Let us know what you think. I plan to join the EMS discussion tomorrow by phone and can answer questions then if people have them. -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

1 0