1. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/7/04 Endpoint Services Glen Dobson Lancaster University, Computing Department g.dobson@lancs.ac.uk http://digs.sourceforge.net

2. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/7/04 Who We Are Dependability Infrastructure for Grid Services Lancaster University: Ian Sommerville, Glen Dobson, Stephen Hall University of Edinburgh: Stuart Anderson, Conrad Hughes A project jointly undertaken with... Dependability Interdisciplinary Research Collaboration http://www.dirc.org.uk UK E-Science Programme

3. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/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.

4. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/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.

5. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/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.

6. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/7/04 Proxy for Fault Tolerance (2)

7. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/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.

8. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/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.

9. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/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.

10. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/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.

11. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/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.

12. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/7/04 Processor XML [... ] [... nested processors...] [... processor specific XML...] ● 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.

13. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/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.

14. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/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.

15. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/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:...

16. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/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.

17. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/7/04

18. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/7/04 Endpoint Services Configration Tool ● To simplify the creation and configuration of Endpoint Services we have developed a graphical tool.

19. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/7/04 Endpoint Services Configuration Tool ● A project can include more than one Endpoint. ● The tool also includes an aid to container configuration:

20. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/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.

21. Glen Dobson, Lancaster University g.dobson@lancs.ac.uk Service Grids Workshop NeSC Edinburgh 23/7/04 Questions/Comments