Given their ability to hide the complexities of the underlying computational environment, Science gateways, Grid portals and Web Service interfaces are crucial in enhancing user adoption of e-Infrastructures. Much effort has been invested in this field to create virtual environments that allow researchers to focus on their research carried out within the Virtual Organisations they belong to. The approach presented in the paper follows the Teragrid vision, according to which gateways enable entire communities of users associated with a common scientific goal to use the resources of a cyberinfrastructure through a common interface. The paper describes the EnginFrame framework developed to easily build Science Gateway prototypes and presents a use case from the Life Sciences domain.
One of the most rapidly evolving areas of Grid and Distributed Computing is the construction of Grid Portals, high level graphic interfaces that greatly simplify the execution of scientific applications on e-Infrastructure exploiting the various middleware services in a transparent and ubiquitous way.
The main goal of Grid Portals is to hide the details and the
complexity of the Grid infrastructure from the users in order to
improve usability and utilization of the Grid. Usability can be
enhanced by lowering end-user requirements for accessing the
Grid and verticalizing the service offering. In parallel utilization
can be improved making the Grid evolution transparent to the
enduser and enforcing Grid utilization policies [
A number of Grid portals have become popular in the last few
years in the scientific research community [
DEGREE project1, for example, has particularly been both efficient and effective in the exploitation and dissemination of Grid technology in the field of Earth Science identifying a short list of requirements for Grid portals for Earth Science (ES) applications. In order to achieve its aims of making the Grid easier to use for the ES community, DEGREE has successfully integrated ES applications and middleware functionalities but only within specific web Portals2.
Notable exceptions are the EnginFrame portal3, that boasts relevant
references in the industrial world (Ferrari, Schlumberger, ENI,
Partners Healthcare, etc.) and it has been used in various research
projects such as A-WARE [
Those issues may be approached with a paradigm shift: considering that a portal should be kept as generic as possible, in order to be used by the largest possible number of communities, and considering that scientific communities require specific services, tools and interfaces on top of the general purpose ones, researchers are migrating towards the Science Gateway concept. This is explained in the next section. The EnginFrame framework is outlined in section 3 in the context of a Science Gateway for Life Sciences and an exemplar use case is shown in section 4. Conclusions are then drawn in section 5. 2
According to TeraGrid5, a Science Gateway is a communitydeveloped set of tools, applications, and data that is integrated in graphical user interface via a portal or a suite of applications and that is customized to meet the needs of the targeted community. Some gateways expose customized sets of community codes so that scientists or students can run them. Others bring new services and applications to the community that would not be accessible otherwise. Depending on the needs of the specific community, any of the capabilities listed below should be provided by a typical Science Gateway: (1) (2) (3) (4) (5) (6) (7)
Job execution services: the classical preparation, submission, monitoring and output retrieval;
query data collections, intended as collection of files and describing metadata; Workflows: the possibility to design and run virtual experiments in the form of organized sequence of tasks with inter-dependencies;
of high-end visualization tools and systems to visualize complex and large datasets;
provision data to a specific location accordingly to user, network, and performance requirements; Resource discovery: an indexed collection of resources that applications and user-services will rely on;
services that may collect several of those aspects resulting in end-user applications that address a specific, complex issue.
According to the Science Gateway definition, in the next section we present a Science Gateway for Life Sciences based on EnginFrame, a Grid framework through which it is possible to integrate these functional elements in a stable and powerful environment. Missing key aspects in the above check-list, such as authentication and authorization, will be addressed in detail. 5 Teragrid project, http://www.teragrid.org/gateways/
The Science Gateway described in this section belongs to Life
Science and has its focus on biomedical informatics, in which the
authors have a significant experience [
In this section we will concentrate on the architecture and general functionalities of the portal, based on EnginFrame, while a use case will be presented in section 4.
The work benefits from hardware infrastructure donated as a SUR Grant from IBM to the University of Genoa in 2008. It is composed by a Blade Centre architecture with one visualization blade, four Intel based computing nodes and three IBM PowerCell/ BE based computing nodes. The computing cluster is accessed by users using the portal described in this paper.
Moreover, thanks to the collaboration with RENCI6, North
Carolina, and the INFN GILDA team [
The portal is based on EnginFrame, a framework that allows virtual organizations to provide application-oriented computing and data services both to users (via Web browsers) and in-house applications (via SOAP/WSDL based Web services), hiding all the complexity of the underlying Cluster, Grid, or Cloud infrastructure.
EnginFrame as Grid Portal framework offers a wide range of facilities to IT developers and provides end users with applicationoriented vertical services.
In particular, it simplifies the development of Web portals exposing computing services that can run on different computational Grid systems such as Platform LSF7, Sun Grid Engine8, Altair PBS9, EGEE gLite10, etc.
EnginFrame supports several open and vendor neutral standards, distributed file systems, GUI virtualization tools and different kinds of authentication systems.
The EnginFrame Grid portal receives incoming requests from the Web, authenticates and authorizes the requests, and then executes the required actions in the underlying Grid computational environment. Then, it gathers the results and transforms them into a suitable format before sending the response to the client. Transformation of results is performed according to the nature of the client: HTML for Web browsers and XML for Web-services based client applications.
EnginFrame architecture is layered in three tiers, as shown in Figure 1. 6 Renaissance Computing Institute, http://www.renci.org/ 7 Platform Computing, http://www.platform.com/ 8 Open source Grid Engine, http://gridengine.sunsource.net 9 Altair PBSpro, http://www.altair.com/software/pbspro.htm 10 EGEE gLite, http://glite.web.cern.ch/glite The Client Tier consists of the user's Web browser. In EF, this interface is based on well established Web standards like XHTML and JavaScript. This tier is independent of the specific software and hardware environment used by the end user. The Client Tier also integrates remote visualization technologies.
The Server Tier consists of a Server that interacts with the EF Agents and manages the interaction with the users. EF Server is a Java Web application and must be deployed inside a Java Servlet Container (e.g., Apache Tomcat). It takes care of exposing services to users.
The Resource Tier consists of one or more EF Agents deployed on the back-end infrastructure. EnginFrame Agents are stand/alone Java applications which manage computing resources on user's behalf and interact with the underlying operating system, job scheduler, and Grid infrastructure to execute the portal services (e.g., starting jobs, moving data, retrieving cluster load, etc.). EnginFrame allows exposure of computing services solutions on the Web. This is done by developing XML-based descriptions of the services and scripts representing the actual services implementations. Most of the information managed by EnginFrame is described by dynamically generated XML documents. The source of such information is typically the service execution environment: an XML abstraction layer aims to submit service actions and translate raw results (from the computational environment) into XML structures. The XML abstraction layer is designed to decouple the portal from the actual Grid environment. This characteristic allows to extend the functionalities of the portal by developing ad hoc plug-ins for specific Grid middleware and legacy applications.
A plug-in is a self-contained software bundle that encapsulates XML service descriptions and the scripts or executables involved with the services actions. In other words, a plug-in is a piece of software that extends the EnginFrame portal functionalities in many different areas: • • • • • • • •
Bundle - full featured package containing other plug-ins, e.g. Grid Portal for LSF; Kernel - extension that enriches the portal’s core system, e.g. Enterprise Portal; Auth - extension that authenticates users towards an authoritative source (e.g., Operating system, NIS, LDAP, etc.); Data - extension that helps display user data inside the portal, e.g. a Remote Spooler Plug-in; Grid - extension that connects the Grid portal with a Grid manager, e.g. LSF Power Pack; SOA - extension that transforms the Grid portal into a SOA provider, e.g. the EnginFrame Web Service Integration Kit; Interactive - extension that allows clients to interactively use the applications launched by the Grid portal, e.g. VNC Plug-in; Application – extension providing a set of services for integrated back-end industry applications, e.g. EDA11 or MCAE12 applications.
The plug-in mechanism provided by EnginFrame allows developers to easily and dynamically extend its set of functionalities and services offering a full set of plug-ins targeting each of the domains and capabilities covered by the Science Gateway model. 3.1
A flexible authentication delegation offers a wide set of preconfigured authentication mechanisms: Linux Operating system, NIS, PAM, LDAP, Microsoft Active Directory, MyProxy, Globus, etc. It can also be extended throughout the plug-in mechanism. Besides authentication, EnginFrame provides an authorization framework that allows to define or inherit from the underlying system group of users, access control lists (ACLs) and to bind ACLs to resources, services, service parameters and service results. The Web interface of the services provided by the Portal can be authorized and thus tailored to the specific users’ roles or access rights. 11 EDA: Electronic Design Automation 12 MCAE: Mechanical Computer-Aided Engineering 3.2
EnginFrame supports a wide variety of compute environments like the MAUI and Torque scheduler, PBS (both OpenPBS and PBS Pro), the Platform LSF product suite, Sun Grid Engine, and Grid middleware like Globus, gLite, etc. An XML virtualization layer invokes specific middleware commands and translates results, jobs and Grid resources descriptions into a portable XML format called GridML that abstracts from the actual underlying Grid technology in use. 3.3
Concerning data management, the EnginFrame framework allows
users to browse and handle data on the client side or remotely
archived in the Grid and then to host service working environment
in filesystem areas called Spoolers. On the Grid side, the approach
we followed is twofold: both SRB/iRODS and gLite Grid
middleware can be integrated as DataGrid layers with EnginFrame.
SRB and iRODS
The integration of EnginFrame with SRB is provided through a
plug-in. The set of functionalities includes the possibility to get
and send data to SRB and to browse the SRB structures directly
from the user’s browser. Moreover, the plug-in also extends the
Spoolers view in order to link to SRB areas and see files and
collections together with the metadata associated to them.
The plug-in contains a collection of Unix scripts that interact with
SRB commands, a set of XML services, XSL and Javascript code
[
Another plug-in integrates EnginFrame with iRODS, a data-Grid technology that is an evolution of SRB. The rich set of functionalities includes the ability to get and send data to iRODS and to browse and manage the iRODS data Grid structures directly from the user’s browser. It is also possible to obtain audit data for every object in the data Grid and to retrieve and search for associated metadata, ACL, quota information and so on in a very comfortable way through a web browser.
Moreover, the plug-in provides a unique feature for managing iRODS rules, in order to give the user the ability to visually create, edit, save and run rules.
The plug-in contains a collection of Unix scripts which interact with iRODS commands, rules and microservices, a set of XML services, XSL and Javascript/Ajax code. gLite Concerning the data management with the EGEE middleware, gLite provides three kinds of services to deal with data on the Grid: Storage Elements (SE), the LCG File Catalog (LFC) and the AMGA Metadata Catalog. Files are stored into Storage Elements (SE, the Grid service that takes care of data persistence). Files can be replicated on several geographically distributed SEs for ubiquity, security, redundancy and load-balancing purposes. LFC provides a global hierarchical namespace of Logical File Names (LFNs) of stored files, keeping track of the mapping between these LFNs and the physical replica paths of the storage containing the actual data. Finally, the AMGA Metadata Catalog can include descriptive information (metadata) in the content of each file. Using this metadata, users and applications can make queries to the service to quickly individuate and later retrieve the files they are interested in.
Sometimes the direct usage of the three previous services can be difficult because of the complexity and fragmentation of those service’s APIs. In order to cope with this problem, two higher level services have been developed to provide a transparent and easy interface to the underlying services.
The first is a Java Object Oriented Framework, named Grid
Storage Access Framework (GSAF) [
The second service easily integrable in our portal, is gLibrary [
Several workflow technologies have been integrated in the
EnginFrame framework and can use through it. In the context of
the A-WARE [
A client with pluggable image processing and visualization tools is available through the Web portals powered by EnginFrame. Traditional 2D visualization of graphics and GUI-based applications is possible thanks to the VNC Plug-in for EnginFrame. VNC13 is an industry standard technology for Desktop remotization, since it provides the ability to view a remote computer Desktop on a network connected client with minimal bandwidth overhead, thus making possible to control a computer using DSL and low-level broadband home connections. The VNC plug-in available in EnginFrame covers only 2D applications. To obtain unmodified 3D performances on clients that are not capable of accelerated 3D, an extension to the classical architecture is required. Basically, it consists of compressing the 3D component of the scene (OpenGL) and send it to clients as a separate stream. This is achieved using a visualization plug-in implemented with IBM Deep Computing Visualization (DCV)14, SUN VirtualGL15 and HP RGS16. These are advanced 2D/3D GUI virtualization solutions that can provide 3D content from unmodified 3D OpenGL applications to clients. The approach may benefit from the availability, on the server side, of server nodes equipped with computer graphics hardware.
EnginFrame plays a central role in the remote visualization architecture: it allows users to run and control their interactive applications just using a common Web browser and to share sessions with other users (e.g., for teleconsulting, training, etc.). A screen-shot of the Portal, running two interactive services (a 3D brain viewer and a computational chemistry software) is reported in Figure 2.
Client-server paradigm allows for lightweight, noiseless, low powered and small form factor clients, enabling the provision of complex 3D and 4D data on small client, remote displays and mobile devices. From a computational point of view, computing intensive tasks, such as integration among medical imaging modalities (CT, PET, MRI, fMRI), brain surface extraction, voxel based analysis, are performed on server side and can benefit from powerful hardware. 13http://www.realvnc.com/vnc/index.html 14http://www-03.ibm.com/systems/deepcomputing 15http://www.virtualgl.org 16http://h20331.www2.hp.com/hpsub/cache/286504-0-0-225-121.html Different sites can be integrated into a distributed architecture which enables users to access their data transparently and run complex analyses.
Data are usually stored in different locations - in most cases there is no shared file system or common namespace - and they need to be moved between locations.
For these reasons, components such as File and Replica Catalogs (to keep track where data are stored) and File transfer services (for scheduled, reliable file transfer) represent important layers in every Grid middleware stack.
Depending on the middleware, EnginFrame “speaks” the right language to interact with the appropriate component: e.g., LFC17, SRM18 and gridFTP19 for gLite middleware or iCAT20 and iCommands21 for iRODS.
From the user perspective, distributed data are accessible in an easy and transparent way, regardless their physical location, in line with the concept of global virtual file system(s). 3.7
Resource discovery systems are essential components in every Grid environment because they provide information about Grid resources and their status, with the possibility to use this information for monitoring and accounting purposes. gLite Information System and iRODS Resource Monitoring System are just two examples of solutions we have tested.
EnginFrame has the capability to internally monitor new resources availability. Every time the administrator of the portal publishes a new resource (plugins, computing and storage nodes, services, 17LCG File catalog, http://www.gridpp.ac.uk/wiki/LCG_File_Catalog 18Storage Resource Manager, https://sdm.lbl.gov/srm/ 19GridFTP, http://www.globus.org/grid_software/data/gridftp.php 20ICAT, https://www.irods.org/index.php/iCAT 21iCommands, https://www.irods.org/index.php/icommands features, etc.), it can be automatically visualized and used by the other users entitled to do so.
An example of high-level resource discovery system has been implemented in the context of the A-WARE project. The AWARE architecture basically involves four layers, from the top to the bottom: (1) (2) (3)
Middle-layer: an ESB (Enterprise Service Bus) called ASB (A-WARE Service Bus), an integration layer providing many services and functionalities. E.g. applicative services, Grid integration, Workflow orchestrator, etc; (4)
Grid services are defined in the back-end Grid environment and automatically exposed on the ASB.
The portal, interfacing the ASB, was thus able to dynamically expose EF services, ASB services, and Grid services (through the ASB). 3.8
This aspect is widely described in the next section reporting the use case from Life Sciences. 4 4.1
We present in this section an example of bioinformatics application integrated in a portal based on EnginFrame and successfully tested and used in production mode by the Functional Genomics laboratory of the National Cancer Research Institute of Genoa.
The service developed, Survival Online (available at http://ada.dist.unige.it:8080/enginframe/bioinf/bioinf.xml), is a novel method to perform correlations between microarray gene expression data and clinic-pathological data through a combination of available and newly developed processing tools.
Microarray data analyses procedures are usually made of several steps ranging from preprocessing (background correction, normalization, summarization) to the statistical analysis of differential gene expression. This may involve different computer programs, ranging from specialized tools and statistical software environments to simple spreadsheets. It is therefore difficult for single researchers to analyze large datasets just using their local resources and, even if it is possible, it requires time, costs and skills.
The service becomes a good solution to the challenge of translating a complex manual procedure into an automated and consolidated Web-based process which can benefit from a back-end Grid infrastructure.
The automated procedure is shown in Figure 3. It represents the
workflow of the processing steps required by the analysis.
As first step, microarray data are preprocessed (using background
correction and normalization methods) and gene expression values
are obtained by running a parallel version of dChip [
The following processing steps further evaluate expression values
by means of several R/Bioconductor methods [
First, under/over-expressed genes are filtered so that only a
userdefined set of genes is retained. Then, specific phenodata are
associated to samples. Finally, a Cox regression analysis, possibly
combined with a multivariate analysis, is performed and the
Kaplan-Meier survival plot is computed [
An example of resulting Kaplan-Meier plot is shown in Figure 4. The application presented in the above subsection has been integrated in a Science Gateway based on EnginFrame. Thanks to EnginFrame, it has been possible to develop new portal services with very little effort.
EnginFrame services are made of an XML description, input parameters and the action to be executed. Normally, all the services exported by EnginFrame are described in a XML file called Services Definition File (SDF). For the sake of completeness and clearness, a fragment of SDF file for Survival analysis service is reported in Figure 5. contained in the ef:action (in this specific case EF_COMMAND="${EF_PLUGIN_PATH}/bin/ma_serv.sh") is submitted to the EnginFrame Agent which executes it on the backend resource tier. The input parameters of the service provided by the user in the HTML form fields are passed to the script as environment variables. Looking at the specific example in Figure 4, the option with id=“FILE” is rendered as a HTML file widget. When the user presses the “Submit job” button, the selected file is uploaded (via HTTP) from the user’s machine to the spooler area created for the submitted service and then a job is submitted to the back-end infrastructure (gLite, SRB, LSF, etc., depending on the plug-in used). The path of the transferred file is stored in the environment variable FILE. Layout and graphical aspects of the portal are kept separated from the services definition and involve XSL programming. EnginFrame system XSL provides libraries coping with the translation of XML into HTML and this makes the task of configuring the graphical layout straightforward. The whole development process is very rapid thanks to the possibility of re-using existing scripts and to the framework ability to dynamically catch any changes in services and layout avoiding in this way complex and tedious deployments iterations. A graphical overview of the developed service is given by the portal screen-shots shown in Figures 4 and 6.
Figure 6 represents the user interface for application parameters and data upload. The fragment shows the basic elements for the description of any service. The ef:option tags represent the input parameters for the service and are transformed to HTML form fields by the EnginFrame Server according to their type. When a user requests the service execution, pressing the “submit” button, the script The user is first enabled to select - remotely or locally - datasets or single samples thereof, as well as single genes or lists of genes. Expression values of selected genes are then correlated with sample annotation data by running mono- or multi-variate Cox regression, depending on user preferences.
Survival analyses results, together with the Kaplan Meier plot, are shown in the spooler area of the portal (see Figure 4). Execution status of the analysis (DONE) is visible as well.
The system was tested using publicly available breast cancer datasets and GO (Gene Ontology) derived gene lists or single genes for survival analyses. 5
In this paper we present a framework to integrate Grid resources and application tools according to the Science Gateway paradigm. The goal is to deliver customized graphical user interfaces for those applications which require many computational resources, so they need to be performed either on Grid infrastructures or on High-Performance Computing facilities.
Based on a service-oriented framework, EnginFrame provides a platform for many kinds of Science Gateways belonging to many domains A bioinformatics application for the analysis of Affymetrix GeneChip microarrays, successfully deployed at IST, National Cancer Research Institute of Genoa, has been presented as an example of EnginFrame usage and benefits.
As future work, special attention will be given to Web 2.0 technologies as a new way to enrich user interface and allow scientists to run their analysis through social web sites.
This work is developed within the Italian FIRB project ITALBIONET (“Rete italiana di bioinformatica”). We would like to thank Carla Milani from IBM Italian University Relation Office who made the competition of the University of Genoa in the 2008 edition of IBM SUR Grant possible, and prof. Enrico Giunchiglia, formal winner of the grant.
Thanks also go to Dott. Ulrich Pfeffer from National Cancer Research Institute, Genoa, for his support in experiment design and validation phases.
Finally we would like to acknowledge the support of the e-Science Institute in Edinburgh.