Best Practice Project
Rapid Prototyping of Usable
Middleware
Peter Coveney
Centre for Computational Science
University College London
31(P.V.Coveney@ucl.ac.uk)
March 2003
PeterParis,
Coveney
EPSRC Annual e-Science Meeting, 21 April, 2005
Scientists developing middleware!
• Rapid prototyping of usable grid middleware (EPSRC funded, starts April
2005)
• Partners include Manchester, Southampton (Comb-e-Chem), Oxford (IB),
…
• Robust application hosting under WSRF::Lite (OMII funded)
• Combined value £500K cash + £100K in kind support
OMII = Open Middleware Infrastructure Institute (UK)
www.omii.ac.uk
Peter Coveney (P.V.Coveney@ucl.ac.uk)
Talk contents
• Grid computing--what is it?
• Problems with existing grid middleware
• The case for lightweight middleware
• Robust application hosting
• Enabling grid-based computational science
• Materials science example
Peter Coveney (P.V.Coveney@ucl.ac.uk)
Grid Computing
My preferred definition:
Grid computing is distributed
computing performed transparently
across multiple administrative
domains
Notes:
Computing means any activity involving digital information
-- no distinction between numeric/symbolic, or numeric/data/viz
Transparency implies minimal complexity for users of the technology
Peter Coveney (P.V.Coveney@ucl.ac.uk)
See: Phil Trans R Soc London A (2005)
Grid Computing
Problem:
No so-called “Grid” we use today
fulfils this definition
Peter Coveney (P.V.Coveney@ucl.ac.uk)
TeraGyroid Grid
Starlight (Chicago)
10 Gbps
ANL
Netherlight
(Amsterdam)
PSC
Manchester
Caltech
NCSA
BT provision
2 x 1 Gbps
Daresbury
production
network
SJ4
SDSC
MB-NG
Phoenix
Visualization
Computation
Access Grid node
Network PoP
Service Registry
Peter Coveney (P.V.Coveney@ucl.ac.uk)
UCL
Dual-homed system
STIMD Grid
UK NGS
Grid infrastructure
Leeds
Starlight (Chicago)
US TeraGrid
SDSC
Manchester
Netherlight
(Amsterdam)
Oxford
RAL
NCSA
PSC
UKLight
UCL
AHM 2004
Both the US TeraGrid
and UK NGS use GT2
middleware
All sites connected by
production network (not
all shown)
Computation
Steering clients
Network PoP
Service Registry
Peter Coveney (P.V.Coveney@ucl.ac.uk)
Local
laptops,PDAs,
and Manchester
vncserver
Problems for users
• lack of a common API for usable core
functionality (e.g. file-transfer) across distinct grid
applications and domains
• heterogeneous software stacks make grid-application
portability a nightmare for users
• security -- high barrier for getting certificates accepted
beyond the issuing domain (more tomorrow)
• non-uniform scheduling and job-launching resources
and often incompatible policies in different admin domains
• complex grid middleware detrimental to scientific
research, and contrary to the stipulated goals of grid
computing
Peter Coveney (P.V.Coveney@ucl.ac.uk)
Grid computing headaches
• Deployment
• It takes a long time and much effort by many people to get applications
properly deployed
• Lots of things can go wrong
• Most people give up -- ROI too low
• Lack of persistence of grid infrastructure & capabilities
• Security issues (more in tomorrow’s talk)
• Clunky, not very usable
• Existing model not taken seriously by people who care about it
Peter Coveney (P.V.Coveney@ucl.ac.uk)
How we build services on GT2 grids
• Globus Toolkit 2 has limited usable functionality, so we:
• Track specs & standards
• Provide functionality as easily as possible
• Put this on top of GT2 grid middleware
• We do NOT wait for heavyweight/generic solutions provided
by others:
• GT3 (obsolescent)
• GT4 (yes, but when?)
• It’s a recipe for being sidelined indefinitely…
• Lightweight middleware: makes provision of a service
oriented architecture a pleasant experience for all
Peter Coveney (P.V.Coveney@ucl.ac.uk)
Lightweight middleware
• What do we mean by lightweight?
• Minimal dependencies on third-party software
• Small learning-curve for new users – obviate the need to learn new
programming methods
• Interoperable with other WSRG implementations
• Easy to write, and so to adapt to new specs, etc.
• Original use of OGSI compliant services
• Now have WSRF::Lite (interoperable with other WSRG implementations)
• Tracks the evolving WSRF standards, implementing stable areas of the
specifications
Peter Coveney (P.V.Coveney@ucl.ac.uk)
Lightweight middleware
• OGSI::Lite/WSRF::Lite
• by Mark McKeown of Manchester University
• Lightweight OGSI/WSRF implementation, written in Perl
• uses existing software (eg for SSL) where possible; simple installation
• Necessary for all RealityGrid grid work
• Using OGSI::Lite (2003):
• Grid-based job submission and steering retrofitted onto the LB2D
workstation class simulation code within a week
• Standards compliance: we were able to steer simulations from a web
browser, with no custom client software needed
• Now developing extended capabilities using WSRF::Lite on
US TeraGrid & UK NGS
• We have developed WEDS--a web service hosting
environment for distributed simulation
Peter Coveney (P.V.Coveney@ucl.ac.uk)
About WEDS
• Developed to make life easy for application scientists for once
• Easy to deploy – sits inside a WSRF::Lite container, has no additional
software requirements
• Provides all the tools and glue required to:
• expose an unaltered binary application as a service
• create and interact with service instances
• Broker service manages creation of services, to load balance across a
pool of machines
• For grid deployment, needs:
• security solution (WS-Security, TLS) and
• grid job submission tools (from OMII_1, others from GridSAM project)
Peter Coveney (P.V.Coveney@ucl.ac.uk)
See Coveney et al., 2004, NeSC Tech Rpt
WEDS Architecture
Client
Broker
Machine Service
Service Factory
Wrapper Service
Invoked
Application
Managed resource
Peter Coveney (P.V.Coveney@ucl.ac.uk)
• Each resource runs a
WSRF::Lite container
containing a WEDS
machine service and
factory services for each
hosted application.
• Each machine that a user
wishes to use is registered
with a broker service
• The user contacts the
broker with the details of
the job to run
• The broker match-makes
the job details with the
capabilities advertised by
each machine service and
decides where to invoke
the service
• The broker passes back
the contact details of the
service instance to the
client
About WEDS
• Can interact flexibly with OMII middleware
• OMII interface to WEDS resources
• WEDS broker will soon interact with GT2, OMII resources
• Delegation of file-transfer to existing transports (HTTP(S), FTP, GridFTP,
etc)
• Provides C and Fortran API to allow an application programmer to
expose a richer service interface to the application.
• Already hosted: LB2D, DL_MESO, NAMD, LAMMPS, CPMD
• RealityGrid steering will be incorporated as those tools move towards
WSRF compliance
Peter Coveney (P.V.Coveney@ucl.ac.uk)
OGSA/WSRF compliance
• In the main, the hosting environment is WSRF- and OGSAcompliant
• BUT we have to go outside these specifications (with
DataProxy) because they require binary data to be moved
within XML files!
• W3C has spotted the problem and is now proposing
recommendations
Peter Coveney (P.V.Coveney@ucl.ac.uk)
Transferring binary data
World Wide Web Consortium Issues Three Web
Services Recommendations
• http://www.w3.org/ -- 25 January 2005 -- The World Wide Web
Consortium (W3C) has published three new Web Services
Recommendations: XML-binary Optimized Packaging (XOP), SOAP
Message Transmission Optimization Mechanism (MTOM), and
Resource Representation SOAP Header Block (RRSHB). These
recommendations provides ways to efficiently package and transmit
binary data included or referenced in a SOAP 1.2 message.
• Web Services Applications Need Effective, Standard Methods for
Handling Binary Data
Peter Coveney (P.V.Coveney@ucl.ac.uk)
Transferring binary data
”One of the biggest technical and performance issues for
Web services occurs when a user or application is handling
large binary files. Encoding binary data as XML produces
huge files, which absorbs bandwidth and measurably slows
down applications. For some devices, it slows down so
much that the performance is considered unacceptable.”
http://www.w3.org/2005/01/xmlp-pressrelease
Peter Coveney (P.V.Coveney@ucl.ac.uk)
Robust application hosting
• Developing our lightweight hosting tools to meet the needs of applications
scientists
• No preconceptions about the 'right way' to do things or pre-determined adherence to
particular specifications or “work flows”
• Gain experience by working with real-world problems, refactoring design as required
• Projects/people we are collaborating with as “end-users”
--Daniel Mason (Imperial) -- polystyrene-surface interactions (see demo)
--CCP5’s DL-MESO Project (Rongshan Qin, DL) -- mesoscale modelling/simulation
--Jonathan Essex (Southampton) -- NAMD for protein modelling
--Integrative Biology EPSRC e-Science Project project
--IBiS (Integrative Biological Simulation) BBSRC Bioinformatics & e-Science Project
• Close collaboration with OMII and its middleware
Peter Coveney (P.V.Coveney@ucl.ac.uk)
The Polysteer Application
Developed by Daniel Mason (Imperial; ReG partner)
• New Monte Carlo polymer simulation code
– Create as many chain conformations as possible
Task farming of configuration generation
• Equilibration is difficult from arbitrary start point
– Need to watch chains relax
Attach visualisation client
• Monte Carlo moves are complex
– Modify parameters on-the-fly to optimise efficiency
Attach steering client
Peter Coveney (P.V.Coveney@ucl.ac.uk)
Lightweight hosting of Polysteer application
Peter Coveney (P.V.Coveney@ucl.ac.uk)
Visualisation
• Visualisation client attaches to a running simulation
• Data transfer via files using ReG steering library
-Fortran main code to Java visualiser
• Showing each atom is
unreadable
• Potentials treat CHx, Bz
as single entities
• We visualise ellipsoids
rather than spheres
Peter Coveney (P.V.Coveney@ucl.ac.uk)
Summary
• Lightweight middleware greatly facilitates
deployment of applications on grids
• We’re now working with several “computational
user communities” from physics through to biology
• All our middleware will be in the public domain
Peter Coveney (P.V.Coveney@ucl.ac.uk)
Acknowledgements
• Matt Harvey, Laurent Pedesseau, Mark Mc Keown,
Stephen Pickles, Daniel Mason, Jonathan Chin
• EPSRC
• OMII
Peter Coveney (P.V.Coveney@ucl.ac.uk)