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. Thank you in advance. Regards, Jeremie. -- *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>
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.
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>
participants (2)
-
Andre Merzky -
Jérémie Chevalier