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-283481

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

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

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 (500-1.000) Develop WF applications Publish the completed WF applications for end-users SHIWA project End-users (e-scientists) (50.000-1.000.000) Execute the published WF applications with custom input parameters by creating application instances using the published WF applications as templates 4

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

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

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

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

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

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

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

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