1. Peter Kacsuk, Zoltan Farkas MTA SZTAKI
Developing Customised Science Gateways at Various Levels of Granularity
Tamas Kiss, Attila Sasvari, Peter Borsody, Gabor Terstyanszly
University of Westminster
Peter Kacsuk,
Zoltan Farkas
MTA SZTAKI
International Workshop on Science Gateways
4th June 2013
Zurich, Switzerland
SCI-BUS is supported by the FP7 Capacities Programme under contract nr RI

2. How to build a science gateway?
Option 1: Build from scratch
Unless the gateway is extremely simple, it requires long time, substantial manpower and development cost to develop a robust gateway
It is probably highly specialized and it may be difficult to extend in a scalable way
It typically represents an isolated development without belonging to a larger (open source) community

3. How to build a science gateway?
Option 2: Adapt and customize an existing gateway framework
Significantly reduces development time
Requires limited manpower and development cost
Produces a robust and usable service
The open source community is driving force for further development and extensions

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

5. WS-PGRADE/gUSE Generic-purpose gateway framework
Based on Liferay
General purpose
Workflow-oriented portal framework
Supports the development and execution of workflow-based applications
Enables the multi-cloud and multi-DCI execution of any WF
Supports the fast development of SG instances by a customization technology
Provides access to application/workflow repositories
internal repository
external SHIWA Repository

6. gUSE – grid User Support Environment Scalable architecture based on collaborating services

7. Molecular docking simulations
The user scenario
Molecular docking simulations
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
Random blind docking:
Uses AutoDock 4
1 receptor and 1 ligand file (pdb or pdbqt)
grid and docking parameter files
number of iterations
number of lowest energy results
Virtual screening:
Uses AutoDock Vina
1 receptor file
a library of ligands
grid and docking parameter files
number of work units (granularity)
number of lowest energy results

8. Granularity 1: Deploy the generic gUse framework for end-users
What is required from the end-user?
Design and configure workflow
Execute and monitor workflow
What needs to be done by the gateway/application provider (system administrator)?
Deploy gateway out of box

9. Granularity 2: Pre-create workflows for end-users
What is required from the end-user?
Import workflow from repository
Customise, execute and monitor workflow
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

10. Granularity 3: The end user view
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

11. Granularity 4: Completely customised gateway
What is required from the end-user?
Customise, 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

12. Any questions? Conclusions?
Sorry, but time is far too short for that (but happy to discuss after the presentation).
Any questions?