[saga-rg] Fwd (andre at merzky.net): Fwd (s.jha at ucl.ac.uk): Re: OGSA is aligned...

[Andre Merzky]

Hi SAGA group,

We finally managed to sit together for an hour and discuss
the relation between SAGA and OGSA in some detail.  Thanks
to the OGSA folks for making the time!

This email tries to capture the points and results of that
discussion.  It is rather detailed for two reasons:

  - we want the OGSA folks to check, and 'officially' agree
    to these points (they did by now)
  - we want to use these points as input to our middleware
    alignment document


Observations:
  
  - There are a number of paradigms which span OGSA and are
    potentially apparent at the application level in some
    use cases (TODO: recheck OGSA use case document)

    Amongst these paradigms are, most notably, 

      - notification / events
      - asynchroneous / decoupled operations
      - state management
      - life-time management


   -- notification / events:
    
    SAGA thinks we are fine here, as we have 
    
      A) a generic event and monitoring model, and 
      B) most events can be captured and reacted on 
         on implmentation level.


   -- asynchroneous / decoupled operations:

    SAGA thinks we are fine here as well, as

    A) the API is asynchroneous as well, and 
    B) asynchroneous middleware calls can be made
       synchroneous with a blocking wait (that has drawbacks
       though, but we can live with those in our use cases).


  -- state management:

    SAGA thinks we are fine here as well, as

    A) essential state information (file pointer, job state,
       stream state) are exposed on API level already
    B) other state information can be kept in the API
       implementation on client side, or on intermediate
       stateful services, depending on the system the API is
       implemented on


  -- life-time management:

    This was the most interesting point I think.  The use
    cases are:

      - an application runs for 3 months, and expects a file
        pointer to be available for that time
      - a remote file op implies a log file, but a network
        failure prevents the lock from beeing removed.  W/o
        life-time management support, that lock lingers
        (can't distinguish between a network drop and
        application being busy).

    Our discussion came to the conclusion, that:

      - sensible life-time defaults in the implementation,
        or out of bound, can probably catch most problems

      - a generic application life-time attribute to a
        session handle should catch most of the more
        difficult cases (long running applications etc).

      - per 80:20 rule, that should be sufficient for SAGA
        until more specific use cases are known.

      - more detailed use cases might motivate life-time
        attributes (contexts) for SAGA object.

    
Summary:

  At the end, we agreed with Steven's remark that OGSA and
  other middleware properties should ideally NOT pop up on
  application level at all.  Having said that, there might
  be use cases where an exposure of life-time, state,
  discovery etc. might be beneficial for application.  
  Also it might not be obvious what is a middleware 
  property ("one middleware's property might be another
  applications")

  ( Comment from Steven:

    If stuff has to pop up it should do so in an infrastructure 
    neutral way
    - i.e. it is a lifetime request (not a setting of a WSRF
      resource property).

    Also if requesting a specific lifetime there should be an
    option for the layer to throw a 'NotSupportedExcepetion"
  )
      

  SAGA should wait for more detailed use cases before
  pursuing that topic any further, for now we see NO point
  of conflict between SAGA and OGSA based middleware.

  Life-time management might be a simple and local addition
  to session properties, and should be considered for
  inclusion into the API, after cross checking with the
  available OGSA use cases.

  
Cheers, Andre et.al.

-- 
"So much time, so little to do..."  -- Garfield