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