Service dependability Ian Sommerville 2006 MSc module Advanced

Service dependability ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 1

Objectives l l l To explain what is required to ensure that services are dependable To discuss mechanisms which can be used to deliver service dependability To introduce you to some research work in service-oriented software engineering ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 2

Topics covered l l l Reliable message interchange Service-fault tolerance A generic mechanism to implement fault tolerant services ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 3

Dependability l l The dependability of a system reflects the extent that the system can be trusted to deliver its required services in a safe and secure way Dependability (in general) will be covered in the 2 nd semester. • Today, I’ll simply focus on one aspect of dependability as applied to service • Availability - the service is available to service requests • Reliability - the services delivers results according to its specification ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 4

Dependability requirements l l Requests for services from service clients and responses to these requests are reliably delivered Advertised services are available • l Both the service software and the servers must be available Services deliver results as advertised • Services must be reliable ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 5

Reliable messaging l l When one service sends a message to another, the sending service should be confident that message will (eventually) reach its destination Sometimes, it is essential that one and only one copy of messages are delivered • l E. g. a withdrawal from a bank account Sometimes, messages must be received in exactly the order they have been sent • E. g. a sequence of database updates ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 6

Messaging standards l Two similar but incompatible standards have been proposed • WS-Reliability. • Has the backing of most companies except Sun and IBM • WS-Reliable. Messaging • Has the backing of Sun and IBM l l It is not yet clear which of these will emerge as the dominant standard. I will illustrate the topic using WSReliable. Messaging ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 7

Reliable message processors Service A Sending RMP Receiving RMP ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Service B Slide 8

Reliable message processors l l l Part of middleware that facilitates service interaction so may be used by any service They are NOT part of the services themselves Sending RMP • • l Submit. Transfers a message from producer to sending RMP Notify. Transfers a response message from the sending RMP to the producer Receiving RMP • • Deliver. Transfers a message from the receiving RMP to a consumer Respond. Transfers a response message from the consumer to the receiving RMP ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 9

RMP operation l l RMP’s add information to the SOAP message header that allows for message exchange to be correlated This allows the middleware to identify duplicate messages, acknowledge message delivery and ensure that messages are delivered in the correct sequence. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 10

Service availability and reliability l To ensure availability, it must be possible to continue to deliver a service when software and/or hardware has failed • l This suggests that there has to be more than one instance of a service plus a mechanism to switch between them in the event of a failure To ensure reliability, it must be possible to check if the results of a service are consistent with its specification ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 12

Fault tolerance l Fault tolerance is: • The ability of a system to continue execution (perhaps offering a degraded service) without system failure in the presence of system faults. l l Fault tolerance is mostly used to provide enhanced system availability but may also be used where a system has critical reliability requirements. For web services, fault tolerance mechanisms may be used to ensure service availability and reliability. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 13

Redundancy and diversity l Redundancy • A system includes functionality that replicates other functionality provided elsewhere in the system. l Diversity • Redundant functionality is provided in different ways. l Providing diversity and redundancy in systems is expensive. Generally, confined to critical systems ie systems where the costs associated with system failure are high. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 14

Fault tolerance policies l Re-try (with/without diversion) • Simple re-try (of a service) handles transient failures; Re-try with diversion handles platform failures. l N-version execution with voting • Simultaneous execution of multiple versions of a service. Handles system failure either lack of service or inconsistent computation. l Constrained execution • Execution of a service with checks on inputs. Handles out-ofrange computation. l Alternative version execution with acceptance tests • Handles system failure - either lack of service or out of range computation. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 15

Service fault tolerance l l The services used in an application may be provided by unknown providers on unknown hardware. Service users do not know anything about how well these services • • l l Meet their specification Have been tested for defects It therefore makes sense to try to ensure that a serviceoriented system can continue to operate even when faulty services are used This means that the system should be fault-tolerant. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 16

Fault tolerant services l l In its most general form, this approach relies on the existence of multiple versions of a service. The vision of competing services offered by different providers provides redundancy and diversity so fault tolerance can be widely deployed. • Service provider • May use fault tolerance to help achieve an advertised quality of service. • Service client • May use fault tolerance to achieve a required quality of service or to enhance service trust. l Ideally, a common mechanism should be available that can be used by both providers and clients. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 17

The container model l Used in component-based software engineering e. g. EJB • Common services (e. g. transaction management) required by different components are provided by a ‘container’. • To deploy a component, it is included in a container and thus it ‘inherits’ access to common services. l We decided to adopt a comparable approach where services are deployed in a container which is configured to provide fault tolerance support. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 18

Conceptual model ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 19

Container components l Policies • A generic container is configured by a fault tolerance policy. • This is an XML description of the strategy to be used to achieve fault tolerance. l Procedures • The container includes a set of procedures (currently in Java) that implements the defined policy. l A proxy service • This manages access to the actual services that are used. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 20

Anatomy of a container ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 21

A voting policy ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 22

Policy models l l l An XML description of the fault tolerance policy to be adopted. This includes references to the procedures to be executed, the conditions for fault detection and the mechanisms for fault recovery. This description is then interpreted by the container to implement the fault tolerance procedures. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 23

Fault-tolerant service provision l l Research project on service dependability to investigate how to provide service fault tolerance Goals • • • The F/T controller should not require any change in existing services or service usage by clients. Services should not have to be aware that they are accessed through a F/T controller. The F/T controller should accommodate a range of fault tolerance policies. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 24

Policy model representation <? xml version="1. 0" encoding="UTF-8"? > <policy. Model> <procedure name="Voting. Procedure" class="net. sourceforge. digs. endpoints. voting. Voting. Procedure" start="true"> <voting requirement="5"> <vote> <xpath>//max. Temp</xpath> <vote. Class>net. sourceforge. digs. endpoints. voting. vote. Integer. Vote</vote. Class> <majority>3</majority> <tolerance>2</tolerance> </vote> <xpath>//min. Temp</xpath> <vote. Class>net. sourceforge. digs. endpoints. voting. vote. Integer. Vote</vote. Class> <majority>3</majority> <tolerance>2</tolerance> </voting> ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 25

Policy model representation <connections> <connection id="Proxy 1" procedure="Proxy 1"/> <connection id="Proxy 2" procedure="Proxy 2"/> <connection id="Proxy 3" procedure="Proxy 3"/> <connection id="Proxy 4" procedure="Proxy 4"/> <connection id="Proxy 5" procedure="Proxy 5"/> </connections> </procedure> <procedure name="Proxy 1" class="net. sourceforge. digs. endpoints. proxy. Procedure"> <endpoint url="http: //in-ega 051000012. lancs. ac. uk: 8080/weather. bbc. co. uk" proxy. Host="wwwcache. lancs. ac. uk" proxy. Port="8080"/> </procedure> …. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 26

Procedures l l We provide a set of generic procedures that can be adapted for use in different policy models Flow control • Implement the fault tolerance pattern l Redirection • Handle redirection to actual services l Caching • Store messages within the container l Query • Used for message querying and manipulation ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 27

Container hosting l l l Containers are not stand-alone entities but are hosted on a Java servlet engine (currently Apache Tomcat). This means that we need be less concerned with issues of performance, security and stability and can focus on fault tolerance. It also allows the dynamic deployment of containers thus opening up the possibility of responsive fault tolerance policies that change according to the services available. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 28

©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 29

Deployment support l To simplify the development of fault tolerant services, we have developed a deployment tool that allows: • Graphical editing of F/T policies and generation of associated XML description. • Access to reusable components • Automated support for deployment to the servlet engine by creating a Web Archive (WAR) file. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 30

Policy and procedure reuse l l l We do not envisage that developers will normally develop policies and procedures from scratch. Our support tool is geared to supporting policy and procedure reuse and gives users access to a library of existing policies and procedures that can be modified. We are currently developing a ‘wizard’ that will allow commonly used policies (e. g. N-version execution with voting) to be configured with no requirement for the user to be aware of the underlying implementation. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 31

The deployment process l Assuming that policies and procedures can be reused, the steps involved are: • Create or edit the fault tolerance policy using the graphical editing system and generate the policy model. • Chose and adapt or implement the procedures to implement the policy. • Deploy the results as a WAR file. l Depending on the extent of reuse, creating a fault tolerant service can take between a few minutes and a few hours to complete. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 32

The deployment tool ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 33

Dynamic adaptation l The model used allows for the possibility of dynamic adaptation of the fault tolerance policy to be used • As the policy is simply an XML document, clients could specify their own policies in the SOAP message that initiates the service call. • The container could dynamically switch policy models depending on the Qo. S provided. • Dynamic discovery and replacement of services could be provided. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 34

Current issues l Semantic equivalence of services • Services provide similar services but with different interfaces. We need to be able to specify semantic equivalences across services. l Stateful services • Services with state offer both problems and opportunities when implementing fault tolerance policies. l Checkpointing • How should checkpointing be supported for composed and computationally intensive services? l Container failure • How should container failure be handled? ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 35

Policy extensions l Service failure simulation • One of the problems we have faced is in testing our system - failures of externally provided services are uncontrollable. • Failure policies could be embedded thus allowing simulators for service testing to be created. l Service monitoring • Monitoring policies (see next slide) could be developed. l Service access control • Rather than embedding access control in the service itself, access control policies could be defined. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 36

Service monitoring l l l Monitoring involves maintaining information about the quality of the service. In general, monitoring should be separated from the service provision. Provider-side monitoring • Providers use monitoring to assess the effectiveness of their service and to inform re-configuration for service improvement. l Client-side monitoring • Clients use monitoring to assess the actual quality of service which THEY receive. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 37

Conclusions l Our goal of developing a flexible and adaptable faulttolerance mechanism for services has been achieved (for atomic services). • Current work is concerned with extending the model to cope with composite services and long transactions. l The mechanism is a generic mechanism that has significant potential for use in other areas • Work is about to start on how it can be adapted for service monitoring. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 38

Key Points l Service dependability relies on • • • l Reliable interchange of messages Service availability Service reliability Reliable messaging is supported by adding message delivery information to the SOAP header with middleware using this information to ensure reliable message interchange ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 39

Key Points l l l Availability and reliability can be enhanced by using fault tolerance techniques Container based fault tolerance provides fault tolerance mechanism in a container which can be used by all services. By deploying several services in a container, a range of fault tolerance policies may be supported. ©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 40