The Developer Perspective
The Application Hosting Environment
Stefan Zasada
Centre for Computational Science
University College London
Introduction
• User requirements/motivations
• Identifying and understanding requirements
• The design of the AHE
• User interaction
• Why we took this approach
• Development issues
• Future plans
User Requirements
• Quickly and easily run applications on remote
resources
• Move input files from desktop to grid resource
• Stage files back after execution
• Steer simulation as it’s running
• Visualize results
Motivations
• Quickly and easily run scientific applications
on the grid, e.g. molecular dynamics codes
such as NAMD
• Very often a group of users will want to access
the same application
• Install the application once, then provide a
service to allow others to share it
• Hide complexity of submitting jobs to grid
Design
•
Design arisen from previous experience using
grid middleware:
–
–
–
–
Difficult to configure and/or install
Dependant on lots of supporting software
Require modified versions of common libraries
Require lots of non-standard ports to be opened
on firewall
– Large footprint – memory/disk space
•
Base on ideas of WEDS
Design
• SOA Approach - WRSF Compliant
• Applications represented as stateful WS-Resources
• User interacts with the WS-Resource to manage
application
• Uses WSRF::Lite Perl toolkit
• Uses GridSAM for job submission
• MyProxy - required by GridSAM when submitting to
Globus
Architecture of the AHE
AHE Client Interaction
• Java command line and GUI clients provided
• Clients allow user to prepare application,
stage files and submit
• GUI client implemented a wizard that takes
user through steps of starting application
• Client parses app config file to find files to
stage in and out
• Parser plug-ins can be written for new apps
Why we took this approach
• We provide a programmatic interface to manage
running application
• Allows a variety of different clients to be developed
• Running client on local machine allows us to stage
files more easily
• Less restrictive that forcing users to use a portal
• Some apps require local visualization clients to be
installed
Benefits of the design
• Command line clients can easily be called from script
to automate complex workflow
• When investigating mutation patterns of HIV-1
protease we need to perform equilibration protocols
that involve chained MD simulations
• Easy to administer:
– server can be deployed be expert user on workgroup by
workgroup basis
– Client can be deployed by user
Technical Strategy
• Standards chosen: WSRF, MyProxy, WebDav
SSL/X.509
• Services provided dictated by GridSAM
• Operations necessary to manage application:
prepare, stage files, start, terminate, destroy
• GridSAM offers a common set of operations for
all DRMs supported
Development Issues
• Time: minimum set of functions available in
first release; plan to add more
– Would have been nice to have more time for
evaluation
• Java/Perl web services interoperate pretty well
• Too much input from users?
– Everyone has different requirements they want
supporting
Evaluation
• Difficult to establish evaluation metrics
– How long it takes to submit a job is dependant on
the job type
• Does it make using the grid simpler - yes
• Real world evaluation - used to run production
jobs
• Need to plan in more time for rigorous
evaluation into future release cycles
Lessons Learnt
• Most successful:
– AHE used for production runs in the NGS and
TeraGrid
– Simple design and command line clients allow for
complex scientific workflows to be constructed
• Least successful:
– Implementation needed some modification to run
in Tomcat
– Too early to tell?
Future Plans
• Integrate into OMII stack
• Orchestrate complex workflows (using BPEL,
Taverna?)
• Use RealityGrid steering web service
• Coupled models – host applications which are
made up of other application components
• Clients to run on a PDA/mobile phone
Summary
• AHE is a kind of portal
– Platform on which we can build
• Lightweight and useable
• Providing programmatic interface allows different
types of client to be developed that meet different
user needs
• Allows for scientific applications to be easily
deployed and shared
• Lightweight nature requires minimum input from
system administrators etc.
Acknowledgements
• UCL: Peter Coveney, Matt Harvey, Laurent
Pedesseau, Radhika Saksena, James Suter,
Phil Fowler, Kashif Sadiq, Mary-Ann Thyveetil,
Giovanni Giupponni, Simon Clifford
• Manchester: Mark McKeown, Stephen Pickles,
Rob Haines, Andy Porter
• EPSRC
• OMII
Links
• RealityGrid web site:
http://www.realitygrid.org/AHE
• NeSCForge:
http://forge.nesc.ac.uk/projects/ahe/
• Mailing list:
http://www.mailinglists.ucl.ac.uk/mailman/listinfo/ahe-discuss