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