[drmaa-wg] More on OGSA-BES BoF efforts

[Rajic, Hrabri]

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