Extracted from https://forge.gridforum.org/projects/ogsa-wg/document/f2f-minutes-200502 14-16/en/1 Notice that the Job container is equivalent to DRMAA internal data structures with the difference that the user app could manage it. -Hrabri ** OGSA-BES (Basic Execution Service) - A Service interface for 'job factory' or container or .... It corresponds to one small piece in the EMS picture (service container). - Note that this is not a scheduler or queue (out of scope) - Job state/modelling is in scope - Review of early draft by Steven N.: - submitJob: - Input: jsdl 1.0 - Output: a job identifier/"Abstract Name" - Faults: (feature not supported) - and a variant - submitJob - Input: an abstract name pointing to a jobdescription - The abstract name could be an EPR (a WS-Address) - Why not state that it is an EPR? - Just trying not to be overly restrictive at this stage. - This is an open issue. (Need an alternative normative definition of WS-Address that is not based on EPRs if this is not to be defined as an EPR.) - getJobStatus - jobTerminate - This is an operation on the container not the 'job'; the job might also have a similar operation. - Shouldn't this be done through WS-Resource lifetime mechanism? - Or why create new operations or terms for functionality that can be provided by existing mechanisms? - Not intended as a substitute for a destroy on the created resource (job). It is an alternative (shorcut) way of managing jobs within a container. - Input could be a list of abstractNames; provide a serviceGroup like functionality. For example, to quickly purge all jobs from a container. - ... still open... 'different' names for what is already available/possible using EPR and WSRF model - getSupportedStatus - Provides a view that is more easily mappable to more traditional job submission/control functionality. - Simplest set that is useable by a large part of the community; and can be delivered within a reasonable time. - Requirement: exactly once job submit semantics - Does not have to be part of the spec, but the spec must allow support for it - Possibilities: A jobid (or some unique input token) could be in the submission document or part of the API - Differences in opinion - Concerns with possible overlap or clash in functionality with basic profile definition. - In the sense that the BP takes the WSRF route while this proposal might take a different approach that does not use WSRF, but provides similar functionality to what WS-Resource modeling would provide. - And also 'way of doing things' that fits with the OGSA/OGSA-EMS model/architecture. - But this is something that should and could be done as the work of this proposed WG progresses. - Whether the 'container' has operations that can manage jobs or whether that management is done directly on the jobs (and only that way is defined) - BoF followup - (Andrew is leading the activity for now) - Select chairs - How to make sure that this work remains OGSA compliant - Milestones: draft by GGF14; implementations by GGF15 and go into public comment; proposed recommendation by Dec. ** Basic Execution Profile - Two approaches: - list candidate specs currently available - what we would like to be able to define and then match what is available with what is needed to be able to describe it - Currently available or nearly available - JSDL - WS-Agreement - JSDL and WS-Agreement connection. A need for some simpler normative document that describes how these two fit together. - The OGSA-BES BoF/proposal - Proposal for a short informational document to describe what the space looks like, where the holes are and whether they can be filled. - In other words an EM roadmap document that will be part of the OGSA roadmap - With a basic execution profile following after that. - Which part of the broader EM architecture should be worked on next? - Refinement could proceed along with other activities to do a proto-profile - Proposal to begin BP-EM after June; after the OGSA-BES activity starts up. - Three activities: 1. OGSA-BES BoF spawns WG for BES Specification 2. OGSA-WG works on Basic execution profile (With input from existing specs (JSDL & WS-Agreement, etc)) 3. OGSA EM Design team works on Refactoring of EM architecture