glen dobson, lancaster university g.dobson@lancs.ac.uk service grids workshop nesc edinburgh 23/7/04...
Post on 18-Jan-2016
214 Views
Preview:
TRANSCRIPT
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
Endpoint Services
Glen DobsonLancaster University, Computing Department
g.dobson@lancs.ac.uk
http://digs.sourceforge.net
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
Who We Are
Dependability Infrastructure for Grid ServicesLancaster University: Ian Sommerville, Glen Dobson, Stephen Hall
University of Edinburgh: Stuart Anderson, Conrad Hughes
A project jointly undertaken with...
Dependability Interdisciplinary Research Collaborationhttp://www.dirc.org.uk
UK E-Science Programme
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
Overview of Presentation
● Previous DIGS work.● Proxy for Fault Tolerance.
● The Endpoint Service architecture itself.● A bottom up discussion.
● The Endpoint Services Configuartion tool.● Future Directions.
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
DIGS Project Aims
● To enable a simple high level means of adding increased dependability to services.
● Initially to concentrate on fault tolerance.● To make this as transparent as possible to users.
● Ideally using a 'more dependable' service should appear identical to using the 'less dependable' service/s.
● Potentially to use service discovery and late binding to perform e.g. dynamic recovery.
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
Previous Work: Proxy for Fault Tolerance (1)
● A proxy● To allow the addition of fault tolerance to services.● Proxied at SOAP level.
● Proxy accepted XML representation of fault tolerance pattern as configuration.
● SOAP request forwarded to one or more services according to this pattern.
● Gave the user the impression of using a single service, when in fact, they may have been communicating with a composition of a number of services.
● Largely transparent to the end user.
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
Proxy for Fault Tolerance (2)
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
Fault Tolerance Patterns
What do we mean by this? Things like:● Redundancy
– First valid response– Voting– Average– etc.
● Recovery Blocks● Checkpointing
● With other aspects of dependability to potentially come later.
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
Endpoint Services
● An evolution of proxying approach from monolithic to modular.
● An Endpoint Service = a finer grained proxy.– Both approaches aim to map a client request to one or more
services according to some configurable pattern.● The Endpoint Service itself is decomposable.
● Why the name Endpoint Services?● An Endpoint Service provides no functionality of its own -
but 'adds value' to existing services.
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
Improvements on Monolithic Proxy
● More Manageable:● Proxies were envisioned to be installed locally to clients.
But we really wanted providers to do the configuration in order to maintain transparency.
● More Easily Extensible:● Develop your own Module/s. No need to hack the
monolithic proxy to achieve given functionality.● More Generic by Design:
● Other 'added value' beyond fault tolerance is also more easily achieved due to modularity.
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
Processors
● Starting from the bottom up...● The modules that an Endpoint Service decomposes into are
called Processors. These form a directed graph.
● A Processor is interchangeable between an XML form and a Java class (i.e. it serializes to XML).
● Equivalent in the Proxy to:● An extension to the configuration XML schema.● Code within the proxy to implement the desired
functionality.
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
What a Processor Might Be
● For fault tolerance...● e.g. RedundancyProcessor, RecoveryBlockProcessor, etc.
● Almost anything else...● e.g. Measurement, Monitoring, Authentication, Result
checking, etc.– A Processor may also implement its functionality by calling
external services.
● An HTTPProxyProcessor will exists in all useful Endpoint Service configurations. This passes the request message on to a destination service.
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
Processor XML
<processor name=”...” class=”...” [start=”true”]>
[<outputs>
<output processor=”...” id=”...”>
...
</outputs>]
[... nested processors ...]
[... processor specific XML ...]
</processor>
● Name must be unique within a configuration.● Class indicates an implementing class.● Outputs lists processors to pass the message context on to.● Processors may be nested.● A specific type of processor may have its own specific XML.
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
Processor Implementation
● A Processor implementation extends the abstract Java class Processor
● Constructs itself from XML configuration.● Can convert itself back to XML.● Has an invoke method
– This takes a Message Context as input– The Processor acts upon or alters the Message Context and passes
the context on to its outputs.
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
Message Context
● Why 'Message Context' rather than just Message?● More than the request itself needs to be passed around in
order to achieve added functionality.
● Message Context includes:● The request message.● The response message (if and when received).● Processor specific information.
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
The Container
● The graph of processors exists within a container.● The container is in fact implemented as a processor itself. It
is the first to receive the message context and passes it on to its root processor (marked by the start=true attribute).
● The container configuration simply consists of a list of processors:
<container>
<processor ...>...</processor>
<processor ...>...</processor>
...
</container>
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
Architectural Overview
● The Endpoint Service is deployed as a Java web application.
● The client communicates with a Listener● A Listener is a servlet which accepts a SOAP request and
passes a corresponding Message Context to the container.● The required functionality is achieved by passing the
message context through a directed graph of modules called Processors.
● A processor acts upon and/or alters the message context.
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
Endpoint Services Configration Tool
● To simplify the creation and configuration of Endpoint Services we have developed a graphical tool.
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
Endpoint Services Configuration Tool
● A project can include more than one Endpoint.
● The tool also includes an aid to container configuration:
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
Future Work
● Bulk out the base fault tolerance implementation.● Develop scenarios to demonstrate and evaluate this.
● Fault Tolerance Policies/Wizard● Add API for plugin Processor editors.● Consider issues in generalising the architecture
for languages other than Java.
Glen Dobson, Lancaster Universityg.dobson@lancs.ac.uk
Service Grids Workshop NeSC Edinburgh23/7/04
Questions/Comments
top related