1.

1 Science Gateway
A Science Gateway (SG) is a set of tools, applications and data collections integrated via a web
portal (or a desktop application) to provide collaborative access to computing resources and
services. A commonly accepted definition terms a SG as a “community-development set of
tools, applications, and data that is integrated via a portal or a suite of applications, usually in
a graphical user interface, that is further customized to meet the needs of a specific
community”.

According to the European Grid Infrastructure (EGI) Foundation, SGs are generally
categorised into two principle groups: SG frameworks and SG instances. SG frameworks offer
enabling front-end and back-end technologies that combine to act as a gateway to DCIs. SG
frameworks are generic rather than specific structures, which enables them to be used by
scientists working in many different specialities and locations (Kacsuk, 2014). Examples of
such framework SGs are Catania Science Gateway (Rotondo et al., 2011), GridPort (Dahan
and Boisseau, 2001), Vine Toolkit (Dziubecki et al., 2012) and WS-PGRADE/gUSE (Kacsuk
et al., 2012). SG frameworks offer the advantage of access to large-scale, low-level computing
services. However, to fully exploit the computing power available, scientists will typically
require lengthy training in the underlying technologies and the applications they can host. In
this case, IT specialists can provide valuable assistance in developing specific DCI applications
for the end-user.

In contrast to SG frameworks, SG instances are application-specific gateways intended for use

by scientists working in specific scientific fields. The user interface of such gateways is closely
customized for ease of use by the particular scientific community they serve. This makes such
gateways readily accessible to scientists without too steep a learning curve. However, ready-
for-use, science-specific gateways have the drawback of being limited in the novel services
they are easily able to provide.

The most popular SG frameworks are the Catania Science Gateway and WS-PGRADE/gUSE.
The next section explains these two science gateways in more detail.
1.1.1 Catania Science Gateway Framework
The Catania Science Gateway Framework (CSGF) enables easy access to original software
architecture (see Figure ), distributed infrastructures and remote resources available on the web
or cloud. Certification rules for each user ensure that security is not compromised when
accessing the distributed architecture. The CSGF comprises seven principle interrelated
components that perform specific functions within the framework. These components are the
Catania Grid and Cloud Engine, the Liferay portlets layer, the e-Infrastructures layer, the SG
interface (portlets layer), the SAGA/JSAGA interface, the eToken server and the Users
Tracking database (Rotondo et al., 2011).

Figure 1: The Catania Science Gateway Architecture

The Catania Grid and Cloud Engine

Catania Grid and Cloud Engine is a generic software module that is at the core of the CSGF.
The presentation layer is connect by the engine to underlying distributed infrastructures using
basic technologies. Developers are able to use the Simple API for Grid Applications (SAGA)
standard – a protocol supported by the Open Grid Forum (OGF) – as an interface with standard
functionality. SAGA is implemented using its Java-based interpretation, JSAGA. The
SAGA/JSAGA interface enables developers to create new SGs without needing to understand
the middleware used to connect with grid/cloud infrastructures. The three elements
contributing to the functionality of the Catania Grid and Cloud Engine are the Data engine, the
Job engine, and the Users tracking and monitoring database.

The Data Engine

The data engine module maps data operations to JSAGA functions by simulating a file tree
system similar to that on a physical disk. This enables transfer of data between the SG and the
grid or cloud resources and full exploitation of the data management services.

The Job Engine

The Job engine module manages job execution through the workflow life cycle. In common
with the Data engine, the Job engine maps all job operations to JSAGA functionalities allowing
users full use of the job management services. Job requests from the SG interface are received,
submitted, and managed by the Job engine through to final output(s). The Job engine also
manages activities such as associating jobs with a proxy, meeting additional user requirements,
and sourcing a suitable resource manager. The Job engine interfaces with the eToken server to
accept end-user proxies for job submissions. It also updates the User Tracking and Monitoring
module with all user activities conducted on grid/cloud resources.

The User Tracking and Monitoring DB

The User Tracking and Monitoring database stores information on every grid/cloud transaction.
As an accounting source, the database stores information on every operation by each user to
ensure non-repudiation. The module also implements flow control over the rate of interactions
executed and the number of job submissions per user and per SG.

Science Gateway Interface

The Science Gateway interface is the medium that receives requests from SG portlets to submit
jobs. Through this interface, portlets call the functions of the Grid and Cloud Engine, which in
turn calls the functions of JSAGA (see below). It enables the seamless execution of SG portlet
jobs on distributed resources.
Simple API for Grid Applications (SAGA) and Java implementation of SAGA (JSAGA)

SAGA is a software library for high level grid applications that are defined by the Open Grid
Forum (OGF). The Catania Grid and Cloud Engine uses SAGA’s Java implementation known
as JSAGA. Using JSAGA enables original interfaces to be created to various middleware
stacks. It thus enhances the ability of SGs to exploit the resources of many different grid
infrastructures. JSAGA also allows job and data management independent of the middleware
used.

e-Token server

Security for all middleware transactions is achieved using X.509 robot certificates for
authorisation. A dedicated e-Token server receives plugged-in e-Token USB smart cards and
then generates a proxy certificate for each end-user. This ensures non-repudiation, reliability,
and confidentiality.

1.1.2 WS-PGRADE/gUSE Science Gateway Framework

The architecture of WS-PGRADE/gUSE framework is shown in Figure . The Web Services
Parallel Grid Runtime and Developer Environment Portal (WS-PGRADE) is a generic-
purposed, web-portal interface that helps users design scientific workflows. gUSE (grid and
cloud User Support Environment) is a middle layer workflow specification system. The web
service-based DCI Bridge uses plug-ins to give access to various infrastructures such as grids
and clouds (Kacsuk et al., 2012).

WS-PGRADE is a generic-purposed, workflow-oriented graphical user interface that provides

services enabling workflow applications to be created for execution on various DCIs such as
grids, clusters and clouds. The workflow orientation of WS-PGRADE/gUSE distinguishes it
from other SG frameworks. Its three most significant features are: workflow support,
facilitation of multi-DCI workflow execution, and an ability to customize the framework for
application specific SGs. WS-PGRADE/gUSE has three main tiers: Presentation tier, Middle
tier, and Architectural tier.
 Figure 2: WS-PGRADE/gUSE Architecture

Graphical User Interface: WS-PGRADE (Presentation tier)

The presentation tier consists of the graphical WS-PGRADE user interface of the generic DCI
gateway framework. The presentation tier can be customised to meet different community
needs, which makes the generic DCI gateway framework readily accessible to different types
of users.

The first category of user is the workflow developer who acts for end-user scientists. The task
of the workflow developer is to edit, configure, and run workflows before they are uploaded to
the repository where scientists can access and use them. WS-PGRADE supports workflow
development activities.

The second category of user is end-user scientists who are unfamiliar with both the underlying
infrastructures involved in distributed computing and the workflow structure required to run
scientific applications. Often, it is only necessary for such end-users to download an
appropriate workflow from the Application Repository and customize it for parametric sweeps.

A third category of user is developers of portlets that have specific application requirements
such as original interfaces or other application specific needs. This category is addressed by
provision of the Application Specific Module (ASM) API that simplifies portlet customization.
In this case, the customized ASM user interface replaces the WS-PGRADE user interface and
is used to access gUSE services through the ASM API.

A fourth user category is those end-users who are familiar with using a particular application-
specific user interface and wish to employ this in order to access various DCIs.

The final category of users includes those who wish to access gUSE services without a specific
user interface. Provision of the gUSE remote API facilitates this by enabling WS-PGRADE
workflows to be run via a direct API.

gUSE Services (Middle tier)

The grid and cloud User Support Environment (gUSE) information services reside in the
middle architectural layer together with the workflow storage, file storage, workflow
interpreter, and application repository. gUSE is essentially a workflow system that enables
specification of tasks for execution by individual applications on a variety of DCIs. Originally
developed to support grid computing, gUSE treats all DCIs alike and is therefore suitable for
all DCI formats including use of the cloud.

Job Submission Service: DCI-Bridge (Architecture tier)

The DCI-Bridge is used to provide standard access to different DCIs such as grids, desktop
grids, clusters and clouds. It eliminates the need to use different submitters for each DCI
configuration requiring support. The DCI-Bridge is a web service-based application with major
components that include the Resource Registry, Application Management, Runtime System,
and the Monitor component – all of which can be run from a Tomcat-based web container. The
Resource Registry subsystem provides an online configuration interface and delivers
configuration information to other software components. The Basic Execution Service (BES)
interface is used to submit and manage end-user workflows. The Application Management
subsystem implements the BES-Management port type. The Runtime system accepts all
standardized JSDL job description documents from the workflow interpreter service.

1.1.3 The CloudBroker Platform

The CloudBroker platform is a store for applications and a middleware system for deploying
and executing technical and scientific software on heterogeneous cloud infrastructures. It is
available as an on-demand, pay-per-use service via a web-based interface or a web service API.
Access to various public and private cloud technologies is managed by plug-in modules. It
employs SSL encryption between user and the CloudBroker platform and between the platform
and the cloud. An overview of CloudBroker platform functionality is shown in Figure .

Figure 3: The CloudBroker Architecture

CloudBroker can be accessed with any normal web browser and is used to manage and operate
software on a cloud either as a front-end or a back-end service. Alternatively, API access is
provided for frequent or advanced automatic use. Facilities include a REST-based interface,
Linux shell command line interface, and a Java client library.

The CloudBroker platform utilizes IEEE standard applications and server technologies and
commonly operates in secure data centres. CloudBroker is also a marketplace in which users
can deploy their own applications and resources, pay for the use of resources deployed by
others, or use those offered by CloudBroker.