[drmaa-wg] More on OGSA-BES BoF efforts
hrabri.rajic at intel.com
Fri Feb 25 10:39:38 CST 2005
Notice that the Job container is equivalent to DRMAA internal data
structures with the difference that the user app could manage it.
** 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
- 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.:
- Input: jsdl 1.0
- Output: a job identifier/"Abstract Name"
- Faults: (feature not supported)
- and a variant
- 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
- 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.)
- 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
- 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
- And also 'way of doing things' that fits with the OGSA/OGSA-EMS
- 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 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
- In other words an EM roadmap document that will be part of the
- With a basic execution profile following after that.
- Which part of the broader EM architecture should be worked on
- Refinement could proceed along with other activities to do
- Proposal to begin BP-EM after June; after the OGSA-BES activity
- 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
More information about the drmaa-wg