[SAGA-RG] Question about SAGA features

[Andre Merzky]

Hi Jeremie, 


Quoting [J?r?mie Chevalier] (Aug 07 2008):
> 
> Dear all,
>
> Sorry if my question seems a little bit tedious here...
> I'm currently evaluating several Grid API, whatever they
> come from proprietary middleware or from OGF standards.
>
> In the document SAGA-RG/Related_APIs/related.txt, which
> can be found on the CVS repository of SAGA, there is a
> feature matrix for frameworks, where several items are
> compared (e.g. DRMAA, JSDL, GFS, SRM, etc.).  My question
> is: What about SAGA with regard to all the criteria you
> are using to do the comparison ?
>
> Does SAGA provide means for all the criteria provided in
> the feature matrix, which are:
> 
> Resource management
> Job Management
> Data Access
> Data Management
> Data bases
> ... etc.

First, that table originated waaay back when we started to
define the scope for SAGA, and is very probably out of date.
Thus, the table may do injustice to the framwworks we
compared then, as we never cared to update the table.

The current list for SAGA would look like:

  +-------------------+-------+
  |                   |  SAGA |
  +-------------------+-------+
  | API/Interface     |   x   |
  | Protocol          |   -   |
  | Language          |   -   |
  | Service           |   -   |
  | Architecture      |   -   |
  | Use Case          |   -   |
  +-------------------+-------+
  | Resource Mngmt.   |   ?   |
  | Job Mngmt.        |   x   |
  | Data Access       |   x   |
  | Data Management   |   x   |
  | Data Bases        |   ?   |
  | Data Stream       |   x   |
  | Logical Files     |   x   |
  | Events            |   x   |
  | Steering          |   ?   |
  | Information       |   ?   |
  | Communication     |   ?   |
  +-------------------+-------+
  | Security          |   x   |
  | Error             |   x   |
  | Audit             |   -   |
  | Transactions      |   -   |
  | Workflow          |   ?   |
  | Tasks             |   x   |
  | Bulk              |   x   |
  | QoS               |   ?   |
  +-------------------+-------+

All the X'es are at the present available, either in the
Core API specification, or in some extension package.

The question mark are those item where I am aware of ongoing
efforts, or at least active interest, to add a SAGA API
package.  Some of those will take many months (literally)
before being a published API specification, if at all, but
in general, SAGA is able to host them.

Specifically:

  - resource management: XtreemOS started to work in a SAGA
    package IIRC, no idea what status that is in.  Also, it
    may have covered Resource Discovery only, not sure

  - Data Bases: we are synchronizing with the DAIS people in
    OGF now and then, but a clear way forward is difficult
    to define (technically).  We don't want to re-invent
    ODBC, nor do we want to re-invent data base query
    languages.  So, what role does a Grid API play here?
    We probably need more API level use cases to answer this

  - Steering: we have very superficial steering capabilities
    in the SAGA Core, but are interested in extending that.  

  - Information: The advert package to SAGA (work in
    progress) provides persistent storage of application
    level information.  The service discovery package (just
    came out of public comment) provides access to service
    meta data.  The resource management package listed above
    is another piece in the puzzle.  For more, we need a
    clearer idea of the needs of applications.

  - communication: the stream package in the core API
    provides some basic means of inter process
    communication.  We are working on a message API package
    to SAGA, which provides some higher level abstractions.


The items in the last category in the table, i.e. the
non-functional properties, are thought to be partly out of
scope (e.g. Auditing is usually not done on API, but on
service level), or are part of the individual packages
(e.g., transactions may well be part of a database package,
but rarely useful/implementable elsewhere).  QoS is a long
standing TODO item, and, in respect to jobs at least, we
consider it part of the resource management and resource
discovery package to be designed.  Workflow: yes, we have
some preliminary ideas on expressing workflows on API level.
You may see some development on that over the next months.  

Hope that helps, 

  Andre.



-- 
Nothing is ever easy.