[SAGA-RG] Question about SAGA features

[Jérémie Chevalier]

Hello Andre,

Thank you for your answer, this is exactly what I needed !

Thanks for your time.

Regards,
Jeremie.

Andre Merzky a écrit :
> 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.
>
>
>
>   

-- 
*Jérémie Chevalier*, /R&D Engineer/
CETIC
Software and Service Technologies department
SOA Team
Phone (Office): +32 (0)71 490 731
Rue des frères Wright 29/3
6041 Charleroi

Spécialisé dans les Technologies de l'Information et de la 
Communication, le *CETIC* se positionne en tant que Centre d'Excellence 
en soutien technologique des entreprises.

Plus d'informations sur le site www.cetic.be <http://www.cetic.be> 	

Specialised in Information and Communication Technologies, *CETIC* is 
positioned as a centre of excellence in technological support for business.

More information on www.cetic.be <http://www.cetic.be>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/saga-rg/attachments/20080808/eff557a7/attachment.html