User Requirements
From EGI Knowledge Base
Grid technology should evolve in response to the requirements of its user communities. Here we list the requirements collected from a variety of such communities, abbreviated as follows:
AA = Astronomy and Astrophysics CC = Computational Chemistry ES = Earth Sciences F = Fusion GO = Grid Observatory HEP = High Energy Physics LS = Life Sciences
Contents |
[edit] Highest priority requirements
Five requirements have the highest priority for any middleware:
| 1. | Reliable grid middleware; Quality of Service, especially when submitting a huge number of jobs. | All |
| 2. | Easy access to data and databases; easy to use, standardized API and fine grained access policies possible. | All |
| 3. | Advance reservation or the information when your job will be scheduled: monitoring of jobs, estimate of queue delay, near- real time reservation. | All |
| 4. | Common ways of authentication and authorization: Standardized Authentication and authorization mechanisms for usage in portals as well as in direct Grid access. A globally accepted, trustworthy Grid user identity or ‘Passport’ with an infrastructure providing it is part of this. | All |
| 5. | A support to international VOs which are in many NGIs each with its own preference for grid services. | All |
[edit] Administration and Operating
| • Common Authentication process across all Services | ES, LS |
| • Powerful Authorization with VO/group support (multiple groups per user) | ES, LS |
| • Shared Credentials (same certificate for all Services and Groups) | ES, LS |
| • Central place to create user and credentials for the whole Grid | ES, LS |
| • Secure Communication and Transfer (e.g. TLS) | ES, LS |
| • Uniform configuration across all Grid components | ES, LS |
| • Standard mechanisms for deploying application environments to CEs | ES, LS |
| • Ability to deploy and operate different versions of same software | ES, LS |
| • Interoperability through standard-compliance (e.g. OGSA) | ES, LS |
| • Standard mechanisms to fault tolerance, error handling, service recovery, outages and maintenance scheduling for all Grid components | ES, LS |
| • Testing and Monitoring of Grid Components with automatic Alerts | ES, LS |
| • Reliable adherence to quotas and Quality of Service requests | ES, LS |
| • Common standard for documentation, consistent documentation model, supported tools and formats across all middleware packages | ES, LS |
| • Fast, easy site installation and verification procedures for new sites joining the grid | ES, LS |
[edit] Infrastructural Services
| • | Support for very data and metadata intensive applications, including fast access to metadata and reliable transfer of massive amounts of data. | ES, LS |
| • | Level of fragmentation and distribution into subjobs as well as the selection of computational sites should be influenced by proximity of data and bandwidth capabilities to ensure efficiency of the workflow. If this is ignored, data transfer might take much more time than the actual computation. If needed, local copies of files, so called replicas, should be created to aid the user. Existing replicas should be discovered automatically. | ES, LS |
| • | Ad-hoc integration of arbitrary data sources that lie outside the Grid, e.g. archives of sensor data that get updated regularly. The aggregation should not be a rarely synched local copy, but the up-to-date original data. Possible data sources are web service queries, databases (oracle, mysql, postgresql, firebird, mssql, db2), (S)FTP, HTTP(S), RTP (real-time). | ES, LS |
| • | Access to and integration with auxiliary software libraries for:
| ES, LS |
| • | Encryption / protection of data on grid storage elements | LS |
[edit] Application Development and Porting
| • | Consistent API for all middleware components | ES, LS |
| • | Standardized error codes and error handling procedures | ES, LS |
| • | Framework to easily use Authentication, Authorization and secure communication | ES, LS |
| • | Client APIs for most prominent programming languages (Java, C++, Perl, Python, Fortran) | ES, LS |
| • | Consistent Command Line Interface to support shell scripting or unsupported languages | ES, LS |
| • | Ability to use MPI-standard (across domain boundaries) | ES, LS |
| • | Automatic Utilization of file replicas and mirrored databases without application side interaction | ES, LS |
| • | Unique identifier for files and all associated metadata | ES, LS |
| • | Support and interoperability of different query languages, e.g. SQL, LDAP, TMQL, XQuery, SPARQL, DMX | ES, LS |
| • | API to retrieve parameters specified in job description file | ES, LS |
| • | API for service and resource discovery features | ES, LS |
[edit] Utilisation and Usability
| • | Visualization of intermediate data during computation and of completed results | ES, LS |
| • | Discovery of services and data by arbitrary properties and metadata | ES, LS |
| • | Potential modification of parameters during computation by interpretation of specific indicators or manually (application / simulation steering) | ES, LS |
| • | Description of entities by the use of custom or standardised ontologies | ES, LS |
| • | Support for wide range of metadata schemas (ISO 19115/19139) providing means to discover data, describe data objects, etc. | ES, LS |
| • | Non-intrusive easy way to handle authentication | ES, LS |
| • | Reliable real-time and instantaneous job submission for high priority jobs for e.g. risk management | ES, LS |
| • | Intelligent assistant interface to facilitate scientific workflows and domain applications | ES, LS |
| • | Workflow must provide knowledge representation and reasoning tools connected to metadata repositories | ES, LS |
| • | Workflow management must be able to handle workflow templates | ES, LS |
| • | Description of workflows in standard workflow description languages | ES, LS |
| • | Possibility to explicitly specify QoS requests | ES, LS |
| • | Support for Service Level Agreements and monitoring of their compliance | ES, LS |
| • | Standard framework for response messages. Unambiguous, clear and meaningful error messages. Rationalization of request handling processing and result codes (i.e. analogous to the HTTP error processing and execution codes) | ES, LS |
