1: % Template article for preprint document class `elsart'

2: % SP 2006/04/26

3: 

4: \documentclass{elsart}

5: \sloppy

6: \raggedbottom

7: % if you use PostScript figures in your article

8: % use the graphics package for simple commands

9: \usepackage{graphics}

10: % or use the graphicx package for more complicated commands

11: \usepackage{graphicx}

12: % or use the epsfig package if you prefer to use the old commands

13: \usepackage{epsfig}

14: %place all figures at the end

15: %\usepackage{endfloat}

16: 

17: % The amssymb package provides various useful mathematical symbols

18: \usepackage{amssymb}

19: \usepackage{paralist}

20: %\usepackage{natbib}

21: 

22: % The lineno packages adds line numbers. Start line numbering with

23: % \begin{linenumbers}, end it with \end{linenumbers}. Or switch it on

24: % for the whole article with \linenumbers.

25: % \usepackage{lineno}

26: 

27: % \linenumbers

28: \begin{document}

29: 

30: \begin{frontmatter}

31: 

32: % Title, authors and addresses

33: 

34: % use the thanksref command within \title, \author or \address for footnotes;

35: % use the corauthref command within \author for corresponding author footnotes;

36: % use the ead command for the email address,

37: % and the form \ead[url] for the home page:

38: % \title{Title\thanksref{label1}}

39: \title{The Application Hosting Environment: Lightweight Middleware for

40:   Grid-Based Computational Science}

41: % \thanks[label1]{}

42: % \author{Name\corauthref{cor1}\thanksref{label2}}

43: \author{P. V. Coveney, R. S. Saksena and S. J. Zasada}

44: % \ead{email address}

45: % \ead[url]{home page}

46: % \thanks[label2]{}

47: % \corauth[cor1]{}

48: % \address{Address\thanksref{label3}}

49: \address{Centre for Computational Science, Department of Chemistry,

50: University College London, 20 Gordon Street, London, WC1H 0AJ}

51: % \thanks[label3]{}

52: 

53: \author{M. McKeown and S. Pickles}

54: \address{Manchester Computing, Kilburn Building, The University of

55:   Manchester, Oxford Road, Manchester, M13 9PL}

56: 

57: %\title{}

58: 

59: % use optional labels to link authors explicitly to addresses:

60: % \author[label1,label2]{}

61: % \address[label1]{}

62: % \address[label2]{}

63: 

64: %\author{}

65: 

66: %\address{}

67: 

68: \begin{abstract}

69: % start of abstract

70: Grid computing is distributed computing performed transparently across

71: multiple administrative domains. Grid middleware, which is meant to

72: enable access to grid resources, is currently widely seen as being too

73: heavyweight and, in consequence, unwieldy for general scientific

74: use. Its heavyweight nature, especially on the client-side, has

75: severely restricted the uptake of grid technology by computational

76: scientists. In this paper, we describe the Application Hosting

77: Environment (AHE) which we have developed to address some of these

78: problems. The AHE is a lightweight, easily deployable environment

79: designed to allow the scientist to quickly and easily run legacy

80: applications on distributed grid resources. It provides a higher level

81: abstraction of a grid than is offered by existing grid middleware

82: schemes such as the Globus Toolkit. As a result the computational

83: scientist does not need to know the details of any particular

84: underlying grid middleware and is isolated from any changes to it on

85: the distributed resources. The functionality provided by the AHE is

86: `application-centric': applications are exposed as web services with a

87: well-defined standards-compliant interface. This allows the

88: computational scientist to start and manage application instances on a

89: grid in a transparent manner, thus greatly simplifying the user

90: experience.  We describe how a range of computational science codes

91: have been hosted within the AHE and how the design of the AHE allows

92: us to implement complex workflows for deployment on grid

93: infrastructure.

94: \end{abstract}

95: \begin{keyword}

96: grid computing \sep scientific workflows \sep middleware \sep service

97: oriented architecture \sep web services

98: % keywords here, in the form: keyword \sep keyword

99: 

100: % PACS codes here, in the form: \PACS code \sep code

101: \PACS 47.11.Mn \sep 87.57.Ra \sep 07.05.Tp \sep 89.20.Ff

102: %47.11.Mn computer assisted molecular dynamics

103: %87.57.Ra Computer-aided diagnosis

104: %07.05.Tp Computer modeling and simulation

105: %89.20.Ff Computer science and technology

106: \end{keyword}

107: \end{frontmatter}

108: 

109: % main text

110: \section{Introduction}

111: We define grid computing as distributed computing performed

112: transparently across multiple administrative domains

113: \cite{pvc2005_1,boghosian2005}.  By grid computing, we refer to any

114: activity involving digital information - computational processing,

115: visualisation, data collection from instruments and computational

116: analyses, database access, storage and retrieval \cite{pvc2005_1} -

117: performed by utilising computational, visualisation, network and

118: storage resources available on a grid. Grid computing has immense

119: potential for computational scientists.  A grid composed of resources

120: belonging to different institutions has the potential to provide a

121: level of service and support that cannot be expected from

122: intra-institutional resources or even an existing set of independent

123: resources which are not integrated into a grid as such. Some of the

124: benefits possible from using grid infrastructure include capacity for

125: increased workload volumes, faster response times/turn-around times

126: for the user, and increasing the frequency of running

127: analyses. Integration of resources into a grid infrastructure allows

128: for better consolidation and workload management and may result in

129: reduction of overall costs for grid resource owners. Grids can be used

130: to solve computational science problems that could not be solved by a

131: single resource either at all or efficiently, possibly due to compute,

132: memory, data or network limitations

133: \cite{chin2006_1,boghosian2006_1}. A grid provides a flexible and

134: dynamic infrastructure based on open standards which scales

135: efficiently as the number of component resources increases.  A general

136: computational grid should provide easy access to computational,

137: visualisation, storage, network and other resources, enabling

138: computational scientists to pick and choose those required to achieve

139: their widely varying scientific objectives.

140: \newline

141: \newline

142: Many emerging grids are in operation around the world, for example,

143: the UK National Grid Service (NGS) \cite{ngs}, US TeraGrid

144: \cite{teragrid}, Enabling Grids for E-sciencE (EGEE) \cite{egee} and

145: Distributed European Infrastructure For Supercomputing Applications

146: (DEISA) \cite{deisa} in the EU and the Japanese National Research Grid

147: Initiative (NAREGI) \cite{naregi}, which make capability for

148: computational processing, data storage and visualisation on high speed

149: networks available to computational scientists. The engagement of

150: scientists in grid activities is essential for such grids to mature

151: into genuine production-level infrastructure which can deliver the

152: much heralded potential of grid computing to the international

153: computational science community.

154: 

155: \section{Motivation for the Application Hosting Environment}

156: Grid architecture consists of various components including grid

157: middleware, application programming interfaces (APIs), software

158: development kits, protocols, services, system software and hardware

159: \cite{foster2001}. In our efforts over the past four years to utilise

160: grids to address new challenges in computational science and

161: engineering, we have experienced significant barriers, particularly

162: when dealing with heavyweight grid middleware

163: \cite{pvc2004_1}. Transparency, implying minimal complexity for

164: computational scientists using grid technology, has been missing from

165: existing distributed computing infrastructures that might aspire to

166: call themselves grids. In this paper, we present the approach we have

167: taken to address and overcome the heavyweight grid middleware problem.

168: \newline

169: \newline

170: Grid middleware is the software layer that transforms distributed,

171: heterogeneous resources spanning multiple administrative domains into

172: a single, integrated grid so that the heterogeneity and multiplicity

173: of the distributed resources is transparent to the user. The user

174: interacts with all the heterogeneous resources in the grid through a

175: uniform interface. Thus, middleware is a critical component of grid

176: infrastructure and its lack of usability has been a major barrier to

177: the uptake of grid technology. Many of the current grid middleware

178: solutions can be characterised as what we describe as `heavyweight',

179: that is they display some or all of the following features:

180: \begin{inparaenum}[(i)]

181: \item the grid middleware's client-side software, which is what the

182: users/computational scientists have to interact with on their

183: desktops, is difficult to install and configure,

184: \item has non-negligible dependencies on supporting software \item

185: requires non-standard ports to be opened within client-side firewalls

186: and

187: \item the server-side components of the grid middleware exhibit the

188: same heavyweight characteristics as the client-side software; in most

189: cases the situation is worse on the server-side\end{inparaenum}. As a

190: result, the user faces significant obstacles in deploying and using

191: many of the current grid middleware solutions. This has led to

192: reluctance amongst many scientists to actively embrace grid technology

193: \cite{pvc2004_1}.  It is important for the development of grid

194: computing as a whole that as many diverse groups of scientists as

195: possible begin to use grids; it is crucial that the uptake of grid

196: technologies occurs beyond specialized grid-centric projects

197: \cite{blake2005,jha2005_1,boghosian2006}. While some progress has been

198: made in the field of grid middleware technology \cite{globus,unicore},

199: the prospect of a heterogeneous, on-demand computational grid as

200: ubiquitous as the electrical power grid is still a long way off.

201: \newline

202: \newline

203: To address these deficiencies, there is now much attention focused on

204: `lightweight' middleware solutions

205: \cite{kewley2005,pvc2005_2,rixon2005,blower2005}, which attempt to

206: lower the barrier of entry for grid users. Our efforts to address

207: these deficiencies have been concentrated on the development of the

208: Application Hosting Environment (AHE), a lightweight WSRF \cite{wsrf}

209: compliant, web services based environment for hosting scientific

210: applications. The AHE alleviates many of the problems posed by

211: heavyweight grid middleware for computational scientists, who are

212: among those who stand to benefit the most from grid computing.  The

213: AHE allows scientists to quickly and easily run unmodified application

214: codes on grid resources, managing the transfer of files to and from

215: the grid resources and allowing the user to monitor the status of

216: application instances that are run on the grid. In the AHE, we adopt a

217: standards-based web services approach to expose scientific

218: applications on the grid as stateful web services.

219: \newline

220: \newline

221: From a computational scientist's perspective, a web service is simply

222: any computational application functionality that is accessible over a

223: network as a service, that can be invoked in multiple contexts,

224: possibly to form higher-level services. The description of the

225: services provided by the AHE is standards-compliant \cite{wsdl} so

226: that they can be invoked using any web services compliant client (see

227: Appendix \ref{s:arch} for more details). The AHE design is influenced

228: by our previous work on WEDS (WSRF-based Environment for Distributed

229: Simulation) \cite{pvc2005_2}, a hosting environment designed for

230: operation primarily within a single administrative domain. The AHE

231: differs from WEDS in that it is designed to operate seamlessly across

232: multiple administrative domains, in a true grid sense.

233: 

234: \section{Design of the Application Hosting Environment}

235: The AHE is an ensemble of programs written in Perl with Java-based

236: command-line and Graphical User Interface (GUI) client tools. The

237: purpose of the AHE is to provide a mechanism for deploying

238: applications onto computational grids that makes it easy for the

239: scientist to start and manage applications on the grid.  The AHE has a

240: client-server architecture in which as much of the complexity as

241: possible is moved to the AHE server. This makes the AHE client

242: thinner, with a reduced set of software dependencies, and easy to

243: install. Our approach works better than the conventional and

244: relatively inflexible portal approach as the AHE client is not

245: constrained to being a web browser. The AHE client has been

246: implemented as a desktop GUI application as well as an interoperating

247: set of command-line tools, making it highly flexible and powerful as a

248: tool for constructing lightweight workflows via scripting as described

249: in Section \ref{s:aheworkflows}. Furthermore, all state persistence

250: occurs on the AHE server, which substantially increases client

251: mobility.

252: \newline

253: \newline

254: To ensure that the AHE client is easy to install, configure and use,

255: whilst providing maximum functionality, a number of design constraints

256: were set on the overall design of the AHE:

257: \begin{enumerate}

258: \item We do not require the user to install Globus \cite{globus},

259: Unicore \cite{unicore} (or any other grid middleware) clients on

260: his/her machine even if the grid, that he wishes to run applications

261: on, uses such grid middleware.

262: \item We assume that the client device uses NAT (Network Address

263: Translation \cite{nat}) and that the device is firewalled to only

264: allow outgoing connections. This effectively means that the client

265: does not accept any inbound connections: all communication is

266: out-bound and initiated by the client.

267: \item For maximum portability, we require that the client only

268:  supports HTTP \cite{http}, HTTPS \cite{https} and SOAP \cite{soap}.

269: \item The client does not have to be installed on a single machine;

270: the user can move between clients on different machines and access the

271: applications that have been launched from any one of them. The user

272: can even employ a combination of different clients - for example, a

273: command line client to launch an application and a GUI client to

274: monitor it. The client therefore must maintain no information about an

275: application instance's state. All state information is maintained as a

276: central service on the AHE server that is queried by the AHE client.

277: \item The client machine needs to be able to upload input files to and

278: download output files from a grid resource, but we assume it does not

279: have GridFTP client software installed. A WebDAV-based intermediate

280: file staging area is therefore used to perform file-staging between

281: the client and the target grid resource.

282: \item The AHE client maintains no knowledge of the location of the

283: application on the target grid resource, or how it should be run, and

284: it maintains no information on specific environment variables that

285: need to be set.

286: \item The client should not be affected by changes to a remote grid

287: resource, for example if its underlying middleware changes to a newer

288: version of the Globus Toolkit \cite{globus,gt4}.

289: \item All communication is secured using Transport Layer Security

290: (TLS) \cite{tls} with the user's X.509 certificate \cite{x509} used

291: for encryption, authentication and authorization.

292: \end{enumerate}

293: These design constraints have led us to an architecture in which the

294: AHE client is extremely lightweight and simple to deploy, with no

295: dependencies except for the Java Runtime Environment \cite{jre}. It

296: should be noted that this design does not remove the need for

297: middleware solutions such as Globus or Unicore on the grid resource

298: (which may be, for example, a US TeraGrid site or a supercomputer on

299: the DEISA grid); indeed, we provide an interface to run applications

300: on multiple resources with different underlying grid middlewares, so

301: it is essential that the grid resource provides a supported middleware

302: installation on their machines. The AHE uses GridSAM \cite{gridsam}, a

303: job submission and monitoring software, as its interface to the grid

304: resources. GridSAM provides the AHE server with a uniform interface to

305: the different type of grid middleware installed on a grid. See Section

306: \ref{s:arch} and Figure \ref{F:arch-fig} for a brief discussion of

307: GridSAM's role in the AHE architecture. The AHE removes the

308: requirement to install any other middleware on the user's client

309: machine: the user simply needs to install the lightweight AHE client

310: to interact with the grid resources which may have heavyweight

311: middleware installed on them. The AHE client currently provides a

312: uniform interface to grid resources with installations of Globus

313: Toolkit 2.4.3 \cite{globus}, Grid 

314: Engine 6.0 u4+ \cite{sge}, Condor

315: v6.4, 6.6 and 6.7 \cite{condor} and Unicore \cite{unicore} while

316: work is in progress to enable interfacing to Globus Toolkit 4.0 \cite{gt4}

317: based grids. The recently developed Unicore support for AHE 

318: fulfils demand for the capability to launch applications on the EU DEISA

319: grid \cite{deisa} and brings

320: with it the much sought after interoperability between Unicore-based grids

321: and Globus-based grids.

322: \newline

323: \newline

324: In addition to the state information about all the application

325: instances, the AHE server also stores all the necessary information

326: about how an application should be run on the various computational

327: grid resources and provides a single, uniform interface to the AHE

328: client for running that application across all possible grid

329: resources. This is particularly useful for applications that run on

330: supercomputers which often have unique deployment scenarios and

331: require special runtime environments. Storing this

332: deployment/configuration information on the AHE server as a central

333: application-specific service is an efficient mechanism for making the

334: information available and useful to a large number of users at once.

335: \newline

336: \newline

337: The AHE design is based around the notion that very often a group of

338: researchers will want to run the same application, but not all of them

339: will possess the skill or inclination to install the application on a

340: remote set of grid resources. In the AHE, we therefore distinguish

341: between experts and end-users. An expert user installs the application

342: and configures the AHE server, so that all participating users can

343: share the same application on the grid at large.  The end-user simply

344: needs to download and install the lightweight AHE client and is then

345: able to trivially access such `centrally installed' applications.

346: \newline

347: \newline

348: The design of the AHE is novel in its application-centric approach,

349: according to which we treat the computational `application' as a

350: higher level entity than a computational `job'. Computational

351: steering applications \cite{fowler2005,pickles2005}, coupled model

352: simulations \cite{defabritiis2006,pvc2006_3} and workflows

353: \cite{pvc2006_1,pvc2006_2,fowler2006_2} are cases where applications

354: and jobs can be clearly distinguished. In the initial AHE release,

355: applications and jobs stand mainly in a one-to-one relationship except

356: for the case of workflow applications. Complex workflow applications

357: have been deployed on grids using the AHE wherein the workflows are

358: composed of simpler computational jobs. This is discussed in more

359: detail in Section \ref{s:aheworkflows}. By providing a service that

360: will launch a particular application rather than a generic

361: computational job it is possible to reduce the complexity of the

362: client and make the scientist's life easier. The scientist can then

363: concentrate on science rather than spending time understanding and

364: installing middleware and managing individual jobs.

365: 

366: \section{Application Hosting}

367: \label{s:hostingapps}

368: An application is said to be grid-enabled when it is able to run on

369: multiple heterogeneous resources comprising a grid. In the

370: computational science domain, the AHE provides a mechanism to expose

371: an unmodified application as a standards-compliant web

372: service. Appendix \ref{s:webservices} and \ref{s:arch} provide more

373: technical detail about how this is done.

374: \newline

375: \newline

376: When an application is launched on a grid resource using the AHE, that

377: instance of the application is referred to as the application

378: instance. In other words, the user can launch many application

379: instances for an application which is hosted in the AHE.  Any kind of

380: modelling and simulation application can be hosted within the AHE.  To

381: the best of our knowledge, all of the applications currently hosted in

382: the AHE are simulation codes as discussed in Section

383: \ref{s:hostingapps}. We therefore use the term simulation instead of

384: application instance in much of the following discussion of the AHE.

385: However, the same discussion is applicable, more generally, to

386: instances of any other type of application hosted in the AHE.

387: \newline

388: \newline

389: We currently host a number of scientific applications within the AHE

390: including the highly scalable molecular dynamics (MD) codes DL\_POLY

391: 3.01 \cite{smith1996}, NAMD \cite{kale1999}, LAMMPS

392: \cite{plimpton1995} and GROMACS \cite{gromacs} and the

393: lattice-Boltzmann (LB) code, LB3D

394: \cite{chin2006_1,harting2005,lb3d}. Scientists can use the AHE client

395: to launch these applications on a grid; in particular, we currently

396: use the AHE to run these applications on the UK NGS and US TeraGrid

397: resources.  The AHE does not require the application to be modified as

398: long as the application is reasonably well-behaved with respect to the

399: run parameter specification, file-naming and file-location

400: conventions.

401: \newline

402: \newline

403: We next describe, how to run such applications on a grid

404: using the AHE. Most of the steps involved are common to all

405: applications. Then we discuss some of the specific applications

406: currently hosted in the AHE. Lastly, we describe how the AHE client

407: and server can be configured to host a new application.

408: 

409: \subsection{Running hosted applications}

410: \label{s:runningapps}

411: The steps involved in running an application instance on a grid using

412: the AHE are listed below. We present the steps in terms of running

413: application instances of simulation type applications. The AHE GUI

414: client is implemented in the familiar `wizard' fashion; each step in

415: the launching process is presented to the user as a separate screen in

416: the GUI with controls to navigate between screens:

417: \begin{enumerate}

418: \item In the AHE client wizard, the user first specifies the

419: particular application that he wishes to run, e.g., DL\_POLY, and

420: other constraints such as the number of processors on which to run it,

421: maximum wall time required and so on. The AHE server returns a list of

422: grid resources on which the application is installed and that match

423: the constraints. The user then selects the grid resource on which he

424: wants to run the simulation.

425: \item Next, the AHE client wizard prompts the user to specify the

426: location of the input files and the names of the output files that

427: would be produced at the end of the simulation. In the most general

428: case, the user can manually specify the locations of input files and

429: the names of output files. However, the AHE client has a plug-in

430: parser feature, whereby application-specific plug-in parsers can be

431: integrated into the client automating the file management

432: operations. This is discussed in more detail in Sections

433: \ref{s:exampleapps} and \ref{s:newapps}

434: \item The user then uses the AHE client wizard to start the simulation

435: on the grid resource.

436: \item Once the simulation has started, the user can manually check the

437: simulation status or choose either to set the AHE client to poll the

438: status of the simulation or to shut-down the client and return at a

439: later time to retrieve the simulation status. The user can use any

440: machine with an AHE client installation, not necessarily the one from

441: which the simulation was started to monitor his/her simulations.  This

442: is ideal in situations where the user would like to access the

443: simulation state, including the input and output files, from different

444: machines.

445: \item Apart from monitoring the status of the simulation, users can

446: also terminate their simulation before normal completion using the AHE

447: client.

448: \item Finally, when the simulation has completed, the user can

449: transfer all the input and output files on the remote grid resource at

450: the click of a button. The task of recovering output files scattered

451: around a (global) grid has been very tedious until now and this

452: feature of the AHE has greatly enhanced the productivity of grid

453: users.

454: \item The user may then destroy all memory of the simulation on the

455: AHE server or can allow the simulation state to persist on the AHE

456: server to review it in the future. Note that a review may involve

457: retrieving the simulation input and output files at a later time.

458: \end{enumerate}

459: 

460: The combination of the capability to parse configuration files in

461: order to discover input and output files, to automatically stage the

462: files to and from the grid resources, and to review the state of the

463: simulation including associated files long after the simulation has

464: finished, makes the AHE an extremely powerful tool for addressing the

465: challenge of solving the provenance problem especially when one wishes

466: to run a large number of application instances distributed across a

467: grid.

468: 

469: \subsection{Example applications}

470: \label{s:exampleapps}

471: \textbf{DL\_POLY}\newline

472: DL\_POLY \cite{smith1996} is a parallel

473: molecular dynamics package for simulations of macromolecules,

474: polymers, ionic systems and solutions. We host DL\_POLY within the AHE

475: for users who wish to run molecular dynamics (MD) simulations with

476: DL\_POLY on the UK NGS core nodes and the HPCx facility \cite{hpcx}.

477: This makes it trivial to launch DL\_POLY simulations on these grid

478: resources using the AHE client wizard.

479: \newline

480: \newline

481: A DL\_POLY specific plug-in parser has been integrated into the AHE

482: client, so that the user simply needs to specify the location of the

483: CONFIG, file on his/her local machine and all the input files, such as

484: CONTROL, FIELD and/or TABLE, etc., automatically get staged to the

485: remote grid resource at the start of the simulation.

486: \newline

487: \newline

488: Once the simulation has terminated, the user can, at the click of a

489: button, retrieve all the input and output files from his/her DL\_POLY

490: simulations, for example, the OUTPUT, REVCON, REVIVE, STATIS files to

491: the local machine.

492: 

493: \textbf{NAMD and LAMMPS} \newline

494: We host NAMD and LAMMPS within the

495: AHE for users who wish to run MD simulation with these applications on

496: the UK NGS core nodes and US TeraGrid sites.  NAMD \cite{kale1999} is

497: a parallel molecular dynamics code primarily used for large-scale

498: bio-molecular simulations. LAMMPS \cite{plimpton1995} is a parallel

499: molecular dynamics code with optimizations for long-range

500: interactions.  It is trivial to launch NAMD and LAMMPS simulations

501: using the AHE client wizard by following the steps described

502: previously.

503: \newline

504: \newline

505: Plug-in parsers for NAMD and LAMMPS have already been integrated into

506: the AHE client and are supplied with the AHE client download. These

507: plugin-parsers allow the user to specify the location of the

508: NAMD/LAMMPS configuration file from which the AHE automatically

509: discovers and transfers all the input and output files that the

510: application instance will consume and produce.

511: \newline

512: \newline

513: For example, the NAMD/LAMMPS configuration file along with the

514: force-field paramete file, co-ordinate file, velocity file, and

515: restart files that may be required to run the simulation are

516: automatically staged to the grid resource at the start of the

517: simulation.  Since the simulation is run within a single working

518: directory on the remote grid resource, any relative paths in the

519: configuration files are removed. All input and output files that

520: belong to a particular simulation are located in a uniquely associated

521: working directory. Once the simulation has finished the user can

522: again, at the click of a button, retrieve all the output files from

523: his/her simulation working directory on the remote grid resource.

524: 

525: \textbf{GROMACS}\newline

526: GROMACS \cite{gromacs} is a highly optimized,

527: parallel molecular dynamics simulation package extensively used for

528: biomolecular simulations. We host GROMACS within the AHE for users who

529: wish to run MD simulations with GROMACS on the UK NGS core nodes. A

530: client parser plug-in makes it trivial to launch the application using

531: either the AHE GUI or command-line clients.

532: 

533: GROMACS differs from most of the other applications currently hosted

534: in the AHE in that it consists of two separate applications, namely a

535: preprocessor (grompp) and the actual simulation code (mdrun). A Perl

536: script has been created which runs on the grid resource and directs

537: the output of the preprocessor to the input of the simulation

538: code. This script is then hosted in the AHE and treated as a single

539: application. A client configuration parser has also been created which

540: takes its input from a `meta' configuration file, allowing the user to

541: specify parameters for both components of the application.

542: 

543: Once complete, the AHE client stages back both the output from the

544: simulation code and certain important intermediate files created by

545: the preprocessor.

546: 

547: \textbf{LB3D}\newline

548: LB3D \cite{lb3d} is a massively parallel

549: implementation of the lattice-Boltzmann model for amphiphilic fluid

550: dynamics \cite{chin2006_1,harting2005} which is able to reproduce the

551: morphological and rheological phenomena observed in ternary

552: amphiphilic mixtures from purely bottom-up mesoscopic interactions.

553: We have hosted LB3D within the AHE to run lattice-Boltzmann

554: simulations on the UK NGS and US TeraGrid nodes.  In this case, it was

555: necessary for us to modify the application, as some features of the

556: code were incompatible with the AHE design. LB3D produces output files

557: whose names contain a randomly generated string while relying also on

558: a pre-exisiting output directory at the start of the simulation. In

559: order to be easily hosted within the AHE, it is preferable to know in

560: advance the names of the output files that the code will generate

561: during the execution so as to automate the process of output file

562: retrieval. Moreover, in the AHE design, each independent execution of

563: an application is associated with a unique working directory on the

564: remote grid resource, within which the simulation is run and the

565: staging and de-staging of input and output files occurs. It is,

566: therefore, desirable for the application code to run within a single

567: working directory. In grid environments, where because of the

568: multiplicity of resources, one needs to keep track of output dispersed

569: across various remote grid resources, it is particularly useful to

570: have working directories associated with specific simulations.

571: 

572: \subsection{Hosting a new application}

573: \label{s:newapps}

574: To host an application within the AHE, the expert-user needs to

575: configure the AHE server with the following application-specific

576: information:

577: \begin{enumerate}

578: \item location of the application executable on the grid resources,

579: e.g., NGS nodes and TeraGrid sites.

580: \item any environment variables that may be required to run the

581: application on the different grid resources such as the path to

582: dynamically linked libraries

583: \end{enumerate}

584: The reader should consult the AHE server installation guide

585: \cite{aheserverguide} for the exact location where this information

586: needs to be stored. After configuring the AHE server with the above

587: information, running a short script provided with the server

588: distribution updates the registry of hosted applications to include

589: the new application.  There is no need to restart the AHE server once

590: a new application has been added in this manner.

591: \newline

592: \newline

593: Once the above changes have been made to the server-side, the user is

594: able to run the application using the AHE client in the generic mode,

595: i.e. the AHE client does not require any modification when a new

596: application is hosted. However, it is possible to write an

597: application-specific plug-in parser for the AHE client which can parse the user-specified

598: application configuration file to automatically discover the input and

599: output files for the particular application instance that the user

600: wishes to launch. The parsing capability allows the user to simply

601: specify the location of the configuration file; the AHE client then

602: automatically parses it to find out all the input file locations and

603: output file names. Thus, when the simulation is started the input

604: files are automatically staged to the remote grid resource and the

605: output files are retrieved at the end of the simulation. Details of

606: writing and integrating such a plug-in parser with the AHE client

607: are specified in the AHE client user guide \cite{aheclientguide}.

608: 

609: \section{Scientific Workflows}

610: \label{s:aheworkflows}

611: In addition to the GUI, the AHE client includes a closed set of atomic

612: command-line tools that replicate the essential operations in the AHE

613: GUI client. For example, there are AHE command-line tools to `prepare'

614: an application instance for running on a grid resource, to `start',

615: `monitor', `terminate' and `getoutput(files)'. Complex workflows

616: composed of multiple simulations and/or calculations can be realised

617: very simply by writing scripts that combine the command-line tool

618: functionality. Here, we present three examples of how the AHE

619: command-line tools can be combined to compose and deploy complex

620: workflows.

621: 

622: \subsection{Ensembles of simulations}

623: \label{s:ensembles}

624: \begin{figure} [!h]

625: 	\begin{center}

626: 	    \includegraphics[scale=0.3]{ensemble.eps}

627: 	\end{center}

628: \caption{Running ensembles of application instances on a grid using

629: the AHE. Application instances labelled as sim1, sim2,..., simN are

630: started on computational resources on the grid using the AHE. The AHE

631: manages input/output file-staging for each application instance

632: to/from the associated grid resource. The user is able to monitor the

633: status of all the application instances.}

634: \label{F:ensemble-fig}

635: \end{figure}

636: In the workflow depicted in Figure \ref{F:ensemble-fig}, the user

637: wishes to launch a large number of independent simulations on the grid

638: and retrieve the results for post-processing. There may be an

639: additional requirement for these simulations to run

640: concurrently. Despite their multiplicity, each simulation may be

641: computationally expensive. For high-end applications, the capabilities

642: needed can only be delivered by resources available on grids such as

643: the UK NGS and US TeraGrid.  Computational resources on the grid

644: provide a flexible, low cost alternative to intra-institutional

645: supercomputing resources for running such ensembles of simulations.

646: Provided sufficient computational resources are available on the grid,

647: deployment of the ensemble workflow via the AHE results in shorter

648: turn-around time and greatly enhanced control of provenance for the

649: simulation output data as compared to submitting each simulation

650: individually on a local computational resource.

651: \newline

652: \newline

653: The ensemble functionality is currently being employed to run an

654: ensemble of molecular dynamics simulations of the HIV-1 protease and

655: inhibitors \cite{pvc2006_1}, each with a different starting

656: configuration for the system, in order to obtain better

657: statistics. Within the ensemble of simulations, the initial conditions

658: are identical for the simulations except for the initial atomic

659: velocity distributions, sampled from a Maxwell-Boltzmann distribution

660: and randomised differently for the same system temperature.

661: \newline

662: \newline

663: Such ensembles of MD simulations are useful for thermodynamic

664: integration (TI) calculations where multiple MD simulations need to be

665: launched at different values of the dual topology parameter $\lambda$

666: or where multiple short trajectory simulations can be launched on a

667: grid to give insight into the thermodynamics of a single long

668: trajectory simulation \cite{shirts2001}. An alternative way to study

669: TI calculations via chained simulations is discussed in Section

670: \ref{s:chains}.

671: \newline

672: \newline

673: Thus the AHE provides a simple way to write scripts in order to start

674: simulations on multiple grid resources. The user needs only to specify

675: the configuration file for each simulation; the AHE automatically

676: discovers and stages input/output files to/from the remote grid

677: resource without the user having to install any complicated grid

678: middleware on his/her local machine. This feature is particularly

679: useful when there are a large number of simulations to be launched on

680: several resources which span multiple administrative domains.

681: \newline

682: \newline

683: The AHE server maintains a history of all the simulations that have

684: been launched by each user and allows for their monitoring and review

685: in the future. As noted previously, the user has the flexibility to

686: change between client machines while still having a reference to

687: his/her entire simulation history.

688: 

689: \subsection{Chained simulations}

690: \label{s:chains}

691: \begin{figure} [!h]

692:         \begin{center}

693:            \includegraphics[scale=0.5,width=\textwidth]{chain.eps}

694:         \end{center}

695: \caption{Running a chain of application instances on a grid using the

696: AHE.  Application instances labelled as sim1, sim2,...., simN are

697: started in sequence on computational resources on the grid using the

698: AHE. The AHE manages input/output file-staging to/from the associated

699: grid resources; piping the output from one application instance as

700: input for the next application instance in the chain. The user is able

701: to monitor the status of each application instance as the workflow

702: progresses.}

703: \label{F:chain-fig}

704: \end{figure}

705: In the workflow in Figure \ref{F:chain-fig}, the user wishes to launch

706: a sequence of chained simulations where one application instance

707: begins execution after the previous instance has finished and may

708: depend on output from the previous instance's execution.

709: \newline

710: \newline

711: Such a workflow of chained simulations is currently being used by

712: numerous AHE users. In particular, the chained simulation capability

713: is being used to study binding affinities of wild-type and

714: mutant HIV-1 proteases with drug inhibitors \cite{pvc2006_2}. In order

715: to obtain a starting structure for the MD production runs, the initial

716: artificially mutated HIV-1 protease wildtype crystal structure is

717: equilibrated by subjecting it to a chain of equilibration simulations,

718: each simulation corresponding to a step in the equilibration

719: procedure. This is illustrated in Figure \ref{F:chainmd-fig}.

720: \begin{figure} [!h]

721:         \begin{center}

722:            \includegraphics[scale=0.5,width=\textwidth]{equili.eps}

723:         \end{center}

724: \caption{Running a chain of MD simulations on a grid; each simulation

725: 		corresponds to a different step in the initial

726: 		relaxation of the system to equilibrium before

727: 		production runs can be performed.}

728: \label{F:chainmd-fig}

729: \end{figure}

730: The AHE is used to automate the entire process of launching and

731: managing the equilibration simulations in sequence on the grid, thus

732: realising the workflow in Figure \ref{F:chainmd-fig}.  The automation

733: provided by AHE includes starting each simulation on different grid

734: resources in sequence, transferring input files to the grid resource

735: at the start and retrieval of output files at the end of each

736: simulation. This feature is particularly valuable as it frees the user

737: from the mundane task of keeping track of all the simulation data

738: files and manually transferring them across the grid resources for the

739: next simulation in the chain.

740: \begin{figure} [!h]

741:         \begin{center}

742:            \includegraphics[scale=0.5,width=\textwidth]{thermodynamicintegration.eps}

743:         \end{center}

744: \caption{Thermodynamic integration calculation consisting of a chain

745: 	of simulations at different values of parameter $\lambda$ is

746: 	an ideal candidate for grid deployment.  See text in Fowler

747: 	\emph{et al.} \cite{fowler2005} for more details.}

748: \label{F:ti-fig}

749: \end{figure}

750: Thermodynamic integration (TI) calculations

751: \cite{fowler2005,fowler2006_2}, where each simulation is run at a

752: particular value of the dual topology parameter $\lambda$ ($0 \leq

753: \lambda \leq 1$), such that the initial configuration for a simulation

754: at $\lambda_n+1$ is obtained from a simulation at $\lambda_n$, is

755: another example of a workflow of chained simulations that can be

756: deployed via the AHE. This is illustrated in Figure \ref{F:ti-fig}. As

757: noted in Section \ref{s:ensembles}, TI-type calculations can also be

758: studied using an ensemble workflow. Additionally, one can imagine a

759: chained workflow as in Figure \ref{F:chain-fig} comprising of

760: application instances belonging to different application types.

761: 

762: \subsection{Concurrent simulations}

763: \begin{figure} [!h]

764:         \begin{center}

765:            \includegraphics[scale=0.4]{coupled.eps}

766:         \end{center}

767: \caption{Running coupled application instances on a grid using the

768: AHE. Each application instance is executed on a separate grid resource

769: via the AHE. The AHE can monitor the individual components as they

770: execute.}

771: \label{F:coupled-fig}

772: \end{figure}

773: In the workflow in Figure \ref{F:coupled-fig}, the user wishes to

774: launch concurrent and dependent simulations on multiple grid

775: resources. The simulations may need to communicate with each other

776: periodically during their execution. This type of workflow can be used

777: to perform coupled model simulations \cite{pvc2006_3} where the system

778: being simulated spans multiple time-scales and/or length-scales. In

779: order to accurately and efficiently simulate such systems, the

780: different domains of the system are simulated at different levels of

781: detail using distinct applications which communicate at regular

782: intervals.  See De Fabritiis \emph{et al.} \cite{defabritiis2006} for

783: a description of such a multiscale computational technique that has

784: successfully coupled molecular dynamics with Landau's fluctuating

785: hydrodynamics to simulate sound waves propagating in bulk water and

786: reflected by a lipid monolayer.  Although such coupled models have not

787: been deployed with the AHE yet, the AHE provides the infrastructure to

788: start up the different applications on the grid, and once

789: communication has been established and concurrent execution has begun,

790: the AHE will enable the user to monitor individual applications and/or

791: to terminate them, while at the same time furnishing a high-level

792: overview of the entire coupled model application.

793: \newline

794: \newline

795: At the time of writing, there is a significant AHE user base with

796: others planning to use it. Favourable experiences have been reported

797: for NAMD and LAMMPS applications hosted within the AHE as compared to

798: alternative strategies \cite{globus,pvc2005_2,pickles2005} for running

799: jobs on grids \cite{pvc2006_1}. As expected, from the design criteria,

800: the key benefits for users have been:

801: \begin{compactenum}[(i)]

802: \item minimal installation, configuration and maintenance effort on

803: the client-side;

804: \item flexibility of restarting or switching between clients so that

805: the client need not be `attached' to the grid in order to launch or

806: manage jobs;

807: \item automatic staging in of input files to a grid resource, third

808: party file transfer between resources, and retrieval of distributed

809: files to the local machine on job completion;

810: \item no need to repeatedly submit individual jobs to many resources

811: and monitor status across multiple grid resources.

812: \end{compactenum}

813: Users have expressed the need for the capability to monitor queues on

814: different grid resources. This capability can be provided by the AHE

815: in future if the queue status

816: information is published via a web service by the resource managers

817: installed on the grid resources.

818: 

819: \section{Future Developments}

820: Future extensions of the AHE aim to add functionality that enables

821: even more ambitious computational science projects to be undertaken on

822: grids with ease. Globus Toolkit 4 (GT4) \cite{gt4} and Unicore \cite{unicore} 

823: are able to process jobs specified using the JSDL

824: schema and we are exploring the possibility of future versions of AHE

825: being able to

826: directly submit jobs to Globus Toolkit 4 (GT4) and Unicore

827: without the need for GridSAM (see Appendix \ref{s:arch}) as a

828: third party tool to provide 

829: the web service interface for job submission. Work is underway to integrate

830: the WSRF-compliant RealityGrid steering framework into the AHE

831: \cite{pickles2005}, which will provide support for starting and

832: managing steerable applications and coupled model applications hosted

833: in the AHE. We plan to extend the current workflow functionality to

834: orchestrate even more complex workflows, using the

835: industry-standard BPEL language \cite{bpel}. The scientist will 

836: be provided with graphical tools to interface with the BPEL 

837: workflow engine and easily implement their desired BPEL workflow 

838: operations.

839: \newline

840: \newline

841: We are now looking at new platforms on which the lightweight AHE

842: client can be deployed. For example, work is underway on an AHE client

843: that runs on mobile phones and PDAs \cite{kalawsky2005} allowing

844: scientists to launch and monitor simulations on the move. Co-allocation

845: is one of the major challenges faced by computational scientists

846: trying to perform cross-site runs using multiple concurrently

847: available grid resources \cite{boghosian2006}. No automated advanced

848: reservation and co-scheduling systems are in place yet within

849: so-called production grids; performing cross-site runs

850: \cite{boghosian2006} today requires human intervention for booking

851: resources in advance and making sure these are indeed available at the

852: desired time\footnote{Note that the beta version of the NAREGI

853: \cite{naregi} software stack has a super-scheduler at the heart of its

854: architecture \cite{naregi2} and claims to implemenent WS-Agreement

855: \cite{wsagreement} compliant co-allocation.}.  A fault-tolerant web

856: services compliant approach to co-allocation called HARC

857: \cite{maclaren2006} has recently been proposed and implemented. The

858: attractiveness of this scheduler stems from its ability to co-allocate

859: \begin{inparaenum}[(i)] \item compute resources and \item lambda

860: networks \cite{smarr2006}, which are dynamically provisioned optical

861: networks for bandwidth intensive applications\end{inparaenum}. An

862: interface to the HARC system will be developed in the AHE client to

863: provide support for automated, fault-tolerant co-allocation. We hope

864: to provide support for MPICH-G2 \cite{mpichg2} enabled applications in

865: the future.  Finally, we are also looking into the use of the AHE for

866: accessing campus-based resources, often referred to as `campus

867: grids'. Ultimately, AHE could become a uniform interface to all

868: computational resources.

869: 

870: \section{Conclusions}

871: Our goal in this work has been and continues to be to provide

872: scientists with tools such as command-line interfaces that are simple

873: and familiar, while at the same time furnishing access to a much more

874: powerful set of resources on grids than previously available, allowing

875: scientists to use their own creativity to achieve increasingly complex

876: computational objectives. The AHE allows computational scientists to

877: overcome the barrier of heavyweight, difficult-to-use grid middleware

878: and thereby to take advantage of grid computing with much greater ease

879: than has been possible hitherto. Grid computing has contributed

880: significantly to the scientific programme within isolated,

881: grid-centric computational science projects

882: \cite{chin2006_1,blake2005,jha2005_1,chin2004,jha2006_1} but it still

883: remains under-utilised among wider national and international

884: computational science communities. The involvement of increasing

885: numbers of computational scientists in grid activities is essential

886: for determining best practices in grid scheduling policies,

887: provisioning/orchestration policies and resource configuration. We

888: hope that the AHE will help to realise these goals.

889: 

890: \section{Distribution and Installation}

891: The first release of the AHE was made available on 31 March 2006. The

892: AHE (Version 1.0.1) client and server software can be downloaded from

893: the RealityGrid website at http://www.realitygrid.org/AHE or the

894: NeSCForge website at http://forge.nesc.ac.uk/projects/ahe. Future

895: releases will continue to be available from the RealityGrid

896: website. Documentation, including installation and configuration of

897: the AHE to run applications on the UK NGS and US TeraGrid, is also

898: available from these websites. Subscription to the AHE mailing list is

899: open at

900: http://www.mailinglists.ucl.ac.uk/mailman/listinfo/ahe-discuss.

901: \newline

902: \newline

903: A version of the AHE software, Version 1.0.2, has also been 

904: developed in which the AHE

905: server can be hosted within the Apache Jakarta Tomcat container

906: \cite{tomcat}. This version of the AHE is distributed via the Open

907: Middleware Infrastructure Institute UK (OMII-UK) \cite{omii}

908: within the latest OMII 3.2.0 server and client software 

909: which was released on 12 November 2006. This 

910: version of the AHE conforms to the OMII Integration

911: Specification and is easily installable and integrated with the rest

912: of the OMII distribution including WSRF::Lite \cite{wsrflite} and

913: GridSAM \cite{gridsam} which are pre-requisites for the AHE. OMII 3.2.0

914: server and client software is available for download at http://www.omii.ac.uk.

915: 

916: \section{Acknowledgements}

917: We are grateful to many current AHE users for suggestions and comments

918: which have improved its usability. We thank Dr. Phil Fowler, Kashif

919: Sadiq, Mary-Ann Thyveetil and Dr. James Suter for providing scientific

920: use cases during the initial development of the AHE.  In particular,

921: we acknowledge Kashif Sadiq for providing use cases for the ensemble

922: and chained simulation workflow functionality of the AHE. We would

923: like to thank Dr. Dorothy Duffy and Alex Rutherford for providing

924: expertise and use cases for hosting DL\_POLY in the AHE.  The AHE is

925: funded by EPSRC through the RealityGrid (GR/R67699), RealityGrid

926: Platform Grant (EP/C536452/1) and Rapid Prototyping of Usable Grid

927: Middleware (GR/T27488/01) projects, and through the OMII Managed

928: Programme project Robust Application Hosting using WSRF::Lite

929: (http://www.omii.ac.uk/mp/mp\_wsrf\_lite.jsp).

930: % The Appendices part is started with the command \appendix;

931: % appendix sections are then done as normal sections

932: % \appendix

933: % \section{}

934: % \label{}

935: \appendix

936: \section{Web Services and the Application Hosting Environment}

937: \label{s:webservices}

938: In the AHE, we have adopted the Service Oriented Architecture (SOA)

939: approach to providing applications as services on the grid. Web

940: services are one way of realizing SOA. As mentioned in the main text,

941: from a computational scientist's perspective a web service is simply

942: any computational functionality accessible over a network as a

943: service. The term `service' implies that the user simply needs to know

944: the description of the service in order to invoke it and does not need

945: to know how the functionality of the service is actually implemented;

946: this is particularly important on a heterogeneous grid. Hence, in

947: order for the web service to be consumed by a client, it is of utmost

948: importance that the web services have standards-compliant

949: interfaces. In the AHE, we use WSRF::Lite \cite{wsrflite}, a perl

950: library that provides the framework for writing web services.  In this

951: Service Oriented Architecture (SOA) approach, the key concept is that

952: of loosely coupled components, i.e., web services, that interact via

953: SOAP messages and whose interface is described by documents conforming

954: to the WSDL standard \cite{wsdl}.

955: 

956: There are obvious benefits to the adoption of a standards-based,

957: dynamic and flexible approach to running applications on heterogeneous

958: grid resources and managing the state of the application instances in

959: a uniform, integrated way. Such an approach allows flexible

960: integration of multiple applications to accomplish complex

961: computational tasks on the grid, as we aspire to do with the AHE's

962: workflow functionality. Also, the widespread adoption of the web

963: services approach in industry and academia permits grid computing

964: practitioners to take advantage of numerous existing web services and

965: web services development tools that are independently being made

966: available to the community and to take advantage of the significant

967: standardization and inter-operability efforts which clearly also

968: address significant issues in grid computing.

969: 

970: In the AHE, an application instance is represented as a transient

971: stateful web service Resource WS-Resource \cite{wsrf}. The WS-Resource

972: properties associated with the application instance include

973: \begin{itemize}

974: \item the application instance's reference handle or the EndPoint

975: Reference(EPR)

976: \item status of the application instance

977: \item a trivial name to refer to the simulation

978: \item date and time when the application instance was started,

979: \item the grid resource on which its running,

980: \item names and URLs of the input files

981: \item names and URLs of the output files.

982: \end{itemize}

983: Each time an application is run on the grid, a WS-Resource \cite{wsrf}

984: is created on the AHE server-side, and is used to represent that

985: instance of the application's execution. This WS-Resource provides an

986: interface for the user to interact with the application instance.  The

987: WS-Resource corresponding to the application instance and its

988: WS-Resource properties are stored on the AHE server in a database

989: referred to as the `App Instance Registry'.  This is described in more

990: detail in Appendix \ref{s:arch}. The WS-Resource properties can be

991: queried at any time using the AHE client or any other web services

992: compliant client. In this way the AHE provides a uniform interface for

993: managing simulations of various scientific application codes deployed

994: on multiple grid resources.

995: 

996: The WS-Resource persists even after the application instance has

997: finished executing, providing information on the location of any

998: output files as well as the input files and configuration parameters

999: used to initially run the application. This is a powerful provenance

1000: capability of the AHE, as the user can return at a later time and

1001: review the simulation by querying the properties of the associated

1002: WS-Resource.

1003: 

1004: \section{AHE Architecture}

1005: \label{s:arch}

1006: \begin{figure} [!h]

1007:         \begin{center}

1008:            \includegraphics[scale=0.5,width=\textwidth]{arch.eps}

1009:         \end{center}

1010: \caption{Architecture of the Application Hosting Environment; the

1011: 	 numbers denote operations performed between the AHE client,

1012: 	 AHE server, File Staging Service, File Store, MyProxy server

1013: 	 and Grid Resources. See the text in Appendix \ref{s:arch} for

1014: 	 a detailed description of this diagram.}

1015: \label{F:arch-fig}

1016: \end{figure}

1017: \textbf{WSRF::Lite}

1018: \newline The AHE is developed with WSRF::Lite, a

1019: Perl implementation of the Web Service Resource Framework (WSRF

1020: \cite{wsrf,wsrfglobus}) specification which has been ratified by the

1021: OASIS \cite{oasis} standards body. WSRF::Lite is the follow-on from

1022: OGSI::Lite, the Perl implementation of the Open Grid Service

1023: Infrastructure (OGSI \cite{tuecke2003}) specification from GGF

1024: \cite{ggf}.  It is built on SOAP::Lite \cite{soaplite} the Perl module

1025: for web services from which it derives its name.

1026: 

1027: In the current release of the AHE, we host the WS-Resources on the

1028: server-side within the Apache web server and store the WS-Resource

1029: properties in a PostgreSQL \cite{postgresql} database.  The PostgreSQL

1030: \cite{postgresql} database storing the simulation's state can be

1031: replicated and backed up non-locally to provide fault tolerance.

1032: 

1033: \textbf{GridSAM} \newline

1034: The AHE currently accesses computational

1035: resources on the grids via middleware called GridSAM

1036: \cite{gridsam}. GridSAM provides a web services interface, running in

1037: an OMII \cite{omii} web services container, for submitting and

1038: monitoring jobs on grid resources with various Distributed Resource

1039: Managers (DRMs) - Globus 2.4.3 \cite{globus}, Grid Engine 6.0

1040: u4+ \cite{sge} and Condor v6.4, v6.6 and v6.7 \cite{condor} - via its DRM

1041: connector-based plugin-in architecture. GridSAM has a plug-in

1042: architecture that allows connectors for different types of DRMs to be

1043: integrated into it, thereby adding the functionality to submit and

1044: monitor jobs on resources with those DRMs.

1045: 

1046: 

1047: Computational jobs submitted to GridSAM are described using another

1048: emerging standard, the Job Submission Description Language. GridSAM

1049: consumes Job Submission Description Language (JSDL \cite{jsdl})

1050: documents and performs the task of `job' submission to the target grid

1051: resource.

1052: 

1053: 

1054: \textbf{File Staging Area (FSA)} \newline

1055: The `File Staging Area'

1056: (FSA) is designed to allow the client to use the WebDAV \cite{webdav}

1057: file transfer protocol to `GET' (step 13 in Figure \ref{F:arch-fig})

1058: or `PUT' (step 4 in Figure \ref{F:arch-fig}) a file on the WebDAV

1059: server so that it can be downloaded by GridSAM on to the target grid

1060: resource (step 10/12 in Figure \ref{F:arch-fig}).  This is designed to

1061: handle the case where input files exist on the user's client machine

1062: and these need to be transferred to the grid resource. Similarly, the

1063: FSA is useful when files need to be retrieved from the remote grid

1064: resource to the local client machine. The FSA provides an intermediate

1065: file-staging area, albeit one which is accessible via normal HTTP GET

1066: and PUT mechanisms and is useful for pulling down the simulation

1067: input/output files from anywhere on the grid using nothing more than a

1068: web browser or potentially a PDA. We consider this type of file

1069: transfer as `pass by value' since the client actually transports the

1070: file to the FSA.

1071: 

1072: 

1073: \textbf{FileStore} \newline

1074: For much larger input/output files, which

1075: the user may not wish to download to his/her local machine, the AHE

1076: supports third-party file transfer using a `FileStore' mechanism. The

1077: FileStore is any place on the grid where files required by the

1078: instance of the application are available through GridFTP or HTTP. The

1079: FileStore is used to hold large files like checkpoints that would not

1080: normally be stored on the client machine. The AHE client passes the

1081: URL \cite{url} of the source input file or target output file to the

1082: AHE server and the input files automatically get staged from the

1083: FileStore to the grid resource on which the simulation is to be run or

1084: the output files from the grid resource automatically get staged out

1085: to the desired target FileStore. These are steps 10 and 12 in Figure

1086: \ref{F:arch-fig}. We call this `pass by reference' Note that FileStore

1087: may be a grid resource providing a storage service such as the data

1088: nodes on the UK NGS.

1089: 

1090: 

1091: \textbf{MyProxy} \newline

1092: Security is critical in any grid computing

1093: environment \cite{pvc2005_1}.  We chose not to use WS-Security

1094: \cite{mls,mls2} for the AHE because message level security is not

1095: required: we do not have any intermediaries for relaying SOAP

1096: messages. In the AHE, communication is via HTTPS to provide Transport

1097: Layer Security (TLS \cite{tls}); mutual authentication is used between

1098: the AHE client and the AHE server using X.509 digital certificates

1099: \cite{x509}. For users of the UK NGS \cite{ngs}, digital certificates

1100: or e-Science certificates can be obtained from the national

1101: certification authority \cite{ukca}. Within the AHE, the App

1102: WS-Resource is given access to a proxy certificate \cite{x509} stored

1103: on a MyProxy \cite{myproxy} server. The AHE server implements

1104: fine-grained authorization in that only the owner of the simulation

1105: has access to its properties.  This can be extended to provide group

1106: access or open access analogous to the UNIX file system permissions

1107: for collaborative work.

1108: 

1109: 

1110: \textbf{App Server Registry} \newline

1111: The `App Server Registry'

1112: maintains a registry of all the applications that are hosted within

1113: the AHE, such as, DL\_POLY \cite{smith1996}, NAMD \cite{kale1999},

1114: LAMMPS \cite{plimpton1995}, GROMACS \cite{gromacs} and LB3D

1115: \cite{chin2006_1,harting2005,lb3d}. The user can query the registry

1116: (step 1 in Figure \ref{F:arch-fig}) to find the address for the

1117: service factory that provides a particular application.

1118: 

1119: 

1120: \textbf{App Server Factory} \newline

1121: The `App Server Factory' is a web

1122: service based on the Factory Pattern \cite{factorypattern} which

1123: creates a new App WS-Resource on the AHE server each time the user

1124: invokes the Prepare operation.

1125: 

1126: 

1127: \textbf{App WS-Resource} \newline

1128: The `App WS-Resource' exists on the

1129: AHE server and is a WS-Resource representing a particular application

1130: instance. The user invokes the Prepare operation of the App Server

1131: Factory whenever an application instance needs to be launched on the

1132: grid. For each invocation of the Prepare operation, a new App

1133: WS-Resource is created on the AHE server and its WS-Resource

1134: properties are initialized as per the application instance parameters

1135: specified by the user.

1136: 

1137: 

1138: \textbf{App Instance Registry} \newline

1139: The AHE server maintains an

1140: `App Instance Registry' which contains the history of all application

1141: instances/WS-Resources that the user has launched/created. The App

1142: Instance Registry is implemented by a PostgreSQL \cite{postgresql}

1143: database. The user can query the App Instance Registry to get a list

1144: of all the application instances launched and the associated

1145: WS-Resource properties. Collaborative analysis of simulation histories

1146: is greatly aided by the stored WS-Resource properties that can be

1147: accessed online via the App Instance Registry.

1148: 

1149: We now briefly describe the numbered operations in Figure \ref{F:arch-fig}:

1150: \begin{enumerate}

1151: \item User retrieves a list of applications hosted within the AHE from

1152: the App Server Registry.

1153: 

1154: \item User invokes the Prepare operation in step 2 on the App Server

1155: Factory.

1156: 

1157: \item As a result of the invocation of the Prepare operation, the App

1158: Server Factory creates a new App WS-Resource representing the instance

1159: of the application. The App Server Factory returns a WS-Addressing

1160: \cite{wsaddressing} EndPoint Reference (EPR) to the client which the

1161: client uses to communicate with the App WS-Resource.

1162: 

1163: \item The AHE client automatically transfers the user's input files to

1164: the File Staging Area.

1165: 

1166: \item The user uploads his/her proxy credential to the MyProxy

1167: server. This is then valid for one week by default.

1168: 

1169: \item The user starts the application instance and the AHE returns the

1170: initial status of the application instance.

1171: 

1172: \item Once the App WS-Resource is created as a result of the Prepare

1173: operation, its reference handle and associated properties are stored

1174: in the App Instance Registry (see 3 above).

1175: 

1176: \item The AHE server creates one or more JSDL documents based on the

1177: user's specification of the application instance and submits them to

1178: GridSAM which then starts the application instance on the target grid

1179: resource.

1180: 

1181: \item The App WS-Resource uses the proxy certificate for

1182: authentication with the various grid resources that the user wishes to

1183: use.

1184: 

1185: \item The input files are staged from the FSA to the target grid

1186: resource on which the application instance will be executed.

1187: 

1188: \item The user can use the AHE client to invoke, monitor and terminate

1189: commands on the App WS-Resource in order to check the status and, if

1190: need be, to terminate the application instance.

1191: 

1192: \item Once the job finishes, the output files are transferred from the

1193: grid resource to the FSA.

1194: 

1195: \item The user can use the AHE client to manually or automatically

1196: download the output files from the FSA.

1197: 

1198: \item The user can query the App Instance Registry to review the

1199: history of application instances.

1200: \end{enumerate}

1201: 

1202: \begin{thebibliography}{00}

1203: 

1204: \bibitem{pvc2005_1}

1205: P.~V. Coveney, Scientific grid computing, Phil. Trans. R. Soc. A 363 (2005)

1206:   1707--1713, {DOI}: 10.1098/rsta.2005.1603.

1207: 

1208: \bibitem{boghosian2005}

1209: B.~Boghosian, P.~V. Coveney, Scientific applications of grid computing,

1210:   Computing in Science and Engineering 7~(5) (2005) 10--13, {DOI}:

1211:   10.1109/MCSE.2005.95.

1212: 

1213: \bibitem{chin2006_1}

1214: J.~Chin, P.~V. Coveney, Chirality and domain growth in the gyroid mesophase,

1215:   Proceedings of the Royal Society of London Series A, published online, June

1216:   2006{DOI}: 10.1098/rspa.2006.1741.

1217: 

1218: \bibitem{boghosian2006_1}

1219: B.~Boghosian, L.~I. Finn, P.~V. Coveney, Moving the data to the computation:

1220:   multi-site distributed parallel computation.

1221: \newline{h}ttp://www.realitygrid.org/publications/{GD}3.pdf

1222: 

1223: \bibitem{ngs}

1224: {N}ational {G}rid {S}ervice ({NGS}).

1225: \newline{h}ttp://www.ngs.ac.uk

1226: 

1227: \bibitem{teragrid}

1228: P.~H. Beckman, Building the {T}era{G}rid, Phil. Trans. R. Soc. A 363 (2005)

1229:   1715--1728, {DOI}: 10.1098/rsta.2005.1603.

1230: \newline{h}ttp://www.teragrid.org

1231: 

1232: \bibitem{egee}

1233: F.~Gagliardi, B.~Jones, F.~Grey, M.~E. Begin, M.~Heikkurinen, Building an

1234:   infrastructure for scientific grid computing: status and goals of the {EGEE}

1235:   project, Phil. Trans. R. Soc. A 363 (2005) 1729--1742, {DOI}:

1236:   10.1098/rsta.2005.1603.

1237: \newline{h}ttp://www.eu-egee.org

1238: 

1239: \bibitem{deisa}

1240: {D}istributed {E}uropean {I}nfrastructure for {S}upercomputing {A}pplications

1241:   ({DEISA}).

1242: \newline{h}ttp://www.deisa.org

1243: 

1244: \bibitem{naregi}

1245: {N}ational {R}esearch {G}rid {I}nitiative ({NAREGI}).

1246: \newline{h}ttp://www.naregi.org

1247: 

1248: \bibitem{foster2001}

1249: I.~Foster, C.~Kesselman, S.~Tuecke, The anatomy of the grid: Enabling scalable

1250:   virtual organizations, Intl. J. Supercomputer Applications 15 (2001) 3--23.

1251: 

1252: \bibitem{pvc2004_1}

1253: J.~Chin, P.~V. Coveney, Towards tractable toolkits for the grid: {A} plea for

1254:   lightweight usable middleware, UK e-Science Technical Report UKeS-2004-01.

1255: \newline{h}ttp://nesc.ac.uk/technical\_papers/{UK}e{S}-2004-01.pdf

1256: 

1257: \bibitem{blake2005}

1258: R.~J. Blake, P.~V. Coveney, P.~Clarke, S.~M. Pickles, The {T}era{G}yroid

1259:   experiment - {S}upercomputing 2003, Scientific Programming 13~(1) (2005)

1260:   1--17.

1261: \newline{h}ttp://iospress.metapress.com/link.asp?id=gcxd7nr3h1k29rw1

1262: 

1263: \bibitem{jha2005_1}

1264: S.~Jha, P.~V. Coveney, M.~J. Harvey, {SPICE}: {S}imulated {P}ore {I}nteractive

1265:   {C}omputing {E}nvironment, in: Proceedings of the 2005 ACM/IEEE Conference on

1266:   Supercomputing, 2005, pp. 70--75, {DOI}: 10.1109/SC.2005.65.

1267: \newline{h}ttp://www.realitygrid.org/{S}pice/anal109.pdf

1268: 

1269: \bibitem{boghosian2006}

1270: B.~M. Boghosian, P.~V. Coveney, S.~Dong, L.~I. Finn, S.~Jha, G.~Karniadakis,

1271:   N.~Karonis, {NEKTAR}, {SPICE} and {V}ortonics: {U}sing federated grids for

1272:   large scale scientific applications, in: Proceedings of Challenges of Large

1273:   Applications in Distributed Environments, 2006, pp. 34--42, {ISBN}

1274:   1-4244-0420-7.

1275: 

1276: \bibitem{globus}

1277: I.~Foster, C.~Kesselman, Globus: {A} metacomputing infrastructure toolkit, Int.

1278:   J. Supercomputer Applications 11~(2) (1997) 115--128.

1279: \newline{h}ttp://www.globus.org/toolkit/downloads/2.4.3

1280: 

1281: \bibitem{unicore}

1282: D.~Breuer, D.~Erwin, D.~Mallmann, R.~Menday, M.~Romberg, V.~Sander,

1283:   B.~Schuller, P.~Wieder, Scientific computing with {UNICORE}, in: Proceedings

1284:   of the NIC Symposium 2004, Vol.~20 of NIC, John von Neumann Institute for

1285:   Computing, Julich, 2003, pp. 429--440, {ISBN} 3-00-012372-5.

1286: \newline{h}ttp://www.fz-juelich.de/nic-series/volume20/erwin.pdf

1287: 

1288: \bibitem{kewley2005}

1289: J.~Kewley, R.~Allan, R.~Crouchley, D.~Grose, T.~van Ark, M.~Haynes, L.~Morris,

1290:   {GROWL}: A lightweight grid services toolkit and applications, in:

1291:   Proceedings of the 4th UK e-Science All Hands Meeting, 2005.

1292: \newline{h}ttp://www.allhands.org.uk/2005/proceedings/papers/460.pdf

1293: 

1294: \bibitem{pvc2005_2}

1295: P.~V. Coveney, J.~Vicary, J.~Chin, M.~Harvey, {WEDS}: a {WSRF}-based

1296:   environment for distributed simulation, Phil. Trans. R. Soc. A 363 (2005)

1297:   1807--1816, {DOI}: 10.1098/rsta.2005.1608.

1298: 

1299: \bibitem{rixon2005}

1300: J.~Rixon, {U}sing {A}strogrid {CEA} to access compute grids, in: Grid Workshop,

1301:   Strasbourg, 2005.

1302: \newline{h}ttp://cdsweb.u-strasbg.fr/meeting5/rixon-cea-and-grid.pdf

1303: 

1304: \bibitem{blower2005}

1305: J.~Blower, K.~Haines, E.~Llewellin, Data streaming, workflow and firewall

1306:   friendly grid services with {S}tyx, in: Proceedings of the 4th UK e-Science

1307:   All Hands Meeting, 2005.

1308: \newline{h}ttp://www.allhands.org.uk/2005/proceedings/papers/573.pdf

1309: 

1310: \bibitem{wsrf}

1311: {W}eb {S}ervice {R}esource 1.2.

1312: \newline{h}ttp://docs.oasis-open.org/wsrf/wsrf-ws\_resource-1.2-spec-pr-01.pdf

1313: 

1314: \bibitem{wsdl}

1315: {h}ttp://www.w3.org/{TR}/{WSDL}.

1316: 

1317: \bibitem{nat}

1318: The {IP} network address translator ({NAT}), {IETF} {RFC} 1631.

1319: \newline{h}ttp://www.faqs.org/rfcs/rfc1631.html

1320: 

1321: \bibitem{http}

1322: {H}ypertext {T}ransfer {P}rotocol {HTTP}/1.1, {IETF} {RFC} 2616.

1323: \newline{h}ttp://www.w3.org/{P}rotocols/rfc2616/rfc2616.html

1324: 

1325: \bibitem{https}

1326: {HTTP} over {TLS}, {IETF} {RFC} 2818.

1327: \newline{h}ttp://www.faqs.org/rfcs/rfc2818.html

1328: 

1329: \bibitem{soap}

1330: {S}imple {O}bject {A}ccess {P}rotocol ({SOAP}) 1.1.

1331: \newline{h}ttp://www.w3.org/{TR}/soap

1332: 

1333: \bibitem{gt4}

1334: I.~Foster, {G}lobus {T}oolkit {V}ersion 4: {S}oftware for service-oriented

1335:   systems, in: IFIP International Conference on Network and Parallel Computing,

1336:   Springer-Verlag LNCS 3779, 2005, pp. 2--13.

1337: \newline{h}ttp://www.globus.org/toolkit/docs/4.0/

1338: 

1339: \bibitem{tls}

1340: The {TLS} protocol version 1.0, {IETF} {RFC} 2246.

1341: \newline{h}ttp://www.faqs.org/rfcs/rfc2246.html

1342: 

1343: \bibitem{x509}

1344: Internet {X}.509 public key infrastructure certificate mangement protocols,

1345:   {IETF} {RFC} 2510.

1346: \newline{h}ttp://www.faqs.org/rfcs/rfc2510.html

1347: 

1348: \bibitem{jre}

1349: {h}ttp://www.java.com.

1350: 

1351: \bibitem{gridsam}

1352: {h}ttp://gridsam.sourceforge.net/.

1353: 

1354: \bibitem{sge}

1355: {h}ttp://gridengine.sunsource.net.

1356: 

1357: \bibitem{condor}

1358: {h}ttp://www.cs.wisc.edu/condor.

1359: 

1360: \bibitem{fowler2005}

1361: P.~W. Fowler, S.~Jha, P.~V. Coveney, Grid-based steered thermodynamic

1362:   integration accelerates the calculation of binding free energies, Phil.

1363:   Trans. R. Soc. A 363 (2005) 1999--2015, {DOI}: 10.1098/rsta.2005.1603.

1364: 

1365: \bibitem{pickles2005}

1366: S.~M. Pickles, R.~Haines, R.~L. Pinning, A.~R. Porter, A practical toolkit for

1367:   computational steering, Phil. Trans. R. Soc. A 363 (2005) 1843--1853.

1368: 

1369: \bibitem{defabritiis2006}

1370: G.~De~Fabritiis, R.~Delgado-Buscalioni, P.~V. Coveney, Multiscale modelling of

1371:   liquids with molecular specificity, Physical Review Letters 97 (2006) 134501,

1372:   {DOI}: 10.1103/PhysRevLett.97.134501.

1373: 

1374: \bibitem{pvc2006_3}

1375: P.~V. Coveney, G.~De~Fabritiis, M.~Harvey, S.~Pickles, A.~Porter, Coupled

1376:   applications on distributed resources, Computer Physics Communications 175

1377:   (2006) 389--396.

1378: \newline{h}ttp://www.realitygrid.org/publications/coupled\_model.pdf

1379: 

1380: \bibitem{pvc2006_1}

1381: P.~V. Coveney, S.~K. Sadiq, R.~S. Saksena, M.~Thyveetil, S.~J. Zasada,

1382:   M.~Mc~Keown, S.~Pickles, A lightweight application hosting environment for

1383:   grid computing, in: Proceedings of the 5th UK e-Science All Hands Meeting,

1384:   2006.

1385: \newline{h}ttp://www.realitygrid.org/publications/ahm2006{\_}ahe{\_}paper.pdf

1386: 

1387: \bibitem{pvc2006_2}

1388: P.~V. Coveney, S.~K. Sadiq, R.~S. Saksena, S.~J. Zasada, M.~Mc~Keown,

1389:   S.~Pickles, The {A}pplication {H}osting {E}nvironment: {L}ightweight

1390:   middleware for grid based computational science, in: TeraGrid '06 Conference,

1391:   2006.

1392: \newline{h}ttp://www.realitygrid.org/publications/ahm2006{\_}ahe{\_}paper.pdf

1393: 

1394: \bibitem{fowler2006_2}

1395: P.~W. Fowler, S.~Geroult, S.~Jha, G.~Waksman, P.~V. Coveney, The rapid and

1396:   accurate calculation of relative binding affinities for the {SH2} domain

1397:   using a computational grid, preprint (2006).

1398: \newline{h}ttp://realitygrid.org/publications/sh2paper.pdf

1399: 

1400: \bibitem{smith1996}

1401: W.~Smith, T.~R. Forester, A general-purpose parallel molecular dynamics

1402:   simulation package, J. Mol. Graph. 14 (1996) 136--141.

1403: 

1404: \bibitem{kale1999}

1405: L.~Kale, R.~Skeel, M.~Bhandarkar, R.~Brunner, A.~Gursoy, N.~Krawetz,

1406:   J.~Phillips, A.~Shinozaki, K.~Vardarajan, K.~Schulten, {NAMD2}:greater

1407:   scalability for parallel molecular dynamics, J. Comp. Phys. 151 (1999)

1408:   283--312.

1409: 

1410: \bibitem{plimpton1995}

1411: S.~J. Plimpton, Fast parallel algorithms for short-range molecular dynamics, J.

1412:   Comp. Phys. 117 (1995) 1--19.

1413: 

1414: \bibitem{gromacs}

1415: H.~J.~C. Berendsen, D.~van~der Spoel, R.~van Drunen, {GROMACS}: {A}

1416:   message-passing parallel molecular dynamics implementation, Computer Physics

1417:   Communications 91 (1995) 43--56.

1418: 

1419: \bibitem{harting2005}

1420: J.~Harting, J.~Chin, M.~Venturoli, P.~V. Coveney, Large-scale lattice

1421:   {B}oltzmann simulations of complex fluids: advances through the advent of

1422:   computational grids, Phil. Trans. R. Soc. A 363 (2005) 1895--1915, {DOI}:

1423:   10.1098/rsta.2005.1603.

1424: 

1425: \bibitem{lb3d}

1426: {h}ttp://www.realitygrid.org.

1427: 

1428: \bibitem{hpcx}

1429: {h}ttp://www.hpcx.ac.uk.

1430: 

1431: \bibitem{aheserverguide}

1432: {AHE} {S}erver {I}nstallation {G}uide.

1433: \newline{h}ttp://www.realitygrid.org/{AHE}/doc/{AHES}erver{I}nstallation{G}uide.pdf

1434: 

1435: \bibitem{aheclientguide}

1436: {AHE} {C}lient {U}ser {G}uide.

1437: \newline{h}ttp://www.realitygrid.org/{AHE}/doc/{AHEC}lient{U}ser{G}uide.pdf

1438: 

1439: \bibitem{shirts2001}

1440: M.~R. Shirts, V.~Pande, Mathematical foundations of ensemble dynamics, Physical

1441:   Review Letters 86 (2001) 4983--4987.

1442: 

1443: \bibitem{bpel}

1444: {h}ttp://www.oasis-open.org/committees/download.php/18714/wsbpel-specification%

1445: -draft-May17.htm.

1446: 

1447: \bibitem{kalawsky2005}

1448: R.~S. Kalawsky, S.~P. Nee, I.~Holmes, P.~V. Coveney, A grid-enabled lightweight

1449:   computational steering client: {A} .{NET} {PDA} implementation, Philosophical

1450:   Transactions of the Royal Society A 363 (2005) 1885--1894, dOI:

1451:   10.1098/rsta.2005.1617.

1452: 

1453: \bibitem{naregi2}

1454: {NAREGI} {T}he {J}apanese {N}ational {R}esearch {G}rid \& {N}etworking

1455:   {I}nfrastructure.

1456: \newline{h}ttp://www.apan.net/meetings/tokyo2006/presentation/smatusuoka\_NII.pdf/

1457: 

1458: \bibitem{wsagreement}

1459: {h}ttp://www.gridforum.org/Public{\_}Comment{\_}Docs/Documents/Oct-2005/WS-Agr%

1460: eementSpecificationDraft050920.pdf.

1461: 

1462: \bibitem{maclaren2006}

1463: J.~Maclaren, M.~Mc~Keown, {HARC}: {A} {H}ighly-{A}vailable {R}obust

1464:   {C}o-scheduler, submitted to the 5th UK e-Science All Hands Meeting (2006).

1465: \newline{h}ttp://www.realitygrid.org/publications/{HARC}.pdf

1466: 

1467: \bibitem{smarr2006}

1468: L.~Smarr, T.~DeFanti, M.~D. Brown, C.~de~Laat, Special section: igrid 2005: The

1469:   global lambda integrated facility, Future Generation Computer Systems 22

1470:   (2006) 849--851.

1471: 

1472: \bibitem{mpichg2}

1473: N.~Karonis, B.~Toonen, I.~Foster, {MPICH}-{G2}: {A} grid-enabled implementation

1474:   of the {M}essage {P}assing {I}nterface, Journal of Parallel and Distributed

1475:   Computing 63~(5) (2003) 551--563.

1476: 

1477: \bibitem{chin2004}

1478: J.~Chin, P.~V. Coveney, J.~Harting, The {T}era{G}yroid project -

1479:   {C}ollaborative steering and visualization in an {HPC} grid for modelling

1480:   complex fluids, in: Proceedings of the 3rd UK e-Science All Hands Meeting,

1481:   2004.

1482: \newline{h}ttp://www.allhands.org.uk/2004/proceedings/papers/181.pdf

1483: 

1484: \bibitem{jha2006_1}

1485: S.~Jha, P.~V. Coveney, M.~J. Harvey, {SPICE}: {S}imulated {P}ore {I}nteractive

1486:   {C}omputing {E}nvironment - {U}sing federated grids for ``grand challenge''

1487:   biomolecular simulations, in: International Supercomputer Conference, 2006,

1488:   awarded the ISC Innovation Award for Life Sciences.

1489: \newline{h}ttp://www.realitygrid.org/publications/spice\_isc06.pdf

1490: 

1491: \bibitem{tomcat}

1492: {h}ttp://tomcat.apache.org/.

1493: 

1494: \bibitem{omii}

1495: {h}ttp://www.omii.ac.uk.

1496: 

1497: \bibitem{wsrflite}

1498: {h}ttp://www.sve.man.ac.uk/{R}esearch/{A}to{Z}/{ILCT}.

1499: 

1500: \bibitem{wsrfglobus}

1501: {h}ttp://www.globus.org/wsrf/.

1502: 

1503: \bibitem{oasis}

1504: {h}ttp://www.oasis-open.org/home/index.php.

1505: 

1506: \bibitem{tuecke2003}

1507: {O}pen {G}rid {S}ervice {I}nfrastructure.

1508: \newline{h}ttp://www.gridforum.org/documents/{GFD}.15.pdf

1509: 

1510: \bibitem{ggf}

1511: {h}ttp://www.ggf.org.

1512: 

1513: \bibitem{soaplite}

1514: {h}ttp://www.soaplite.com.

1515: 

1516: \bibitem{postgresql}

1517: {h}ttp://www.postgresql.org.

1518: 

1519: \bibitem{jsdl}

1520: {J}ob {S}ubmission {D}escription {L}anguage ({JSDL}) specification, version

1521:   1.0, {GGF}.

1522: \newline{h}ttps://forge.gridforum.org/projects/jsdl-wg/document/draft-ggf-jsdl-spec/en/21

1523: 

1524: \bibitem{webdav}

1525: {IETF}, {HTTP} extensions for distributed authoring - {WEBDAV}.

1526: \newline{h}ttp://www.faqs.org/rfcs/rfc2518.html

1527: 

1528: \bibitem{url}

1529: {U}niform {R}esource {L}ocators ({URL}), {IETF} {RFC} 1738.

1530: \newline{h}ttp://www.faqs.org/rfcs/rfc1738.html

1531: 

1532: \bibitem{mls}

1533: Web services security: {SOAP} message security {V}1.0 (2004), {OASIS} standard

1534:   2000401.

1535: 

1536: \bibitem{mls2}

1537: Web services security: {X}.509 {T}oken{P}rofile {V}1.0 (2004).

1538: \newline{h}ttp://docs.oasis-open.org/wss/2004/01/oasis-200402-wss-x509-token-profile-1.0.pdf

1539: 

1540: \bibitem{ukca}

1541: {h}ttps://ca.grid-support.ac.uk.

1542: 

1543: \bibitem{myproxy}

1544: The {M}y{P}roxy Online Credential Repository, Software: Practice and

1545:   Experience, 2005.

1546: \newline{h}ttp://www.ncsa.uiuc.edu/jbasney/myproxy-spe.pdf

1547: 

1548: \bibitem{factorypattern}

1549: E.~Gamma, R.~Helm, R.~Johnson, J.~Vlissides, Design Pattern: Elements of

1550:   Reusable Object Oriented Software, Addison-Wesley, 1995.

1551: 

1552: \bibitem{wsaddressing}

1553: Web service addressing 1.0 - core.

1554: \newline{h}ttp://www.w3.org/TR/2005/WD-ws-addr-core-20050331/

1555: 

1556: \end{thebibliography}

1557: \end{document}

1558: