=Paper=
{{Paper
|id=None
|storemode=property
|title=Rapid Prototyping of Science Gateways in the Brazilian National HPC Network
|pdfUrl=https://ceur-ws.org/Vol-993/paper8.pdf
|volume=Vol-993
|dblpUrl=https://dblp.org/rec/conf/iwsg/BastosMG13
}}
==Rapid Prototyping of Science Gateways in the Brazilian National HPC Network==
https://ceur-ws.org/Vol-993/paper8.pdf
Rapid Prototyping of Science Gateways in the
Brazilian National HPC Network
Bruno F. Bastos, Vinicius M. Moreira and Antonio Tadeu A. Gomes
National Laboratory for Scientific Computing (LNCC)
Petrópolis-RJ, 25651–075, Brazil
Phone: +55-24-22336202
Email: bfbastos@lncc.br, vmacedo@lncc.br, atagomes@lncc.br
Abstract—Arguably, an important amount of scientific soft- tools specifically devised for helping with the development
ware development time is likely to be employed on user interfaces. of science gateways are used. In the second solution, content
In particular, science gateways have gained increasing interest management tools are adapted to properly interface with the
from the e-Science community because of their convenience to computational and data resources employed by researchers.
hide the complexity of the underlying resources that give support Crucially, such solutions, in their current form, require a sub-
to the management of scientific data and to the execution of
scientific applications. Based on our previous experience with the
stantial effort from the scientific application developer, whether
development of science gateways for diverse application domains it be for development, for configuration, or for deployment of
in the Brazilian National HPC Network (SINAPAD), we have science gateways.
devised a rapid prototyping strategy to lower the barrier for In this paper we propose a toolset specifically built for
scientific application developers to launch new science gateways.
In this paper we present such strategy, which is based on two
the rapid prototyping of application-specific science gateways.
main tools. The first tool implements a gateway engine that can By application-specific we mean the provisioning of narrow
be configured by a small set of XML files. Such files completely interfaces to researchers, i.e. interfaces that are adapted to the
define the desired functionality of an specific science gateway in particularities of specific scientific applications, as opposed to
such an engine. The gateway engine also offers other features interfaces that expose typical science gateway services (such
not commonly found in related technologies, such as file sharing, as job submission and monitoring) without regard to such
data provenance tracking, and restricted anonymous access to particularities. In contrast to the aforementioned solutions, the
underlying computational resources. The second tool implements purpose of the proposed toolset is to provide the simplest en-
both an editor and a packager for the aforementioned engine, vironment as possible for configuring such gateways, without
allowing the developer to rapidly deploy and launch a new science any development or deployment effort by the scientific appli-
gateway in ordinary Web application containers. In this paper
we present our results with the use of both tools in the SINAPAD
cation developer. Moreover, the toolset offers some specific
network. We also discuss about the current limitations of such features not commonly found in the aforementioned solutions
tools, as well as how we have been dealing with such limitations and which can be easily enabled or disabled individually for
to provide a more comprehensive toolset to developers. each gateway through configuration, such as: (i) file sharing
between gateway users, (ii) support for provenance tracking of
I. I NTRODUCTION jobs’ data inputs and outputs, and (iii) support for restricted
anonymous access to gateway services.
Science gateways allow researchers to interact in a con-
venient way (using mainly Web-based technologies) with The proposed toolset comprises two tools. The first tool,
diverse computational and data resources—e.g. HPC clusters, called PortEngin, implements a gateway engine that is de-
mass storage servers, computational grids and public/private ployed on a Web server like any ordinary Web application.
clouds—, aiming at the management of scientific data and the Such engine is configured by a small set of XML files that
execution of scientific applications on such resources. In some describe the interface to be expected by the user of the intended
cases, such gateways also provide collaboration tools that allow scientific application, as well as the enabling of the specific
researchers to share scientific data with the remainder of its gateway features mentioned above. The PortEngin tool is built
scientific community. upon the basic services for job and data management provided
by the CSGrid middleware, an instantiation of the CSBase
The primary purpose of a science gateway is to allow framework [1] that has been specifically customized for the
researchers to increase their productivity by concentrating Brazilian National HPC Network (SINAPAD)1 to integrate its
mainly on the subject of their research, and not on the details geographically-distributed, highly-heterogenous computational
of the computational tools that are offered him to conduct such and data resources. This paper also describes some extensions
research. Ideally, none of such tools should be dealt with by to the CSBase framework that we have implemented for it
the researcher itself, but instead by a scientific application de- to cope with the specific science gateway features mentioned
veloper. By such developer we mean the staff responsible for above.
building, deploying, and (sometimes) optimizing the scientific
software the researcher is interested in using. The second tool, called PortEditor, aims at aiding the scien-
tific application developer in the edition of the XML files that
Historically, the development of science gateways has been
typically based on two main solutions. In the first solution, 1 http://www.lncc.br/sinapad
set up the PortEngin tool. Besides its edition capabilities, the complexity of the architecture resulting from this integration
PortEditor tool is also responsible for packaging the configured makes the process of configuring and deploying these gateways
engine, so that it can be easily deployed and launched by the considerably difficult and prone to errors.
developer on a typical Web application container.
III. T OOLSET ARCHITECTURE
The remainder of this paper is organized as follows.
Section II describes some of the most popular solutions for The toolset is divided into three layers. The bottom layer
the development of science gateways found in the literature. provides access to the basic data and job management services
Section III presents the overall architecture of the proposed offered by the CSGrid middleware, as detailed in Subsec-
toolset. It also provides some background on the CSGrid tion III-A. The middle layer extends the CSBase framework
middleware technology, which is needed for understanding so that our instantiation of the CSGrid middleware becomes
the modus operandi of the PorEngin tool, and describes able to provide the additional features of file sharing, restricted
some extensions that we have implemented in our CSGrid anonymous access and data provenance tracking, as described
instantiation of the CSBase framework for it to cope with in Subsection III-B. The top layer implements the PortEngin
the specific needs of science gateway technologies such as the tool, which is responsible for building dynamic Web pages
one proposed herein. Section IV illustrates and discusses about based on the settings defined by its XML configuration files,
the use of the proposed toolset in some portals currently on as shown in Subsection III-C. The PorEditor tool also resides
operation in the SINAPAD network. Section V provides some in the top layer, being responsible for the edition of such
concluding remarks as well as our perspectives on future work. configuration files and the packaging of PortEngin for its de-
ployment and launching on typical Web application containers.
II. R ELATED WORK The settings that the developer must do for customizing a
gateway to a specific application domain are presented in more
Historically, the development of science gateways has been detail in Subsection III-D.
typically based on two main solutions. In the first solution,
specific tools for the development of science gateways are A. CSGrid basic services
used. Among the many examples of this approach, the most
probably known are Gridsphere,2 used in TeraGrid (now The CSGrid middleware is an instantiation of the CSBase
XSEDE),3 and the GENIUS Grid Portal,4 used in the EGI framework, which is illustrated in Figure 1. The CSBase
infrastructure.5 Science gateways that use this kind of tool framework is based on central server (a server farm implemen-
implement environments that abstract away the details of the tation is also possible) in charge of managing all the underlying
computational resources in which scientific applications are computational resources available to its users. Such server
executed, providing a single access point to such resources. also manages a data repository that comprises a user directory
Such gateways, in its simplest form, are built for general (for authentication and authorization purposes), a project area
use, offering secure access to computational resources, job (where user files are stored), and an algorithm repository. In the
submission and monitoring and file management operations, CSBase framework, an “algorithm” is an abstraction used for
but exposing these services without regard to the particular referring to scientific applications implemented as executable
needs of specific scientific communities. The development of scripts or binaries that accept input parameters and generate
application-specific gateways is possible and has been done outputs, but do not have any type of user interaction during
in this type of tool, but such approach requires a substantial its execution.
development and configuration effort from the scientific appli- A set of execution daemons is responsible for locally
cation developer [2]. managing the computational resources that are provided to
In the second solution, content management tools are the execution of algorithms. In HPC clusters, for instance,
adapted to interface with the computational resources in which such daemons interact with local resource managers such as
the scientific applications are run. A commonly found ex- SLURM, SGE, and PBS, allowing the submission and mon-
ample of this approach is by employing Liferay.6 Science itoring of algorithm executions onto the job queues provided
gateways that use this type of tool implement highly effective by such managers.9 Likewise, a set of CSFS (CSBase File
environments for collaboration and data sharing. Nevertheless, System) daemons is responsible for transferring data (e.g.
adjusting such tools to properly interface with the underlying input/output files, scripts, binaries) from and to the local
computational resources depends on a considerable develop- filesystems of such resources.
ment effort that does not receive direct support from such The CSBase framework allows different technologies to
tools [3]. In this direction, some projects, such as Vine Toolkit7 be used for its user directory and for remotely accessing the
and EnginFrame,8 have provided support for the integration local filesystems of the underlying computational resources. In
of these tools in the context of grid computing and have our instantiation of the CSBase framework, the user directory
been used to provide application-specific science gateways to is implemented by an LDAP server, and the filesystems of
the particular needs of some communities [4]. However, the the underlying computational resources are accessed via the
2 http://www.gridsphere.org/gridsphere/gridsphere SSH/SCP protocol.
3 http://www.xsede.org
The CSBase framework implements a set of services, some
4 http://egee.cesnet.cz/en/user/genius.html
5 http://www.egi.eu/
of which are available strictly from desktop applications. One
6 http://www.liferay.com/products/liferay-portal/overview 9 In our CSGrid instantiation of the CSBase framework all computational
7 http://vinetoolkit.org/
resources are regarded as job queues, irrespective of them being part of HPC
8 http://www.nice-software.com/products/enginframe clusters, computational grids or public/private clouds.
Fig. 1. CSBase Architecture (based on: [1]).
example of such application is the CSGrid desktop client, framework, and consequently the PortEngin tool, to make it
which offers a set of administrative tools for the CSGrid completely transparent to the researcher not only in which
middleware (e.g. for resource management, user management, computational resource, but also in which type of computa-
and algorithm management). Other CSBase services are also tional resource—whether it be an HPC cluster, a computational
exported to external applications through a CORBA-based grid, or a public/private cloud—his/her job is running.
service bus called OpenBus. Such bus is responsible for the
registration and lookup of both external CSBase services ProjectService offers a set of operations for uploading,
and applications that consume such services. Any service or accessing and manipulating files in the project area of the
application that intends to interact with the OpenBus service user. User files are organized by projects, and users can share
bus must have an X.509 digital certificate properly configured their files in a specific project with other users. Other features
in its access control service. offered by the CSBase framework, which are not crucial to the
presentation of our approach, may be found in [1].
Two main basic services exported by the CSBase frame-
work in the OpenBus service bus are of interest for the B. Features added to the CSGrid middleware
present work: OpenDreams (OpenBus Distributed Resource The CSBase framework combines characteristics of typical
and Algorithms Management Service) and ProjectService. gateway development tools (e.g. by abstracting away the details
of the computational resources) with those of content man-
OpenDreams offers a set of operations for the submission, agement tools (e.g. by allowing file sharing between users).
monitoring and control of jobs (algorithm executions in the Nevertheless, some features not offered by such framework
CSBase jargon) on remote computational resources. Its service have been incorporated into our CSGrid instantiation. These
interface is based on OGF’s DRMAA 1.0 specifications [5]. features are presented below. They have been implemented
The OpenDreams service explores the algorithm abstraction in the Java programming language and its documentation is
in the CSBase framework to provide a very flexible approach available at http://www.lncc.br/sinapad/csgrid-api/.
to mitigating resource heterogeneity, which is key feature
for the SINAPAD network. The algorithm repository of the 1) File sharing: The CSBase framework already allows file
CSBase framework allows the same algorithm to have multiple sharing between users. Nevertheless, the configuration of ac-
versions, each one being described by a specific set of input cess permission categories is somewhat complex and restricted
and output parameters. For each algorithm version, multiple to desktop applications that access the internal CSBase services
executable scripts or programs may be provided to reify the (such as the CSGrid desktop client). To allow the researcher
algorithm abstraction in different computational resources. him-/herself to share files in a common area within a science
This feature allows our CSGrid instantiation of the CSBase gateway, as well as publish them for open access from the
Internet, we have implemented an additional functionality in configurable in the PortEngin tool, such as limitations on
our CSGrid instantiation. Such functionality is based on the the input arguments for the algorithms or on the allowed
definition of a special CSBase user called shared. This user algorithm versions and types of computational resources that
cannot execute jobs and just have access to its own project the anonymous researcher may invoke. Details about such
area. configurations are presented in the following section.
In our approach when the researcher shares a file within
a science gateway, he/she is actually copying such file into C. The PortEngin tool
the project area of the user shared. A shared file cannot The architecture of the PortEngin tool is illustrated in
be modified, and only the researcher who shared the file can Figure 2. From the point of view of a scientific application
remove it from the project area of the user shared. Moreover, developer, the PortEngin tool is a simple Web application that
any researcher can directly copy a shared file into his/her own needs an ordinary Java Servlet container for its deployment.
project area (without needing to download and subsequently From the point of view of an administrator of the CSGrid
upload the file), which he/she can then modify or use for middleware, the PortEngin tool is an external application
performing a job. that consumes the OpenDreams and ProjectService services
2) Data provenance tracking: In its original structure, the published in the OpenBus service bus. The PortEngin tool
CSBase framework keeps a history of job submissions, but creates instances of sciences gateways that offer Web interfaces
does not help with preserving the original files a user provides for: (i) uploading, downloading, viewing and editing files in the
as input as well as the output files generated as part of project area of the users, (ii) submitting jobs, including valida-
a specific submission. The user is then solely responsible tion tips on how to fill out the required algorithm arguments,
for keeping track of such files. Nevertheless, automatic data and (iii) monitoring jobs, indicating their unique identifiers,
provenance tracking [6] is very important in e-Science, because in which computational resources such jobs are running and
it guarantees that a certain in-silico experiment be reproducible when they were submitted, among other information.
in the future. The XML configuration files allow the gateway engine to
To support automatic provenance tracking in our CSGrid be customized for each instance of science gateway according
instantiation, we have implemented an additional functionality to the needs of its researchers. These files are:
in it that maintains a history of each job submission, including
the arguments and files used as input and the output files • openbus.xml - defines the digital certificates used by
generated by the algorithm execution. The researcher may then the science gateway for authentication in the OpenBus
download the data stored in such a history by using the job service bus;
monitoring functionality that the PortEngin tool provides to • config.xml - describes the input and output arguments
the science gateways. Importantly, such data is immutable and of the algorithms associated with the science gateway.
kept separated from the project area of the user in the CSBase Such file is used both by the gateway engine for dy-
framework. namically assembling Web pages, and by the CSBase
framework for assembling the invocation command for
3) Restricted anonymous access: The restricted anonymous the specific scripts or binaries that reify the algorithm in
access feature allows an anonymous researcher to use, in a the underlying computational resources;
limited way, a science gateway without needing to provide user • portal.xml - links the science gateway to a project
credentials or to be registered in the CSBase’s user directory. area and defines which algorithms may run through this
We have implemented such feature in our CSGrid instantiation gateway. Such file also defines whether the Web interface
of the CSBase framework through the definition of another will be generated on every re-deploy of the gateway
special CSBase user called guest. For each invocation (ses- or not (this is particularly important when the scientific
sion) of a science gateway that has this feature enabled, application developer intends to change the Web layout
the PortEngin tool creates a temporary folder in the project that the PortEngin tool generates as default).
area of user guest. Such folder is associated with a unique • modules.xml - enables/disables additional features
identifier for that session and can only be accessed during that (seen in Section III-B) to be provided by the science
session. This folder is removed some time (configurable in the gateway;
PortEngin tool) after the execution of the job. • authentication.xml - configures restricted anony-
To submit a job the anonymous researcher shall respond to mous access to the science gateway, when such feature
a visual challenge (a captcha) and enter a valid email address, is enabled (e.g. if an input argument must have a more
which will be used for informing the researcher about the stringent set of allowed values).
completion of the job execution and for providing a URL
(associated with the unique identifier of the corresponding D. The PortEditor tool
gateway session) from where its results can be accessed.
In spite of the fact that the XML files described in
Importantly, these results may be accessible by anyone that
Section III-C have only a few tags to be configured, such
possesses the unique identifier of the gateway session from
configuration may be tricky at times specially with regard to
which the job was submitted.
the parameters that set up the communication with the CSGrid
An anonymous researcher has restrictions that are not middleware. Besides, the packaging of such files together with
configurable in the PortEngin tool, such as not being able the binaries that implement the various functionalities of the
to share files or to keep track of submissions on the science PortEngin tool must follow an strict organization so that it
gateway after closing his/her session. Other restrictions are can be properly deployed in a Web application container.
Fig. 2. The PortEngin tool.
Finally, any science gateway prototyped with the PortEngin associated with this gateway requires very simple input and
tool must have a valid digital certificate registered in the output arguments (one input file, one number, one selection
OpenBus service bus so that it can consume the OpenDreams option, and one directory for output files), and the layout of
and ProjectService services.
Aiming at aiding the scientific application developer in the
aforementioned issues, we have developed the PortEditor tool,
whose interface is presented in Figure 3. The topmost part of
the figure illustrates the functionality of the PortEditor tool
that allows a registered developer to edit previously created
gateways, whereas the bottommost part shows how a new
gateway may be configured. Such tool uses the same LDAP
service that the CSGrid middleware employs for user authen-
tication and authorization, so that only registered developers
can access the tool to rapidly prototype new science gateways.
Once a new science gateway is configured in the PortEditor
tool, a deployment package is provided to the developer (see
the topmost part of Figure 3), so that he/she can deploy it
on a Web application container. Importantly, however, only
after the digital certificate of the newly configured science
gateway has been registered in the access control service
of the OpenBus service bus, will the developer be able to
effectively launch the science gateway for the researchers to
make use of it. To partially automate such process, when a
new science gateway is prototyped in the PortEditor tool, the
CSGrid administrators receive an email message informing
them about such configuration so as for them to evaluate it
and proceed with the certificate registration accordingly.
IV. E XAMPLES
Figures 4 and 5 show screenshots of two science gateways
currently on production in the SINAPAD network that have
been prototyped with the PortEngin tool.
The first example (DANCE – http://www.lncc.br/sinapad/
DANCE) provides a service for the efficient evaluation of
different kinds of network centralities in complex networks [7].
Figure 4 shows, from top to bottom, the Web pages for job
submission and monitoring and file sharing that have been
automatically generated by the gateway engine. The algorithm Fig. 3. The PortEditor tool.
this website is the default one generated by the gateway engine. functionality, and had its Web layout modified by the developer
of the ProFraGer software. It is important to notice that the
layout of the Web interface provided by the science gateway
is unrelated to the operation of the gateway engine. Therefore,
the Web layout may be modified by editing the HTML, CSS
and JSP files that define such interface, without any change in
the implementation of the gateway engine itself.
Fig. 5. The ProFraGer science gateway.
There are a few other application-specific science gate-
ways that are currently on production in the SINAPAD net-
work. Such gateways are listed in htttp://www.lncc.br/sinapad/
portais.php.
A. Discussion
During our prospecting for new developers and researchers
interested in using our proposed toolset, some of them reported
two main limitations in it: the lack of support for command-
line interfaces, and the poor integratability of PortEngin with
Fig. 4. The DANCE science gateway. widely used content management tools such as Liferay. Our
approach to tackle such limitations was to split the PortEngin
The second example (ProFraGer – http://www.lncc.br/ tool into two sublayers: a lower core sublayer and a higher
sinapad/Profrager) provides a service for generating libraries of user interface layer.
protein fragments. Figure 5 shows the Web page for submitting The core sublayer implements an API for the higher layer
ProFraGer jobs that has been generated by the gateway engine. to programmatically access, in a convenient way, the various
The algorithm associated with this gateway, unlike DANCE, services offered by the PortEngin tool. The documentation for
requires a much larger and more varied set of input arguments such API is available at http://www.lncc.br/sinapad/core-api/.
(files, values and ranges, selections), which are reflected in
the Web page dynamically assembled by the gateway engine. The higher user interface layer allows different interface
This gateway implements the restricted anonymous access personalities to be implemented over the lower sublayer. One
get - downloads a file in the project area of the user onto the local filesystem
Usage: get --project
--file
--dest
list - lists the files in the project area of the user (optionally from a specific path in such area)
Usage: list --project
[--dir ]
put - uploads a file or directory in the local filesystem onto the project area of the user.
If uploading a directory, provide a ZIP file of the desired directory and use the switch --directory
Usage: put --project
--file
--dest
[--directory]
remove - removes a file in the project area of the user
Usage: remove --project
--file
queues - lists the computational resources available for an specific algorithm (optionally for a specific version).
Usage: queues --algorithm
[--version ]
run - runs an algorithm (optionally using an specific version, or a specific computational resource).
Other options and flags are algorithm-specific.
Returns the job id of this algorithm execution.
Usage: run --algorithm
[--email ]
[--version ]
[--queue ]
stats - verifies the status of algorithm executions (optionally in a specific state, or during a specific time slot,
or with a specific job id).
Usage: stats --algorithm
[--status (DONE | FAILED | RUNNING | WAITING),..]
[--begin ]
[--end ]
[--job ]
Fig. 6. CLI commands.
such personality is the Web application that implements our the necessary access rights for them. Since the algorithm
current science gateways (such as DANCE and ProFraGer, abstraction and the project areas employed in both personalities
presented in Section IV) and is targeted by our PortEditor tool. are the same, such duality does not incur in an additional
Another personality is a command-line application that allows cognitive load on the researchers [8].
the researcher to have access to the underlying computational
and data resources by means of a terminal shell interface. A single command-line application is responsible for im-
Such personality is further described below. Other personalities plementing all available commands in the CLI personality.
may be developed, allowing the lower core sublayer to be Such application is registered in the OpenBus service bus so
easily integrated, for instance, with Liferay. Such approach as to be able to consume the OpenDreams and ProjectService
has been adopted in the implementation of a Liferay-based services. Such application is accessible through an SSH server
web portal for climatology applications, which is available at available in the SINAPAD network.
http://cenapadportal.cptec.inpe.br/.
V. C ONCLUSION
The command-line interface (CLI) personality offers re-
searchers the most flexible way for them to manage job Our experience with the provisioning of HPC services
submissions and project areas in the underlying resources that to the Brazilian scientific community through the SINAPAD
comprise the SINAPAD network. Using such interface the network clearly demonstrates that much of the effort em-
researcher may, for instance, automate the submission and ployed by scientific application developers (and often re-
monitoring of a (possibly huge) batch of jobs in a single script. searchers alike) is either on learning the idiosyncrasies of
Such approach is particularly useful in scientific experiments the highly-heterogeneous computational resources that com-
based on parameter sweeping or Monte Carlo methods. prise the SINAPAD network (e.g. available compilers, local
resource managers, hardware architectures), or on the ad-hoc
Figure 6 presents the main commands which are offered development of customized, Web-based science gateways that
by the CLI personality to the researcher. Crucially, all such provide transparent access to such resources. The effort pre-
commands have correspondence with operations available in sented herein aims at simplifying the development of science
the Web-based science gateways that employ the PortEngin gateways through a “zero programming” strategy. In such a
tool. Moreover, all algorithms and projects that are accessible strategy, the configuration of a small set of XML files is
from the Web-based science gateways may be also accessible sufficient to enable any supported functionality in the gateway
through the CLI personality, provided that the researcher has engine that underlies the application-specific science gateways
offered in the SINAPAD network. Importantly, the inclusion [8] F. Paas, A. Renkl, and J. Sweller, “Cognitive load theory: Instructional
of a new CLI personality in our gateway engine copes with the implications of the interaction between information structures and
specific needs of some researchers as regards the automation cognitive architecture,” Instructional Science, vol. 32, no. 1-2, pp.
1–8, 2004. [Online]. Available: http://dx.doi.org/10.1023/B%3ATRUC.
of submission and monitoring of batches of jobs. 0000021806.17516.d0
It is worth considering that this paper has not mentioned
an important trend in e-Science: the use of scientific workflow
management systems (SWMSs). Nevertheless, taking as the
sample space the researchers that make use of the computa-
tional resources provided by the SINAPAD network, it seems
that the vast majority of the Brazilian scientific community is
either: (i) still pretty much unaware of the facilities that the
SWMSs may provide or (ii) does not see value in such facilities
due to the deployment effort that such systems might demand
from the scientific application developers, when one considers
the integration of such systems with the highly-heterogeneous
computational resources of the SINAPAD network. In this
sense, we have progressed work on the integration of some
worldwide-known SWMSs such as Galaxy10 and Taverna11 in
our toolset by turning them onto other personalities that make
use of the lower core sublayer described in Section IV-A.
ACKNOWLEDGMENT
This work was partially supported by the Brazilian Ministry
of Science, Technology and Innovation (MCTI), and by the
Brazilian National Research and Education Network (RNP).
The authors thank Klaus Wehmuth and Artur Ziviani for
their involvement in the configuration of the DANCE science
gateway. The authors also thank the Group for Molecular Mod-
eling of Biological Systems at LNCC for their involvement in
the configuration of the ProFraGer science gateway, and also
for their valuable suggestions that considerably improved our
toolset.
R EFERENCES
[1] M. Julia de Lima, C. Ururahy, A. Lucia de Moura, T. Melcop,
C. Cassino, M. N. dos Santos, B. Silvestre, V. Reis, and R. Cerqueira,
“CSBase: A framework for building customized grid environments,” in
Proceedings of the 15th IEEE International Workshops on Enabling
Technologies: Infrastructure for Collaborative Enterprises, ser. WETICE
’06. Washington, DC, USA: IEEE Computer Society, 2006, pp. 187–
194. [Online]. Available: http://dx.doi.org/10.1109/WETICE.2006.26
[2] N. Wilkins-Diehr, D. Gannon, G. Klimeck, S. Oster, and
S. Pamidighantam, “TeraGrid science gateways and their impact
on science,” Computer, vol. 41, pp. 32–41, November 2008. [Online].
Available: http://dl.acm.org/citation.cfm?id=1477047.1477119
[3] TeraGrid Forum, “Liferay: recommendations from selected users,” 2012,
http://teragridforum.org/mediawiki/index.php?title=Liferay.
[4] R. Barbera, G. La Rocca, R. Rotondo, A. Falzone, P. Maggi,
and N. Venuti, “Conjugating science gateways and grid portals into
e-collaboration environments: the Liferay and GENIUS/EnginFrame
use case,” in Proceedings of the 2010 TeraGrid Conference. New
York, EUA: ACM, 2010. [Online]. Available: http://doi.acm.org/10.
1145/1838574.1838575
[5] Open Grid Forum, “Distributed resource management application API
specification 1.0,” 2008, http://www.ogf.org/documents/GFD.133.pdf.
[6] Y. L. Simmhan, B. Plale, and D. Gannon, “A survey of data provenance
in e-science,” SIGMOD Rec., vol. 34, pp. 31–36, September 2005.
[Online]. Available: http://doi.acm.org/10.1145/1084805.1084812
[7] K. Wehmuth and A. Ziviani, “Distributed assessment of network central-
ity,” CoRR, vol. abs/1108.1067, 2011.
10 http://galaxyproject.org
11 http://www.taverna.org.uk