OGSA EMS Teleconference - 17 January 2005
=========================================

* Participants

  Ravi Subramaniam (Intel)
  Dave Snelling (Fujitsu)
  Andreas Savva (Fujitsu)
  Mark Morgan (UVa)
  Tom Maguire (IBM)
  Fred Maciel (Hitachi)
  Hiro Kishimoto (Fujitsu)
  Andrew Grimshaw (UVa)
  Ian Foster (ANL)
  Dave Berry (UK NeSC)

* General discussion

  - Agreed that the EMS space lacks concrete specs.
  - Initial focus on capabilities to guide effort in exploring the
    area---it seems premature to do an EM profile.

  - JSDL and WS-Agreement do seem to have some momentum behind them.
    But these pieces do not offer sufficient coverage to do a profile.
  - (Clarification that a Profile's purpose is interoperability.)
  
  - Proposal for discussing what a reasonable aim is---a gap
    analysis of sorts.

  - Agreed to the following:

  1. Document the process of defining what we want to do 
     a) Look at what there is in EMS (OGSA version 1.0)
     b) Subset it 
     c) Union with outside specs
     d) Decide where new groups are needed (to fill the gaps)

     - Goal: short-term (candidate) profile that can produce
       something demonstrable 
       - Clarification that "short term" means "year's end"
       - *Candidate* profile since it only has to identify the
         activity leading to a spec.
       - Detail concepts first? Might not finish until the profile is
         done.
       - Profile to cover as a minimum a "Hello world" level of
         functionality.

  2. Look at what is there already in the EMS draft and what is the
     minimum subset that can be done as a first step. (To do.)
  
  3. What is basic functionality?

     - Talk to a service/container/resource to start up something
       - If the executable is there just pass a path to it, or get it
         to the machine first---in some simple manner (no full-blown
         deployment configuration; just a data transfer)

     - (Ian) GT4 as an example that covers such simple functionality
     - (Dave) Unicore/unigrids as another example
     - Other efforts might offer input here, e.g., EGEE, etc

     - These examples might look very similar but their are subtle
       differences

     Proposal: Do a BoF on basic EM functionality.

     - The two projects above are willing to put forward complete WSDL
       specifications of relevant port types. This is important because
       they can be used as the starting point for standardization.
       - Should the entry point be the existence of WSDL specs?
         - Various opinions, but the rough consensus towards 'yes.'
       - Would like to also get Condor on-board (but need WSDL)
         - Condor has a WSDL sub-project: "Condor meets Soap" aka 'birdbath'
       - (DRMAA as an example that has an abstract definition but looks
         like a lot of work to put in WSDL)
       - Shared understanding that we can look at existing effors,
         invite groups to join, but cannot force participation in such
         a standards effort. And cannot just stop and wait.

       - Is there a preference to start from scratch? 
         - Or, make sure that other efforts are also reviewed?
         - Consensus that it is easier to start from existing examples

     Action: Ian will send a pointer to the list describing the GRAM
       interfaces (Done)
       
     - Agreed that background work to review the various material is
       needed first.

     - For BoF need to also leave door open for people who may be
       proposing solutions not based on WSRF (e.g., OMII, etc)

     - The BoF is in addition to the profile work; fill the perceived
       gap in the EM space while the profile defines interoperability.

     - Clarified that the BoF is specifically on the submission
       interface; not the whole EMS space.

     - JSDL and WS-Agreement might be pieces used in the Profile.
     - (And might need more bofs for other pieces as gaps become more
       visible)

     - Forming such a group motivated/became obvious due to the work
       in EMS
       - Need/desire to make sure that it fits in OGSA-EMS
       - And that can only be done through participating in the
         proposed new group.

     Action: Work on drafting the charter for the BoF 
       - Obviously do not to call it EMS; it is focused on a small
         subset: 'submission API'
       - This is not technical (design) work.
       - If the process is 
         - (simple definition/provisioning), instantiation,
           execution, management
         - then BoF preparation is to decide what the minimal subset
           is.
       - Andrew and Dave volunteered to do a draft (initial proposal)
         of what is the important basic functionality and scope it as
         part of F preparation (initial proposal) (partly done)
 
    Additional actions:

      Action: Dave B to send WS-Agreement and DAIS link to the list.
      Action: Ravi volunteered to do a map of existing specs; what is
              there, now

* Next EMS call: Jan 26  (to include BoF discussion)

* OGSA EMS version 1.0 revision update

  - Andreas did a revision of the EMS section in OGSA version 1.0, to
    address some lingering issues: removing the term 'task' and 
    modifying the explanation for 'Job'
  - Key changes:
    - Replace 'task' with generic 'unit of work' or delete as appropriate
    - Change order in definition of 'Job' so that the statement 'Job
      is a resource' comes later. Also remove too concrete statements
      (job is not workflow) that raised many comments at GGF12.

  Action: Andreas will fold in changes to next (final) draft and
          review in a subsequent call. (Done)