1

Developing domain specific gateways based on the WS-PGRADE/gUSE framework

http://www.sci-bus.eu

Peter KacsukMTA SZTAKI

Start date: 2011-10-01 Duration: 36 months

SCI-BUS is supported by the FP7 Capacities Programme under contract nr RI-283481

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) (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

WF (Application) Developers (500-1.000)• 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

WS-PGRADEWF

DeveloperUI

gUSE DCI Bridge

DCI 1

DCI 2

DCI n

ApplicationSpecific

User Interface

ExistingApplicationSpecific UI

WS-PGRADEEnd-User

UI

Remote API

BES interface

ASM API

A

B

C

D

E

BES interface

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 gatewayWhat 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 gatewayWhat 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 agUSE 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 same2.The WF developer gateway could be the SZTAKI gateway, the execution gateway the community’s gateway

Scenario 4: Use own gateway with agUSE 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

WS-PGRADEWF

DeveloperUI

gUSE DCI Bridge

DCI 1

DCI 2

DCI n

ApplicationSpecific

User Interface

ExistingApplicationSpecific UI

WS-PGRADEEnd-User

UI

Remote API

BES interface

ASM API

A

B

C

D

E

BES interface

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