=Paper=
{{Paper
|id=Vol-513/paper-5
|storemode=property
|title=Rapid Development of Computational Science Portals
|pdfUrl=https://ceur-ws.org/Vol-513/paper05.pdf
|volume=Vol-513
|dblpUrl=https://dblp.org/rec/conf/iwsg/KoetsierH09
}}
==Rapid Development of Computational Science Portals==
IWPLS’09 Pages 1–8
Rapid development of computational science portals
Jos Koetsier and Jano I. van Hemert∗
University of Edinburgh, School of Informatics, Informatics Forum, 10 Crichton Street, Edinburgh
EH8 9AB, United Kingdom
September, 2009
Published in the IWPLS’09 International Workshop on Portals for Life Sciences
ABSTRACT of residing in a window. Depending on the portal technology used,
Motivation: Scientific web portals are seen as the way forward these web applications are referred to as ’portlets’, ’widgets’ or
to improve upon the slow uptake in use of utility computing sometimes ’gadgets’. We will use the term ’portlet’ throughout this
infrastructure and high-performance computing facilities (Wilkins- paper.
Diehr, 2007). Currently, two types of portals exist: general- Usually portal frameworks offer users the possibility to log in
purpose portals and domain-specific portals. The first type closely to a personalised environment using a username and password.
resembles the underlying technical infrastructure of compute-job When logged in, users can customise their own pages by selecting
submission systems, thereby providing little appeal to a wide range the layout and deciding which portlets to display and where. The
of domain specialists. The second type is tailored to the application more advanced portals can do this using user friendly menus and
specifications and their end-users’ requirements. Unfortunately, drag-and-drop.
the technical complexity in domain-specific portals makes these There are a number of standardisation efforts underway to enable
expensive and time-consuming to develop and maintain. Clearly, an portlets to be used in portals from different vendors, using the
alternative to these two approaches is required. principle of ’write once, deploy anywhere’. Currently there are the
Results: We introduce an approach, Rapid, that facilitates rapid JSR 168 (Abdelnur and Hepper, 2003) standard and its successor
development of portlets. Its main aim is to reduce the time from JSR 268 (Nicklous and Hepper, 2008), WSRP (OASIS, 2008) and
development to the deployment from several months to a few weeks. the OpenSocial (Google, 2009) standard. Several open and closed
Moreover, it facilitates an easy way to share and maintain these source products exist that implement these standards and which
portlets by domain specialist themselves. Both these advantages can use conforming portlets. Examples of such frameworks include
considerably reduce the cost of developing portal solutions for Liferay, GridSphere, JBoss and WebSphere.
computational science applications. We highlight several scientific The scientific community have long since recognised the
domains where our approach is used or was used successfully. advantages and potential of using portal technology in scientific
Availability: Rapid is developed under an Open Source model applications such as described in Wege (2002), especially as a
and is available freely through a Gnu General Public license. Main tool to improve upon the slow uptake in use of utility computing
releases, documentation, tutorials and examples are available at infrastructure and high-performance computing (HPC) facilities
research.nesc.ac.uk/rapid. The development of Rapid uses an open (Thomas et al., 2005). Instead of learning command-line methods to
read-only CVS repository, which is complemented by a developer upload and execute applications, users would have one web-based
community site at forge.nesc.ac.uk. point of access to the available computational resources. Users can
Contact: j.vanhemert@ed.ac.uk, jkoetsie@ed.ac.uk, select the applications that are of interest to them and use a graphical
user interface to execute a particular task, substantially lowering
the barrier to using the available computing resources and enhance
scientific research.
Unfortunately writing new scientific portlets is not an easy task.
1 INTRODUCTION They are usually written in Java or JavaScript and, for more
Recently, web portals have gained significantly in popularity. advanced portlets, require the use of several middleware packages.
Currently, the largest companies in the web search business deliver Once written, they need to be maintained as depending technologies
their content through portal technology, including Google with their may be updated or changed. An easy solution is to program a
iGoogle portal, Microsoft with MSN and Yahoo. Portal technology few portlets that are very general in their application and cover a
has also gained popularity in social networking sites such as wide range of possible end-uses. Unfortunately, this means they
LinkedIn and Myspace and other sites such as the BBC and many necessarily closely resemble the underlying technical infrastructure
more. of compute-job submission systems, thereby providing little appeal
A web portal is a framework that combines the output of several to a wide range of domain specialists.
independent web applications and arranges them in one or more In this paper we present a solution to this problem by introducing
customisable web pages. The output of each web application tends a novel methodology, ’Rapid’. Its main aim is to enable cost-
to be rendered surrounded by a border that gives it the appearance effective and rapid development of job submission portlets that are
tailored to enable domain specialists to accomplish their domain-
∗ to whom correspondence should be addressed specific task. In other words, users of job submission portlets
c University of Edinburgh 2009. 1
Jos Koetsier and Jano I. van Hemert1
created with Rapid should not need to understand any underlying Portal User Interface
technology. Its secondary aim is to make this method of delivering GridSphere / Liferay / Pluto / Exo / WebSphere / ...
scientific web portals simple enough to allow adoption by domain
Persistence
Rapid Portlet 1 Rapid Portlet 2 Rapid Portlet n
Security
experts with little background in ICT. This will enable communities Control Logic
to develop and maintain their web portals independently. Rapid's Computational Task Manager
In this paper we will refer to people involved in the study by GridSAM Sun Grid Engine Ssh fork Condor Portable Batch System
roles. Developers are those who are involved in the design and Computational Resources
HPC / Cluster / Grid / Cloud / Desktop / ...
development of the Rapid method. Domain-specialists, researchers
and teachers are the Portal Users, e.g. computational chemists, brain
imaging experts and biologists. These will work with the portlets
Fig. 2. The conceptual layers involved in Rapid portlets; Rapid portlets
created with Rapid. A Portal Designer uses Rapid to design, develop provide the link from the user interface, i.e. the portal, to the computational
and deploy portlets for Portal Users. When the Portal Designer resources, e.g. HPC, Cluster, Grid, Cloud or Desktop resources. It does so
in a project is also a domain-specialist we have accomplished our via communication with the resource managers, e.g., GridSAM, Sun Grid
secondary aim. Engine, Condor, Portable Batch System and direct forks over Ssh.
We demonstrate how Rapid is used to develop and deploy portlets
for computational science portals. We highlight a number of use
cases in several scientific domains where Rapid is used or was used
successfully to deliver a solution.
3 ARCHITECTURE OF RAPID
In Figure 2, we depict the typical design of computational science
portals. The top layer provides the actual user interface, which
is delivered via a JSR 168 compliant portal framework. Many
2 PORTAL DEVELOPMENT WITH RAPID frameworks are freely available, some with the possibility to
In Figure 1 we illustrate the processes of creating, deploying purchase commercial support, such as the JBoss portal, Liferay and
and using a domain-specific portlet using the Rapid system. It is Gridsphere. Commercial offerings include IBM’s WebSphere and
important for understanding the philosophy behind Rapid to show Oracle’s Portal server. Rapid generates portlets that live inside any
a typical way a portlet will be used by a Portal User. The focus of these frameworks.
of the methodology is to create portlets that facilitate customised The control logic layer orchestrates the actual business
computational tasks, where they are completely shielded from the logic of the portlet and consequently is responsible for data
infrastructure. It is up to the Portal Designer to decide how much management, configuring and submitting the computational job.
to shield the Portal Users from the underlying applications. For Usually, submitting a computational job entails copying data
instance, a Portal Designer may decide to expose a very limited and applications into the computational resource, initiating and
subset of an application’s feature to ensure inexperienced users can monitoring execution and copying results to a resource where they
perform a number of specified tasks. can be visualised as is specified in Foster et al. (2007).
The process of creating and using a Rapid portlet entails a number Security spans all layers as a user that authenticates in a portal
of steps. In the design phase the Portal Designer specifies (1) the eventually must also successfully authenticate with all the resources
user interface and logic of a task. This specification is created using required to perform a task. This means that credentials may have to
Extensible Markup Language (XML). The Portal Designer executes be taken from the interface layer all the way down to the resources
(2) the Rapid Translator, which reads (3) this specification, creates level. However, in some situations specific authentication may be
the portlet and generates a Java WAR file, which is then deployed required if portal credentials are not recognised by certain resources.
(4) into a portlet container. The generated portlet uses the JSR 168 Rapid allows for this by providing variables together with login and
standard, which ensures it can be deployed in a variety of different password input boxes that can be made available within portlets.
portal containers. However, as the packaging of the WAR file and Persistence too must span all layers as Portal Users will
the requirement of different deployment descriptors for each portal, undoubtedly expect their previous computational tasks, and more
separate packaging options are available to generate specific WAR importantly the results from these tasks, to be available next time
files. they login to their science portals. To do so, the persistence in
Once deployed, a Portal User can use a web browser to log Rapid keeps records of all that happens in portlets and is able
in to the portal and access (5) the new portlet. Using domain- to communicate directly with the resource layers to update these
specific jargon and graphical user-interface elements such as drop- records when computer jobs progress.
down menus, radio buttons and check boxes, (s)he configures and Using our method, the Portal Developer defines the user interface
then performs (6) the task at hand. This transfers control to the in an XML configuration file and the Portal user fills in the web
computational task manager embedded in the portlet, which runs forms resulting from this definition. The business logic takes the
(7) the appropriate compute jobs on available compute resources. contents of these forms as parameters and configures, submits and
The portlet allows monitoring (8) of the progress of all tasks monitors computational jobs. The final layer in our model consists
submitted so far, and when the compute jobs finish the results can of the file and compute resources that Rapid uses to perform its
be transferred (9) to an appropriate location and analysed (10) by tasks. An UML component diagram with these components is
embedding web-based visualisation components. shown in Figure 3
2
XML
interface,
task &
resource teacher
students
1 .creates description 5. performs task
web portal researcher
3. reads
portal
designer 2. uses 7. runs jobs
4. deploys
9. returns results
6. configure
8. monitor compute resources
10. analyse results
Fig. 1. The process of developing, deploying and using portals with Rapid. Two main roles are identified: the Portal Designer and the Portal User, shown here
as students, teachers and researchers
3
Jos Koetsier and Jano I. van Hemert2
Fig. 3. UML Component diagram of Rapid, which shows how specific components fit into the user interface, business logic and resources layers
3.1 User interface layer 3.2 Business logic layer
The user interface is specified in the Rapid XML file. Rapid Rapid’s business logic decides what to do with the values entered in
separates the mark-up of the user interface and the logic that the User Interface. As the main purpose of Rapid is job submission,
communicates with the underlying business logic. a very general model of a job submission is used. The model needs
The mark-up of the user interface is specified using tags from to be flexible enough to allow a wide range of possible scenarios,
the standard XHTML namespace. This gives a Portal Designer a but on the other hand specific enough to ensure creating a new job
wide range of options to design the user interface using familiar tags. submission portlet does not lose any simplicity,
For example, a Portal Designer with basic XHTML knowledge can To achieve both goals, Rapid’s job submission architecture is
easily create tables, use different fonts and incorporate images in the based around two Open Grid Forum standards: the Basic Execution
Rapid Portlet without the need to learn a new computer language. Engine (BES) (Foster et al., 2007) and Job Submission Description
Tags from the Rapid namespace are used to enter new values and Language (JDSL) (Anjomshoaa et al., 2005). These standards,
to communicate with the job submission engine. Parameters can which describe a general framework for submitting compute jobs,
be requested in different ways, such as text boxes, list structures were carefully designed based on years of experience with a variety
and radio buttons. Default values can be set in advance and are of different kinds of computational resources. This ensures our
retained during the session. As HTTP is a stateless protocol this model can cope with most computational scenarios and underlying
would normally have to be programmed explicitly by tying each computational infrastructures. Together these standards define a
variable into the session set up by the portal. Values entered can procedure of job submission that involves the following stages:
be checked whether they are valid by comparing them to a regular
expression. This ensures that users cannot, for example, enter text
where a number is expected. Stage In, a number of files are transferred into a computational
Using Rapid tags, the portlet can be subdivided into a set of resource that is expected to execute the compute jobs that
“pages”. This allows the Portal Designer to guide the user through belong to the task.
the process of submitting a task. Instead of displaying all available
Execute, the computational resource is executing the task.
information at once, a small amount of information can be requested
of the user at one time. When all required information has been Stage Out, the task has finished and the results of the task are
supplied, the user clicks on a button and navigates to a new page, transferred to another site.
which in turn can ask for more information, request confirmation or Error, this state is entered whenever an error has occurred in one of
display monitoring information. the previous states.
4
The Portal Developer specifies a job template in the Rapid XML
file along the lines of the JSDL specification. This includes the name
and location of the application itself and the file transfers before and
after the execution. The application itself is described as a POSIX
job such as used in most UNIX systems: the name of an executable,
a set of parameters and environment variables.
(a) Specifying the executable and parameters in Rapid. The second parameter
refers to a variable.
3.3 Resource layer
If so desired, the compute job can be performed on the same
computer the actual portal is running on, but in the majority of the
cases the compute job is to be offloaded to a dedicated resource. This
can either be a single computer accessed through SSH or a compute
cluster running a workload management system that distributes and
monitors the jobs.
Rapid has an internal engine that can access several high (b) Initialising a variable.
performance and high throughput cluster technologies. These
include Condor, Sun Grid Engine and the Portable Batch System
(PBS). All of these manage compute jobs on local clusters. The
computational task manager of Rapid communicates directly with
all these solutions, initiates the data transfers and polls the resources
to determine which state the execution is in. It is possible to define
several computational resources in the Rapid XML file and let the
Portal User choose between them.
On the other hand, GridSAM can be used to bypass most of
Rapid’s internal job manager. GridSAM is an implementation of the (c) Adding a drop-down box. The target is variable with name ’variable’. The
Basic Execution Engine and provides a Web Service interface that element belongs to the XHTML namespace.
consumes JSDL XML documents and performs data staging and
job submission to several Grid Computing infrastructures. When
Fig. 4. Examples of Rapid XML
submitting to a GridSAM web service, Rapid creates a JSDL
document and hands it to a GridSAM service, which will perform
the actual data staging, job submission and monitoring.
Transferring files to and from the computational resources can be
performed using standard protocols such as FTP, SFTP, HTTP and
the Grid based GSIFTP. If the computation takes place on the portal
itself, simple operating system level ’copy’ commands can be used.
3.4 Example
We present an abstract example of how a Portal Developer would
create a portlet. In the XML file we configure a job which simply Fig. 5. Simple example of Jython code, which enables inserting the current
date dynamically into a page
echos a string. In the job template we specify an executable
’/bin/echo’ with parameters ’hello’ and a reference to a value (See
Figure 4(a)). The variable this example refers to has to be initialised
and given a reasonable default value, which in this case will be set 3.5 Plug-in functionality through Jython
to ’world’ (See Figure 4(b)). The Rapid methodology gains most of its power by encapsulating
Finally, we allow the user to change the second parameters using common programming constructs and using XML tags to invoke
a drop down box, with choices ’World’, ’Rapid’ and ’Unknown’ them. Each XML tag represents a substantial amount of Java code,
(See Figure 4(c)). The framework ensures the right default value is which means that job submission portlets can be built very quickly.
presented to the user and that any changes the user makes, will be However this also results in a loss of flexibility: programming
retained throughout the configuration of the job. constructs that have not been implemented through XML tags
This example shows how we can mix the XHTML namespace cannot be used. This includes the use of looping mechanisms,
and the Rapid namespace to separate mark-up from Rapid’s logic. arithmetic and functions such as database access.
The first line is using the well known element to enlarge the Rather than anticipating and implementing every possible need
sentence ’Enter missing word’. and thereby implementing a complete new computing language,
5
Jos Koetsier and Jano I. van Hemert3
a plug-in framework was developed based on Jython (a Python
implementation in Java). Within a plugin, a Portal Developer can
query Rapid’s Job Submission and Monitoring component and read
and write to all variables. Of course the programmer can also use
many of the existing Python and Java libraries.
Plug-ins can manipulate the user interface, not only adding
output in the form of HTML but also by adding and removing
input elements such as text input boxes and radio buttons.
This feature allows run-time building of the user interface
enabling the user interface to look differently, depending on
certain conditions. An example of Jython is shown in Figure 5,
where the current date is inserted dynamically in the page.
To make use of this Jython code, the Portal Designer simply
inserts at
the appropriate location in the Rapid-XML.
4 USE CASES
Fig. 7. Screenshot of the visualisation part of the portal created by Rapid for
Rapid has been used to build scientific portals in several specialist perfusion imaging in stroke treatment
domains. We highlight five of these below where we give a
general description of the tasks these portals enable and provide
an approximation of the duration of the development period. Each
portal was created by one separate Portal Designer; the names of
purposes. Technological barriers prevented many researchers from
these and all people involved are in the acknowledgements.
using specific chemistry applications and produced large overheads
Chemists from the joint Chemistry Research School of the
in teaching these applications to students. To overcome these
Universities of Edinburgh and St. Andrews (EaStCHEM) have
barriers, the Rapid project showed EaStCHEM how to create
recently used Rapid to create portlets both for teaching and research
portlets with Rapid. This training led to a technology transfer,
where the most ICT adapt chemist was able to create several
portlets without the help of a software developer within a period
of two weeks. One of the portlets is now used to teach over 140
chemistry students. This user-friendly portlet, which is shown in
the bottom half of Figure 1 hides the complexity of the tutorial
(such as, command line options, authentication protocols and
job submission commands) from the student, so that they can
concentrate on learning both the conceptual use of the application
and the chemistry associated with it. A screencast is available at
research.nesc.ac.uk/node/396. Portlets do not just make applications
more user friendly. Future work with EaStCHEM will make more
resources available to the chemists, such as those supplied by the
National Grid Service. This will overcome difficulties in securing
time on the resources available within the universities and will
harness more computational power for the chemists.
In the context of biology, Rapid was used to create a
portal for microscopy. Here the goal was to improve the
usability of computationally-intensive image processing techniques.
These techniques were developed by the Swedlow Lab at the
University of Dundee under the Open Microscopy Environment
(openmicroscopy.org). Using Rapid, a portlet was developed that
integrates the analysis and visualisation techniques into one task
that is executed on their local cluster. In Figure 6, we show the step
where Portal Users can select which computational resources to use.
The development of this portal took three weeks.
Rapid is being used to design, build and deliver a portal to help
brain imaging experts perform tasks using imaging tools developed
by the SFC Brain Imaging Research Centre (www.sbirc.ed.ac.uk)
Fig. 6. Screenshot of the computational resource selection part of the portal at the University of Edinburgh. These tasks are concerned with
created by Rapid for image processing in microscopy CT and MRI brain scans in the context of stroke; they include
6
new computing infrastructure is rapidly being deployed, its broad
uptake is not following at the same pace (Simpson et al., 2008). The
main reasons for this lie in the complexity of the human interface
to these computing infrastructures and the predominant focus on
developing the underlying fabric (see for example Matsuoka et al.
(2008)) as opposed to user interfaces.
Most computational resources rely on a command-line interface
or an application programming interface as the primary route to
operation. As scientists from various disciplines are not always
familiar with such types of interfaces, the current approach is to
operate via a third person. This is a slow and expensive route, which
is often limited by the length of a specific research project.
Another approach, which has recently gained popularity, is to
offer access to computing infrastructures via portals (Novotny et al.,
2004). A portal is essentially a web-based application that acts
as a container for page fragments generated by a set of Java-
Fig. 8. Screenshot of a parameter setting part of the portal created by Rapid based components called portlets. Portals usually offer a rich
for running simulation in fire safety engineering set of features such as user management, security and a set of
personalisation features that allow a user to customise which portlets
to render and how to display them. Through the use of a portal, we
can offer a community of scientists easy, secure web-based access
volume registering, image registration, region of interest selection,
to underlying computing infrastructure.
quantification of perfusion and the visualisation of the results. A
We introduce an approach that allows rapid development and
screenshot of this portal is shown in Figure 7. It was created by an
deployment of portals for scientific computation. It uses a
e-Science MSc student again in a period of four weeks.
philosophy different from any other portal delivery system currently
Rapid is also being used in the FireGrid (firegrid.org) project
in existence. Whereas most portals are graphical representations
(Wickler et al., 2009) at the University of Edinburgh. It aims to
of the underlying job submission components, our system delivers
establish a cross-disciplinary collaborative community to pursue
portals that allow domain specialists to perform tasks in the context
fundamental research for developing real time emergency response
of their own domain. The benefits are: shorter development to
systems, using the Grid, beginning with fire emergencies. Rapid
deployment periods, easier maintenance and a unified approach to
was used to create a portal for running nonlinear finite element
application usage.
analysis using Abaqus, which took five weeks to develop and
deploy. Figure 8 shows the parameter setting step in the task plan.
The Rapid Portals for Seismological Waveform Data project
(research.nesc.ac.uk) aims to encourage the seismology community
to use an application that allows analyses of seismic waveform data. 6 CONCLUSIONS
This will be achieved by embedding the analysis application in a
We have introduced an approach that facilitates rapid development
community gateway, which already exists in the form of a web
of portlets, where the time to deployment can be reduced from
portal. The main barriers to uptake here are the installation and
several months to a few weeks. Moreover, as the whole portlet is
understanding of the analysis package, the difficulty in transporting
declared in one file, it is easy to share and maintain these portlets.
large amounts of data as input to an analysis, and direct visualisation
Both these advantages considerably reduce the cost of developing
of the results. Self-contained web portlets will be directly embedded
portal solutions for computational science applications.
in the community gateway and link to the data available in the
Our technological embodiment of our approach is Rapid, which
Orfeus Data Center (orfeus-eu.org)—the primary European centre
was used to create computational science portals in five different
for this kind of data. All the data and computing will be orchestrated
specialist domains. It has delivered portlets for all these portals
via Rapid, and the results presented to seismologists via their
without any conventional programming required.
existing web portal.
These portal allow scaling the uptake of software applications in
these communities much faster than when they would have to rely
on a small number of expert users to drive the software. In other
5 DISCUSSION words, making the applications easier to use by wrapping them in
Scientific computing is becoming a prevalent methodology in standard tasks is more cost-effective than training everyone to use
many disciplines (Getov, 2008). Today there is a wide range of the applications.
new scientific areas, including Bioinformatics, Systems Biology, By successfully transferring our technology to the domain
Computational Chemistry, Biomedical Imaging, Earth Systems specialists in computational chemistry we have enabled a second
Modelling, Computational Neuroscience, and Computational scaling effect. This community can now increase the number of
Physics. This has led to a surge in demand for computational tasks enabled through web portals by themselves. This frees up
infrastructure, which in turn has resulted in a growth in the Rapid team’s time to develop Rapid and apply it to other
computational resources, such as those offered through utility communities. We aim to make these technology transfers happen
computing and high performance computing facilities. Although in these communities too.
7
Jos Koetsier and Jano I. van Hemert4
ACKNOWLEDGEMENTS REFERENCES
Collaborators Abdelnur, A. and Hepper, S. (2003). JSR 168: Portlet specification. http://www.jcp.
org/en/jsr/detail?id=168.
We thank the following collaborators for their effort in successfully Anjomshoaa, A., Brisard, F., Drescher, M., Fellows, D., Ly, A., and McGough, S.
getting the use cases to work. Portal Designers are shown in italics. (2005). Job Submission Description Language (JSDL) Specification, Version 1.0.
Technical report, Global Grid Forum. http://www.ogf.org/documents/GFD.56.pdf.
Foster, I., Grimshaw, A., Lane, P., Lee, W., Morgan, M., Newhouse, S., Pickles, S.,
Chemistry: Andrew Turner, Patricia Richardson, Neil Robertson Pulsipher, D., Smith, C., and Theimer, M. (2007). OGSA Basic Execution Service
and Carol Morrison (University of Edinburgh); Sharon Version 1.0. https://forge.gridforum.org/sf/go/doc15062?nav=1.
Ashbrook (St. Andrews). Getov, V. (2008). e-science: The added value for modern discovery. Computer, 41(11),
30–31.
Brain Imaging: Albert Heyrovsky, Trevor Carpenter, David Rodrı́quez Google (2009). OpenSocial v0.9. http://www.opensocial.org/.
González, Joanna Wardlaw (University of Edinburgh). Matsuoka, S., Saga, K., and Aoyagi, M. (2008). Coupled-simulation e-science support
in the NAREGI grid. Computer, 41(11), 42–49.
Microscopy: Donald MacDonald and Jason Swedlow (University of Nicklous, M. and Hepper, S. (2008). JSR 286: Portlet specification 2.0. http://www.
Dundee). jcp.org/en/jsr/detail?id=286.
Novotny, J., Russell, M., and Wehrens, O. (2004). Gridsphere: a portal framework
FireGrid: Bruce Duncan and Asif Usmani (University of Edinburgh).
for building collaborations: Research articles. Concurrency and Compututation:
Seismology: Alessandro Spinuso and Torild van Eck (Observatories Practice & Experience, 16(5), 503–513. System available at http://www.gridsphere.
and Research Facilities for European Seismology); Andy org/.
OASIS (2008). Web services for remote portlets specification v2.0. http://docs.
Heath (University of Liverpool);
oasis-open.org/wsrp/v2/wsrp-2.0-spec.html.
Simpson, A. D., Bull, M., and Hill, J. (2008). Identification and categorisation of
applications and initial benchmarks suite. Technical report, EPCC, University of
Funding Edinburgh, UK.
Thomas, M. P., Burruss, J., Cinquini, L., Fox, G., Gannon, D., Gilbert, L., von
The development of Rapid was funded initially as a Commissioned Laszewski, G., Jackson, K., Middleton, D., Moore, R., Pierce, M., Plale, B.,
Software Project in the OMII-UK Centre and Managed Programme Rajasekar, A., Regno, R., Roberts, E., Schissel, D., Seth, A., and Schroeder, W.
(EPSRC, EP/D076617/1). Further development and deployment of (2005). Grid portal architectures for scientific applications. Journal of Physics:
Rapid was funded as an ENGAGE Project under the Engaging Conference Series, 16, 596–600.
research with e-Infrastructure project of the Joint Information Wege, C. (2002). Portal server technology. IEEE Internet Computing, 6(3), 73–77.
Systems Committee (JISC) and as a Rapid Innovation project under Wickler, G., Beckett, G., Han, L., Koo, S. H., Potter, S., Pringle, G., and Tate, A.
(2009). Using simulation for decision support: Lessons learned from FireGrid.
the JISC Information Environment Programme. It is also supported In J. Landgren, U. Nulden, and B. Van de Walle, editors, Proceedings of the
by a Research Platform Grant (EPSRC, EP/F057695/1) under the 6th International Conference on Information Systems for Crisis Response and
e-Science Core Programme. Management.
We acknowledge the sponsorship of The e-Science Institute Wilkins-Diehr, N. (2007). Special issue: Science gateways—common community
interfaces to grid resources: Editorials. Concurr. Comput. : Pract. Exper., 19(6),
and the Scottish Bioinformatics Forum to the 2009 International
743–749.
Workshop on Portals for Life Sciences.
8