Sharing Science Gateway Artefacts Through Repositories - Science Gateways for Distributed Computing Infrastructures - page 127

versions to help repository users browse and search effectively. In addition to this
the portlet repository can act as a hub for releasing updates to maintained portlets
throughout the development lifecycle. The second scenario involves a user, either a
researcher or a portlet developer, who does not have to be registered in the portlet
repository. They can click on the

tab and can browse all the public
portlets. They can also search by knowledge domain (category) or by keywords
(tags) to

“ Portlets ”

find a suitable portlet. They then have access to the files for each publically

available version and links to documentation or support.

9.5 Supporting Work fl ow Interoperability

To address workflow interoperability the SHIWA project developed the coarse-
grained interoperability (CGI) approach (Terstyanszky 2014). SHIWA created and
deployed a production-level CGI service, called the SHIWA Simulation Platform
(SSP) (Korkhov 2013) to enable execution of workflows created in different
workflow systems and executed on different distributed computing infrastructures
(DCI). Several research communities use the CGI concept to create, integrate, share
and run workflows.
CGI concept : CGI is based on workflow engine integration approach. It manages
non-native workflows as black boxes. These workflows are described as legacy
applications and their descriptions are uploaded to the SHIWA Workflow Reposi-
tory. These descriptions identify the workflow engine that can execute the work-
flow. The CGI concept manages two workflow types: native and non-native
workflows. Workflows of the host workflow system are called native workflows,
while all others are considered as non-native ones. In the WS-PGRADE/gUSE
gateways, the native workflow system is the WS-PGRADE workflow system. All
others such as Galaxy, Kepler, MOTEUR, Taverna, etc., are managed as non-native
workflows. According to the CGI concept, the native workflow engine (workflow
engine A) contacts a submission service when it identi

es a workflow of a non-
native workflow engine (workflow engine B) and forwards the workflow ID to the
submission service. It retrieves the non-native workflow from the repository and
associates it with the workflow engine that can run it. Finally, the submission service
forwards the workflow to the associated workflow engine, which then executes the
workflow. To support the CGI concept, a gateway based on WS-PGRADE can be
connected to two SHIWA services: SHIWA Workflow Repository, to publish and
import workflows, and SHIWA Submission Service, to run non-native workflows.
SHIWA architecture : The simulation platform (Fig. 9.5 ) contains a portal
(SHIWA portal), a submission service (SHIWA Submission Service), and a work-
flow repository (SHIWA Workflow Repository). The SHIWA portal is a general
purpose gateway based on the WS-PGRADE/gUSE framework. It has a built-in
workflow system: the WS-PGRADE workflow system, which is used as the native
workflow engine. The SHIWA Workflow Repository stores the formal description