Speaker
Description
Conclusions and Future Work
HELIO started in June 2009 and, as of now, the overall architecture is just being finalized while prototypes of the most important services are being developed.
A first official release of the project that encompassed the prototypes of several services without the Grid-based back ends was released at the end of January 2010.
A second release, due at the end of May 2010, will encompass prototypes of the Community Interaction Service and the Processing service that will be completed and joined by the Storage Service in the third release of HELIO that is due at the end of September 2010.
Detailed analysis
HELIO will provide a set of instruments with which scientists can discover, understand and model the connections between solar phenomena, interplanetary disturbances and their effects on the planets. It does so by orchestrating services that help to identify and analyze events and observations across the solar system, and to correlate these using propagation models.
HELIO must be simple to use, yet ideally its architecture must support different workflow engines to orchestrate its services, it must encompass Grid services fully complying with their policies and, must allow the different services to be deployed flexibly.
HELIO strives to tackle all this requirements with an architecture encompassing different layers:
• The user access layer, an abstraction of all the possible ways in which the different services can be accessed, such as a local workflow engine, the HELIO web site or programs written by the users.
• The service access layer, an abstraction of all the possible deployments of the services that also allows the independent use of some of the services
• The services themselves, with interfaces for remote and local access.
• The back-ends upon which some services rely.
The back ends encompass data sources; web sites that provide specific computational facilities and, more importantly for this paper, grid middleware based back ends.
Grid Middlewares will provide three main functionalities: security, computation and storage.
• A Security Service, called Community Interaction Service, will provide voms-proxy certificates that will be used for authentication and authorization.
• A Processing Service, partially based on Grid Middleware, will offer a unified service for execution. The Grid-based back end of this service is based on the gLite job submission system.
• A Storage Service, based on Grid Middleware, will offer storage for the HELIO system. It will be based, at first, on the gLite storage services but, potentially, will be later connected to an iRods service.
Impact
HELIO's impact will cover three main fields. It will have an impact on Heliophysics helping to foster cooperation among different scientific communities, it will have an impact in the Computer Science community as the problems it is trying to tackle are common in projects that must balance similar constraints, and finally it will provide a useful testing case for the Grid back-ends.
This paper focuses on the technological aspect of the project.
If successful, the HELIO architecture could be adapted as a solution to similar problems that deal with large, distributed data sets arranged in unforeseen topologies, intensive computational tasks and the need to offer the functionalities of a complex system in different ways, e.g. with a workflow or used independently.
It could also prove useful in implementing systems that expose a simple interface to users that want to use complex instruments but do not want to be bothered with technical details.
HELIO will also use the Grid facilities of Grid Ireland. Of particular interest will be the assessment of how well the Storage Facility being developed in the national e-Inis project will act as a back-end to the Storage Services of the HELIO project
| URL for further information | http://www.helio-vo.eu/ |
|---|---|
| Keywords | Heliophysics, grid service, storage, workflows |
