| 목차 |
|---|
...
UC1
...
UC2
...
...
...
...
Architecture & EOSC-hub technologies considered/assessed
...
...
Ambition
What's the ambition of this CC in EOSC-hub?...
User stories
| 정보 | ||
|---|---|---|
| ||
Requirements are based on a user story, which is is an informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end user or user of a system. Depending on the community, user stories may be written by various stakeholders including clients, users, managers or development team members. They facilitate sensemaking and communication, that is, they help software teams organize their understanding of the system and its context. Please do not confuse user story with system requirements. A user story is an informal description of a feature; a requirement is a formal description of need (See section later). User stories may follow one of several formats or templates. The most common would be: "As a <role>, I want <capability> so that <receive benefit>" "In order to <receive benefit> as a <role>, I want <goal/desire>" "As <persona>, I want <what?> so that <why?>" where a persona is a fictional stakeholder (e.g. user). A persona may include a name, picture; characteristics, behaviours, attitudes, and a goal which the product should help them achieve. Example: “As provider of the Climate gateway I want to empower researchers from academia to interact with datasets stored in the Climate Catalogue, and bring their own applications to analyse this data on remote cloud servers offered via EGI.” |
...
No.
...
User stories
...
US1
...
US2
...
...
Use cases
| 정보 | ||
|---|---|---|
| ||
A use case is a list of actions or event steps typically defining the interactions between a role (known in the Unified Modeling Language as an actor) and a system to achieve a goal. Include in this section any diagrams that could facilitate the understanding of the use cases and their relationships. |
...
Step
...
Description of action
...
Dependency on 3rd party services (EOSC-hub or other)
|
Ambition
The Radio Astronomy CC will support researchers to find, access, manage, and process data produced by the International LOFAR Telescope. It aims to lower the technology threshold for the Radio Astronomical community in exploiting resources and services provided by the EOSC. Particular aspects that will be addressed are federated single sign-on access to services in a distributed environment and support for data-intensive processing workflows on EOSC infrastructure, notably having access to user workspace connected to high-throughput processing systems, offer portable application deployment, and provide integrated access to a FAIR science data repository. The community is to be empowered to optimally profit from these and increase the science output from multi-petabyte radio astronomical data archives of current and future instruments. The RACC will achieve this by undertaking activities including integration with available federation and data discovery services.
Users will be provided with access to large-scale workspace storage facilities within the EOSC-hub to store and share temporary data and products from pipelines. RACC will empower science groups to deploy their own processing workflows. The RACC lessons learned will serve as input for the design and construction of a European Science Data Center for the Square Kilometre Array (SKA), e.g. via the complementary AENEAS and ESCAPE projects.
User stories
No. | User stories |
|---|---|
US1 | As an Observatory, we want to offer Single Sign On to our users and manage community access through a central federated collaboration management service, such as COmanage, to improve user experience and consolidate user administration for services. |
US2 | As a scientific user, I want to perform LOFAR data analysis on archived data-products using available scalable compute infrastructure, allowing for long-term storage and inspection of results. It must be possible to automate initiation and monitoring of processing workflows including data staging and storage. I want to use portable software deployment such that time spent on porting applications is minimized, an integrated workflow management framework, and user workspace to store data products that are to be evaluated or further processed. |
US3 | As a scientific user, I want to enter science-grade data products in a science data repository that supports the FAIR principles to ensure long-term data preservation and attribution of effort. This will further improve sharing of data with colleagues and access to data from other science domains. It should be possible to access data in the science data repository using direct links to individual data objects via an anonymously accessible public URL such that other services, e.g. those provided by the Virtual Observatory, can be built to provide access to the data. |
Use cases
Step | Description of action | Dependency on 3rd party services (EOSC-hub or other) |
|---|---|---|
UC1 | Observatory registers service with federation | Federated AAI (Comanage, e.g. EGI Check-In) |
UC2 | User registers for LOFAR collaboration(s) | Federated AAI (Comanage, e.g. EGI Check-In) |
UC3 | Observatory manages collaboration(s) | Federated AAI (Comanage, e.g. EGI Check-In) |
UC4 | Collaboration administration provisions non-web service(s) | Federated AAI (Comanage, e.g. EGI Check-In) |
UC5 | User authenticates to federation | Federated AAI (Comanage, e.g. EGI Check-In) |
UC6 | Observatory releases data analysis software in repository | - |
UC7 | User enters data analysis software in repository | - |
UC8 | User selects data for retrieval/processing | - |
UC9 | User requests/stages data-products | - |
UC10 | User retrieves data-products | dCache WEBDAV/Macaroons |
UC11 | User initiates data analysis workflow | HTC processing cluster supporting Singularity, CWL workflows, CVMFS (application distribution) |
UC12 | User inspects output data | dCache WEBDAV/Macaroons |
UC13 | User registers output data | B2SHARE, PID service (EPIC) |
UC14 | Observatory registers archived data | B2FIND (option), PID service (EPIC) |
The first five use cases are related to providing federated authentication and authorization to LOFAR and EOSC services for the LOFAR community, addressing user story US1.
Use cases UC6 - UC12 are related to user data processing for science projects and address user story US2. UC6 - UC9 are included for completeness but are handled by services provided by the LOFAR Observatory and, other than integration in a federated AAI, do not depend on 3rd party services. The diagram below is a control flow diagram of the user processing workflow that will build on the use cases in this document.
The main user processing workflow.
At the moment, the functions in the diagram above are handled by community-developed services and can be viewed as representations of the ‘User’ role in the use cases provided here (1: UC8; 2: -; 3: UC9 - UC11; 4: UC12; 5: UC10, UC11, UC13). Existing functions have been developed by one of the key science projects but are not available as a service to the wider ‘long-tail’ community. A stepwise implementation of these functions in a central User Portal will be undertaken to support the wider community in the future.
Use cases UC13 and UC14 address user story US3. UC13 is considered critical. UC14 may provide added value for data-linking purposes and to increase use of data from the LOFAR archive outside of the radio astronomical community.
Note that in the use cases the roles ‘Observatory’ and ‘User’ can represent a person, but also an automated process that is performed on behalf of a person.
Architecture & EOSC-hub technologies considered/assessed
High level of the architecture considered for the Radio Astronomy Competence Center.
The high level architecture for the RACC incorporates the suite of services that together address the user stories and is to support all of the defined use cases. The component ‘Federated Access’ interfaces with all components that require user level authentication and authorization support.
At the top of the diagram are two components representing a central LOFAR User Portal, supported by the LOFAR Observatory, and Community Developed Services that use the same service interfaces to build custom functionality.
Within EOSC-hub, the focus will be on the integration of Federated Access and on integration of the blue-coloured components in the lower part of the diagram (dark blue for services directed at users, light blue for integration supporting services). Steps towards implementation of a central User Portal will be undertaken but full implementation depends on work carried out in other projects as well (e.g. ESCAPE). The components ‘Instrument Data Archive’ end ‘Application Repository’ are considered to be provided and supported by the LOFAR Observatory. The other blue-coloured components will be built as much as possible on available EOSC services.
The diagram below shows how the functions in the user processing workflow interact with the services in the RACC architecture. Note that all these functions are to be provided by the components at the top of the RACC Architecture diagram.
Interaction of the user processing workflow with RACC components.
The following table maps components of the RACC architecture to the service provided by EOSC:
Component | EOSC Service | Description |
|---|---|---|
Federated Access | EGI Check-In, using COmanage for collaboration management. | COmanage is the federated collaboration management system of choice. A pilot is underway to federate using EGI Check-In. Depending on outcome, alternative federation providers (notable Geant or SURFnet) may be considered. |
Container Based Processing | EGI/Grid and High Throughput processing clusters | It is envisioned that the processing systems support CWL based workflows using Singularity containerized applications. RACC would be interested in a workflow management service provided by EOSC for this type of processing capability. Alternatively, a workflow management service would need to be deployed and maintained as an RACC specific service. |
Application Distribution | CVMFS | The main objective is to provide transparent local access to selected application containers and software installations on processing clusters. |
User Workspace | dCache WEBDAV & Macaroons | The user workspace is envisioned to use the same storage infrastructure as the instrument data archive. The objective is to move away from personal X509 based access over GridFTP toward Macaroon based access over WEBDAV. |
Science Data Repository | B2SHARE, EPIC/B2HANDLE, B2FIND | User generated science-level data is to be entered in B2SHARE. Optionally, data in the LOFAR instrument data archive will be registered in B2FIND. A LOFAR-scoped handle generating service is to be provided by EPIC/B2HANLDE. |
Requirements for EOSC-hub
Technical Requirements
...
...
- Requirement number: Use numbers RQ1, RQ2, RQ3, ...
- Requirement title: Use a short but descriptive title. Use the same title in the Jira ticket 'Summary' field
- Link to requirement JIRA ticket: Open a ticket in <this JIRA queue https://jira.eosc-hub.eu/projects/EOSCWP10/issues/EOSCWP10-4?filter=allopenissues> (click on 'CREATE' button in the middle-top of JIRA)
- Source use case: Refer back to the use cases above (UC1, 2, ...)
...
Requirement number
...
Requirement title
...
Source Use Case
...
Example
...
EOSC-hub to provide an FTS data transfer service
...
...
UC1
...
RQ1
...
RQ2
...