glen dobson, lancaster university [email protected] service grids workshop nesc edinburgh 23/7/04...

Glen Dobson, Lancaster [email protected]

Service Grids Workshop NeSC Edinburgh23/7/04

Endpoint Services

Glen DobsonLancaster University, Computing Department

[email protected]

http://digs.sourceforge.net



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



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.



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.



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.



Proxy for Fault Tolerance (2)



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.



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.



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.



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.



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.



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.



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.



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.



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>



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.



Endpoint Services Configration Tool

● To simplify the creation and configuration of Endpoint Services we have developed a graphical tool.



Endpoint Services Configuration Tool

● A project can include more than one Endpoint.

● The tool also includes an aid to container configuration:



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.



Questions/Comments

glen dobson, lancaster university [email protected] service grids workshop nesc edinburgh 23/7/04...

Documents