Speaker
Overview
HELIO, an FP7 funded project, offers a set of tools to the heliophysics community to support scientific research.
HELIO uses services specific to HELIO and also external services for storage and computation; the various services of which HELIO is composed are orchestrated through the means of workflows.
HELIO's architecture is complicated by a variety of factors
mainly driven by the large variety of users it intends to
support: while the normal users should be able to easily select pre-defined workflows, more advanced users should be able to define their own procedures defined either as workflows or as scripts and programs.
Also, scientists and the services back-ends have very different approaches towards security and privacy, all of which have to be catered for.
To meet all these requirements HELIO is built on a SOA, Multi-Layered architecture based on the following principles: Service Duality, Workflow Agnosticism, Need to Know Policy, Flexible Deployment and Policy Compliance.
Impact
The impact of HELIO covers two main aspects.
The scientific aspect covers the impact that HELIO will have
on the heliophysics community. To allow a profitable feedback
with the users, special events named CDAW (Complex Data
Analysis Workshop) are scheduled after every major release
of HELIO. The first such workshop was held in Orly in November 2010 and showed a good interest of the scientific community
in the features offered by HELIO.
The other aspect is technological: some of the problems faced
by HELIO are of a wider interest as the need of negotiation between the needs of the different user profiles and the policies of the back-ends is common among infrastructures for the scientific community.
Description of the work
The architecture of HELIO is composed by components arranged in multiple layers that span the conceptual space from the resources to the user.
The services, their interfaces and the back-ends (that only some services rely upon) are of different kinds:
-) services that allow searches in external data sources,
-) services that allow an easy access to diverse data sources: they offer a layer of abstraction to the existing data sources;
-) services that offer functionalities such as computation and storage;
-) services that offer functionalities that are of no direct interest to the user (Authentication, Logging, etc...) but that are important to the system;
-) services that allow discovery and monitoring of HELIO services.
To grant access to these services in compliance of the HELIO
principles, HELIO offers an "access layer", an abstraction used to describe the different ways in which the services can be accessed.
There are three possible implementations of the access layer:
-) The HELIO User Interface that allows the user to invoke the various HELIO services independently or to connect them in patterns defined on the fly. The User Interface also supports an instance of a workflow engine used to execute pre-defined workflows,
-) A desktop instance of a workflow engine used by the scientist to orchestrate the HELIO services in a user-defined fashion, and,
-) Direct access that allows the user to write code to directly use the HELIO services.
All the different implementations of the access layer connect
to the services through the HELIO API that includes the stubs of the various services and offers an optimal entry point to the services.
In particular, the Grid Services are designed to cope with the
complexity stemming from the negotiation between users and back-end policies.
Security is based on authentication tokens with a low and high level of security to cater for all the permutations of user profiles and implementations of the access layer
Conclusions
HELIO is now well into its second year of development, most of the query services have been developed and connected to the HELIO Query Interface with success, enabling services that provide Security, Processing and Storage facilities are now being prototyped and will be connected to HELIO in the next
release in January 2011.
URL
http://www.helio-vo.eu/
