GGF18: OGSA and EGA Reference Model
===================================

Date: 12 September 2006, 4:00-5:30pm 
Room: 159A-B

* Summary of Action

   Next step: Set up an initial group of people to start a discussion
   within OGSA. Identify what should be done.
    - Dave Snelling, Andrew Grimshaw, Tom Maguire
    - Paul Strong, Alan Clark, Bob Thome

* EGA Reference Model Overview (Paul Strong)

  - Policy is at the GME level; is it a statement that the PEP is
    there?  GME is an abstraction; it might be.

  [slide 25]
  - GME looks like it might be itself manageable, it is explicit, or
    munged? 
    - No implication about implementation.
    - Relation is not a nesting (containment), it is a graph (dag)
    - GMEs is a logical entity

  - Simplified policy since these are all within one enterprise and
    the policies might be more clearly defined.

  - How does this map to a SOA? 
    - This defines a component model identifying things that are
      important.

  [slide 31]
  - From left to right (arbitrary choice); might want to have
    concurrent or not at the same level.
  
  - This is an instance dependencies diagram

* Glossary comparison

  - Minor overlap in terms (11) (same term name)
  - See Jem Treadwell's slides for more details.

* OGSA/EGA reference model comparison

  - A number of discussion topics listed in Hiro's presentation.

  - OGSA services vs EGA GME
    - Points to a different way of thinking (modeling) about the
      problem;
    - Could everything on the left be wrapped as service? Maybe, some
      of them have been wrapped as services in implementation
    - OGSA has wrapped as services;
    - this may be the difference between a reference model and an
      architecture

* Next steps

  - No specific OGF policy on unifying EGA and GGF work, but there is
    an expectation that parties talk to each other
  - Merging the glossaries? Yes and does not look too difficult
  - Proposal: maintain the distinction between reference model; and
    OGSA as (a service oriented) rendering of it;
    - Is it true, or should it be made true?
    - As an exercise, what is the specific use case to drive it; need
      a reason--more than an abstract motivation. No reason just to be
      consistent.
    - EMS (or the more restricted HPC Profile) might be a good
      starting point
    - Would probably need more than one use case; would also have to
      think broader than current thinking in OGSA.
    - Transaction processing kind of environment as one motivation?
  - Next step: Set up an initial group of people to start a discussion
    within OGSA. Identify what should be done.
    - Dave Snelling, Andrew Grimshaw, Tom Maguire
    - Paul Strong, Alan Clark, Bob Thome