Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

VT Science Gateway Primer/appdb

From EGIWiki
Jump to navigation Jump to search


AppDB recommendations

Recommendations on how to improve the data structure of the EGI Application Database, to better support science gateway developers, are recorded in this wiki page. Preliminary UCST feedback on these topics are also provided.



Science Gateway sub-categories

1. Within the Science Gateways category we need two subcategories concerning the type of the gateway:

a. SG framework (Generic DCI gateway framework)

b. SG instance (Application-specific science gateway)

UCST comment

Science gateways (SG) and Workflow systems have been added as separate new categories on the AppDB portal interface. The science gateways listed in AppDB SG category are not sub-categorized as mentioned in the above recommendation. However, there are two subcategories already 'conceptually' available within the database through the usage of tags. These two subcategories are shown on the EGI SG dedicated website:

The terminology should match between the Primer and the EGI SG dedicated webpages.

Given this background, the requirement can be translated as:

1. Within the Science Gateways category we need two subcategories concerning the type of the gateway:

a. Science gateway

b. Science gateway enabling technology


How would this recommendation be implemented?

  • Should the two subcategories be at the top level (where Applications, Tools, Science gateways and where Workflow systems are now)?
  • Should these two subcategories be presented under the main Science gateway category? In this case should we use a different name for the main category to avoid name duplication between the top level category and a subcategory under this?



Status of the gateway

2. In both subcategories we need two subcategories concerning the status of the gateway:

a. Production level (available for external users)

b. Prototype level (tested by a selected set of users)

UCST comment

Every software that is registered in AppDB have a 'Status' field in their profile. This Status field can have one of the following values:

  • In production
  • Ready for deployment
  • Ready for validation
  • Ready for portal interface
  • Ready for middleware
  • Ready for standalone use / running on a local cluster

These values are legacy values that have not changed for ~4 years. They are very much tuned for the workflow of porting a scientific application to a cluster, then to a grid, then integrate it with a portal interface to end up in a production system at the end. This workflow is not valid for many of the software that we have now in AppDB, so the statuses should be changed. Just some of the scenarios that the current values cannot cover:

  • What if somebody targets a prototype system, not a production system? (the b scenario from your suggestion)
  • What it somebody ports an application to infrastructure with a graphical environment and not scripts?
  • What if somebody targets a cloud system, not a grid middleware?

We welcome suggestions from the VT on how to revise these values. Particularly, we expect the VT to define:

  • what statuses are realistic for a science gateway
  • what statuses are realistic for a science gateway enabling technology



Science sub-categories

3. In both subcategories we need science subcategories like chemistry, biotechnology, earth, astrophysics, etc.

Use cases:

a. A typical scientist would like to search the data base in the following way:

"I am interested in an Application-specific science gateway that is in production in the area of astrophysics. Using the subcategories she can quickly to the right set of gateways containg only a small number of gateways that all satisfies her requirements."

b. A biotechnology gateway developer would like to see if there is any generic gateway framework that is in production and from which she can build a SG instance.

UCST comment

Scientific discipline (compulsory) and subdiscipline (optional) are defined for every software in AppDB. Filtering and searching AppDB entries using discipline or subdiscipline is a feature in production.

What the VT should provide feedback:

  • the current values that one can select for discipline and subdiscipline
    • are these the right one?
    • are these complete?

(to register science gateways and science gateway enabling technologies!) (E.g. which discipline should a gateway technology belong to?)

  • the way entries can be searched, filtered and presented by discipline and subdisciline
    • are the searches, gadgets provide enough flexibility?
    • can discipline and subdiscipline searches joined with searches for Status and for Type? (Peter's use case below)




Free tags

4. Free tags should be available. These could be used by the Science Gateways software for example to:

a. Define each application a specific SG is offering (Science Gateways can offer access to one or more software packs)

b. Provide a better categorization of a SG software register. For example, which enabling technology is the SG based on? Later on, this information will be valuable to assess how different technologies are being uptake by SG developers. We are aware of the AppDB gadget and that is easy to build customized AppDB queries.



Cross-references

5. An AppDB software (e.g. SG related entries) should be able to cross-reference with other software already in AppDB. For example, if a SG is based on the WS-PGRADE/gUSE enabling technology, then somewhere in the description of the SG this could be referenced.

a. We are aware that AppDB uses permalinks

b. Are there other ways this could be accomplished?



Mandatory hyperlinks

6. If a SG claims to be in production, an URL and usage policy should be available. A user expects to have at least this information available in order to assess if a certain SG is suitable for him or not.


Status

The above recomendations were recorded as requirements in the EGI RT system (#4520). UCST and AppDB developers are discussing these topics. This page will be update accordingly.