1 Developing domain specific gateways based on the WS- PGRADE/gUSE framework Peter Kacsuk MTA SZTAKI Start date: Duration: 36 months SCI-BUS is supported by the FP7 Capacities Programme under contract nr RI

2 How to build a science gateway? 1.Build from scratch –If the gateway is not extremely simple, it requires long time to develop a robust gateway –Requires substantial manpower and development cost –It is very specialized and as users start to use it and come up with new requirements it is difficult to extend in a scalable way –Isolated development without belonging to an open source community => sustainability is difficult

3 How to build a science gateway? 2. Adapt and customize an existing gateway technology –Significantly reduces development time (e.g. Yuri Gordienko’s talk) –Requires limited manpower and development cost –Produces a robust and usable service –The open source community is driving force for further development and extensions SCI-BUS provides the required core gateway and customization technology

Who are the members of an e-science community regarding Option 2? End-users (e-scientists) ( ) Execute the published WF applications with custom input parameters by creating application instances using the published WF applications as templates WF (Application) Developers ( ) Develop WF applications Publish the completed WF applications for end-users SHIWA project SG Instance Developers (50-100) Develop application domain specific SG instance SCI-BUS project Science Gateway (SG) Framework Developers (5-10) Develop generic SG framework SCI-BUS project

Flexible usage scenarios/business models by WS-PGRADE/gUSE Workflow developer view and support (full gateway framework view) End-user view and support (limited portlets) Customized user interface to support the creation of domain specific gateways (ASM API) Provide workflow execution service on top of many different DCIs (Remote API) 5

Typical usage scenarios of WS- PGRADE/gUSE 6 ASM API WS-PGRADE UI Customized UI Other, existing UI Workflow execution service from existing portal (e.g. VisIVO mobile)

Gateway types based on WS-PGRADE/gUSE For developing workflow (WF) applications for a large set of various DCIs Developed WF Internal gUSE Repository End User mode WS- PGRADE/gUSE gateway generated by configuration Customized gUSE gateway with portlets developed by ASM API Generic WS-PGRADE/gUSE gateway Existing Community Gateway WF execution gUSE gateway Remote API

8 The use case: Molecular docking simulations Random blind docking: Uses AutoDock 4 1 receptor and 1 ligand file (pdb or pdbqt) Virtual screening: Uses AutoDock Vina 1 receptor file a library of ligands AutoDock: –a suite of automated docking tools –designed to predict how small molecules, such as substrates or drug candidates, bind to a receptor of known 3D structure –open source software, around 30,000 users worldwide –two distinct AutoDock versions: –Autodock 4: slower, more complex, more precise (?) –AutoDock Vina: newer, faster, less proven results

Autodock gateway operated by SZTAKI

Autodock and rendering gateway operated by Univ. of Westminster

Scenario 1: Generic gUSE framework as gateway For developing workflow (WF) applications for a large set of various DCIs Place developed WF for own usage Internal gUSE Repository Generic WS-PGRADE/gUSE gateway Examples: SZTAKI Public portal Greek NGI portal Turkish NGI portal

Scenario 1: Generic gUSE framework as gateway What is required from the user (WF developer)? Design and configure WF Execute and monitor WF Export WF to repo What needs to be done by the gateway/application provider (system administrator)? Deploy gateway out of box

Scenario 1/b: Generic gUSE framework with end-user support For developing workflow (WF) applications for a large set of various DCIs WF developer: Places developed WF for end-users’ usage Internal gUSE Repository Generic WS-PGRADE/gUSE gateway

For developing workflow (WF) applications for a large set of various DCIs End user: Takes developed WF for own usage Internal gUSE Repository Generic WS-PGRADE/gUSE gateway Scenario 1/b: Generic gUSE framework with end-user support

What is required from the end-user? Import workflow from repository Customise, execute and monitor workflow Scenario 1/b: Generic gUSE framework with end-user support What needs to be done by the gateway/application provider (system administrator + workflow developer)? Deploy gateway out of box Develop and configure workflows Export workflows to repository

Scenario 2: End-user view based gateway For developing workflow (WF) applications for a large set of various DCIs WF developer: Places developed WF as template for end-users’ usage Internal gUSE Repository End User mode WS- PGRADE/gUSE gateway generated by configuration Generic WS-PGRADE/gUSE gateway End user: Take developed WF template and parameterize it for own run

Scenario 2: End-user view based gateway What is required from the end-user? Import workflow from repository Customise, execute and monitor application using simple web forms What needs to be done by the gateway/application provider (system administrator + workflow developer)? Deploy gateway out of box Develop and configure workflows Create templates and applications Export application to repository

Scenario 3: Completely customised gateway For developing workflow (WF) applications for a large set of various DCIs Developed WF Internal gUSE Repository Customized gUSE gateway with portlets developed by ASM API Generic WS-PGRADE/gUSE gateway Examples: Swiss Proteomics Portal MosGrid Portal VisIVO gateway, etc.

Scenario 3: Completely customised gateway What is required from the end-user? Execute and monitor application using completely customised GUI What needs to be done by the gateway/application provider (system administrator + workflow developer + SG instance developer)? Deploy gateway out of box Develop and configure workflows Export workflows to repository Develop custom GUI using the Application Specific Module (ASM) API accessing gUSE services

Swiss Proteomics Portal (ETH Zurich) 20

Scenario 4: Use own gateway with a gUSE gateway for WF developing and execution 21 For developing workflow (WF) applications for a large set of various DCIs Developed WF Internal gUSE Repository Existing Community Gateway Generic WS-PGRADE/gUSE gateway WF execution gUSE gateway Remote API Possible options: 1.These two gateways can be the same 2.The WF developer gateway could be the SZTAKI gateway, the execution gateway the community’s gateway

Scenario 4: Use own gateway with a gUSE gateway for WF developing and execution See the AEGIS CMPC Scientific Gateway poster as an example Further examples: –4D Soft portal –e-Group portal –VisIVO Mobile 22

VisIVO Mobile Architecture

Scenario 4: Using DCI Bridge as independent service 24 ASM API Own existing UI

Conclusions There is a rich set of options on how to use WS-pGRADE/gUSE technology Think over how you would like to support your community and choose the most suitable option 25