Endpoint Services

1. Glen Dobson Lancaster University, Computing Department g.dobson@lancs.ac.uk http://digs.sourceforge.net Endpoint Services

2. 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 Who We Are

3. 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. 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. 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. Previous Work: Proxy for Fault Tolerance (1)

6. Proxy for Fault Tolerance (2)

7. 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. 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. 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. 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. 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. 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.

13. 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. 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. 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>

16. 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.

18. Endpoint Services Configration Tool • To simplify the creation and configuration of Endpoint Services we have developed a graphical tool.

19. Endpoint Services Configuration Tool • A project can include more than one Endpoint. • The tool also includes an aid to container configuration:

20. 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. Questions/Comments