Assessing the Dependability of SOAP RPC-Based Web Services by Fault Injection - PDF

Please download to get full document.

View again

of 8
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report



Views: 0 | Pages: 8

Extension: PDF | Download: 0

Related documents
Assessing the Dependability of SOAP RPC-Based Web Services by Fault Injection Nik Looker and Jie Xu Department of Computer Science, University of Durham, DH1 3LE, UK {n.e.looker,
Assessing the Dependability of SOAP RPC-Based Web Services by Fault Injection Nik Looker and Jie Xu Department of Computer Science, University of Durham, DH1 3LE, UK {n.e.looker, Abstract This paper presents our research on devising a dependability assessment method for SOAP-based Web Services using network level fault injection. We compare existing DCE middleware dependability testing research with the requirements of testing SOAP RPC-based applications and derive a new method and fault model for testing web services. From this we have implemented an extendable fault injector framework and undertaken some proof of concept experiments with a system based around Apache SOAP and Apache Tomcat. We also present results from our initial experiments, which uncovered a discrepancy within our system. We finally detail future research, including plans to adapt this fault injector framework from the stateless environment of a standard web service to the stateful environment of an OGSA service. Keywords: Software Fault Injection, Web Services, SOAP. 1 Introduction Web services form the backbone of the modern Internet and as such require dependable middleware products to facilitate reliable client/server interactions. The SOAP protocol [1], as a means of exchanging data between clients and services, is one of the most popular protocols currently in use but there seems to have been little research done on testing its dependability and fault tolerance. This is required not only to uncover existing problems with the system but to also provide potential users with metrics to compare its dependability to other systems. Fault injection is a well-proven method of assessing the dependability of a system [2]. Although much work has been done in the area of fault injection and distributed systems in general, there appears to have been little research carried out on applying this to middleware [3] except in relation to CORBA middleware. This paper sets out a method and fault model for testing SOAP based RPC middleware and details experimental results obtained. The main aim of our research will be 1) to define a method to assess the dependability of web service middleware, 2) to identify key components within web service middleware to apply this method to, 3) to apply this method to a key area of web service middleware to act as a proof of concept of the method and 4) to provide metrics to allow the method to be refined for future experiments. Our method will be based around injecting meaningful faults into SOAP messages, rather than randomly corrupting bytes within a transport packet, therefore allowing individual parameters to be changed. We intend to extend this method at a later date to allow individual API parameters to be changed and thereby test the robustness of a web service s error checking and fault tolerance. We further intend to make this technique generic enough to be of use testing stateful OGSA based GRID middleware products [4]. Previous research in the field of middleware testing via fault injection has concentrated on tightly coupled, RPC based distributed systems [3]. In defining a testing method for web service middleware a new set of challenges are faced which require different solutions and effect the areas of the system which are given priority of testing. Key differences that will be considered will be: 1) greater chance for network failure, 2) higher levels of security and encryption within the protocol stack, 3) more generic nature of the platform and the need to support multiple programming languages, and 4) timing constrains and the asynchronous nature of web service RPC operations. The contribution of the paper will therefore be: 1) to analyse differences between techniques used to characterise tightly coupled, RPC based distributed systems and SOAP based RPC based distributed systems, 2) to define a method to characterise web service middleware and 3) to apply this method to a web service component. The characterisation technique used in this practical work is based on a modified version of network level fault injection to get round certain security mechanisms (see Section 3.-1). The initial experiments have been conducted using Tomcat 4, Apache SOAP 2.2 and Java running on RedHat Linux Web Services verses DCE Systems Web service architectures represent a radical departure from the classical, tightly coupled RPC based distributed systems such as CORBA [5] and DCOM [6, 7] by moving away from a tightly coupled RPC based architecture to a service based one. This new approach to distributed systems architecture requires a new fault model and testing method to that which has gone before. Although there has been some published work on the dependability of classical distributed systems middleware [3], there has been little work published on web service middleware dependability. Our work aims to define a method for assessing the dependability of web service middleware, and SOAP based RPC in particular. In designing a new fault model for testing web service middleware it is important to review the differences between web service middleware and traditional distributed systems so that we can decide which existing techniques are appropriate to apply and which features will require new techniques. We shall therefore use this section to compare web service middleware to CORBA and DCOM, two of the most popular middleware products based on the DCE specification [8]. 2.1 Interface Definition The DCE specification defines an interface definition language (IDL) for the purpose of specifying interfaces. The definition language is compiled via an IDL compiler to a form that can be utilised by the middleware. This will be proxy/stub code in the case of CORBA, or a combination of type library code and/or proxy/stubs for DCOM. This means that both the client and the server must have copies of the proxy information in order to marshal and un-marshal data packets. This also makes dynamic discovery of service information problematic. Web services use a number of different systems to active the same end. One of the most popular of these systems is Web Service Definition Language (WSDL) [9]. These are definitions in XML, and are held at well-known locations. Each host will reference this single WSDL definition of a service and dynamically marshal/unmarshal data accordingly, thus circumventing the need for each host to have a copy of proxy/stub code. When using WSDL with Tomcat, it is necessary to employ another level of mapping to map the WSDL definition onto the Tomcat Deployment Descriptor, which is Tomcat s proprietary method of exporting interfaces. In both cases the detailed interface definitions could be used to help automate test generation by parsing the definition files and generating tests based upon them. It is envisaged that some manual intervention would be required to add boundary limits to the tests since these are not defined in WSDL. 2.2 Message Format The DCE specification defines a binary message format for use by DCE middleware implementations. There are two formats of message, a connection oriented message format and a connectionless message format. This means that DCE can be run over both a connection oriented and connectionless oriented transport. Since the DCE specification doesn t define the transport layer to be used, the specification defines a comprehensive protocol for exactly once delivery for both protocols. SOAP messages are defined using an XML, variable length based format. SOAP doesn t make any assumptions about the underlying transport and utilizing middleware may support both synchronous and asynchronous messaging. A binary format message is relatively easy to inject a fault into since each message of a given type has the same byte level layout. Since XML message formats are variable length ASCII text, injecting faults into a message would require parsing the XML, injecting the message and then outputting a new XML message. 2.3 Synchronous and Asynchronous Transfers DCE based distributed systems tend to be synchronous in nature, although both CORBA and COM+ now provide asynchronous capabilities. The main method used by these two middleware products is to implement asynchronous messaging via polling. An asynchronous interface is compiled from the IDL with multiple stub methods generated for each call, i.e. one to send the message, one to poll for a response, etc. Another commonly used method of supplying asynchronous notifications is to implement a call-back interface. This is usually done by creating a publicly exposed interface on the client and then passing an interface pointer to the server. The server can then call exposed methods on this interface when it needs to notify the client of some event. This does have the disadvantage of introducing concurrency issues. SOAP based RPC protocols used in web services tend to be simple synchronous request/response protocols but the SOAP definition doesn t exclude the use of SOAP messaging in an asynchronous manner. This is left up to the middleware implementation. DCE and web service middleware implement roughly the same set of RPC transfer mechanisms - similar fault injection models can be used to test web service middleware. 2.4 Authentication and Encryption DCE based systems use a public key challenge protocol to authenticate a connection within a DCE cell. This is intended to provide single sign-on functionality. The authentication process sends an initial challenge to the server, which must respond with the correct response. An authentication trailer can then be attached to each packet sent to provide a further level of security but the information in this trailer isn t linked to the rest of the message contents so data within the message body can be changed without the authentication being effected. Some implementations of DCE middleware (i.e. CORBA) can use SSL transport, thus providing encrypted transport and a good level of physical layer security. Others (i.e. DCOM) rely on the challenge protocol to authenticate connections but provide no encryption and send data packets in the clear. Web services may utilize a higher level of security than DCE based middleware systems. For instance a connection can be made using Secure Socket Layer (SSL) or secure http (HTTPS) which encrypts the data stream between the client and the service using public key encryption. Whilst it may be possible to inject faults into DCE based distributed systems with weak security, at the network packet level, faults must be injected into web service middleware before authentication and encryption takes place. If this is not done the packets will be rejected by the receiving host as security attacks and will therefore not test the intended fault class. 2.5 Timing and Object Lifecycle DCE based systems have a very simple concept of the life cycle of an object. In simplistic terms an object is created, then exists on a server until the utilizing client releases it, and then it is garbage collected. A keep-alive (or ping) mechanism is implemented to check for objects being destroyed early by host crashes and other unforeseen events. Since DCE based systems are intended to run over LANs with reasonably fast response times, packet time-outs are equivalently short. Stateless web services have a different concept of life cycle. When a request is made to a web service a handler context is created which services the request. The handler context may be created from scratch or may be allocated by some optimizing technique, i.e. from a thread pool. This handler context will execute the required code using a single memory context, retaining the memory context for use with the next handler context. Furthermore web services are designed to run over Internet connections. Because of this the timing constraints are proportionally larger for SOAP based systems to allow for greater transmission times. Since web services use far larger timing constraints than a DCE based system, this must also be incorporated into the fault model. The differences in stateful and stateless operation must also be taken into account. 2.6 Summary of Differences In conclusion the major differences between DCE based middleware systems and web service middleware are: 1) more descriptive and generally available definition language, 2) XML message format, 3) encryption, and 4) timing and stateless behaviour. 3 Dependability Assessment Method System dependability can be assessed using either model-based or measurement-based techniques [3]. Since modelling can only make predictions of the dependability of a system we decided to concentrate our efforts on developing a measurement technique that can provide actual metrics for a complete middleware system. Of the two main techniques for measurement-based assessment the observation of errors and failures in large sets of logs [10] would not 1) exercise seldom-used pathways within the code and 2) consume large amounts of time to achieve. It was felt that the deliberate insertion of faults would yield data much faster whilst exercising seldomused pathways within the code. There has been some research done on testing classical distributed systems via fault injection [3]. In Section 2 we noted there are a number of differences between DCE based middleware and web service middleware. This research will ascertain if the research given in [3] can be used as a basis for creating a test method for web service middleware with appropriate additions and modifications. The aim of our test method is to evaluate the dependability of web service interface method calls and the dependability of web service middleware as a whole. We are therefore not concerned with testing the operation of either client applications or services installed on servers. We only expect these applications to be fault tolerant to the degree required to execute our test scripts without user intervention. For the purposes of this test method we will consider the following to be part of the web service middleware: SOAP API, Web Servers, Machine Environment (i.e. the OS). 3.1 Testing Techniques There are a number of techniques available for performing fault injection and a good summary of these is given in [3]. Of these techniques we have decided to base our initial experiments on network-level fault injection for the following reasons: 1) it is a common factor in the design of both client and server software; 2) because of the heterogeneous implementation language nature of web service software it is simple to implement; 3) the protocol packets can be modified to simulate a large number of fault classes (i.e. transport layer failure, API parameter faults, etc). Our method will consider a variation of network level fault injection as a means of determining system dependability. Although we intend to inject faults into network packets we can t do this directly because of the problems of altering encrypted/signed packets after they have been constructed. The purpose of signing a packet is 1) to identify the source of the packet and 2) to ensure that the packet isn t intercepted and tampered with in transit. Since this is effectively what we would do to inject a fault, this would be discarded by the receiving transport layer and would consequently not relay the fault to the desired destination and test the desired area. Encryption is concerned with ensuring that the packet cannot be read and tampered with whilst in transit. Consequently the packet would be unreadable once it had been encrypted so anything other than injecting random faults into the packet would be impossible, and thus would not allow us the fine level of packet manipulation that we require. We therefore propose to inject the faults at the API boundary between the application and the top of the protocol stack, this being the lowest, easily accessible point to inject faults before any encryption and signing has taken place. This will overcome these two problems allowing us the level of control that we require. 3.2 Fault Model The types of fault that can affect a web service can be classified as follows: 1) Physical : effecting memory or processor registers, 2) Software : both programming errors and design errors, (these can occur at either the application level or within the system boundary but we will only consider errors within the system boundary in this experiment), 3) Resource-management faults: such as memory leakage and exhaustion of resource such as file descriptors, 4) Communication faults: such as message deletion, duplication, reordering or corruption, (whilst in traditional distributed systems this class of errors is widely assumed to not have a large effect on middleware, since this is usually built on a reliable transport over a LAN, web services runs over WANs that may be more unreliable that LAN based systems, especially in message delivery times) and 5) Life-cycle faults: such as premature object destruction and delayed asynchronous responses. Our research will concentrate on communication faults implemented via network level fault injection. This will allow us not only to inject network level faults but also allow us to create a framework that will allow us to simulate faults injected at the API level via modifying SOAP message parameters. 3.3 Failure Modes of a Web Service Here we will discuss the ways in which a web service can fail and the effects of each failure on the system as a whole: 1) crash of a service instance, 2) crash of a hosting web server, 3) hang of a service, 4) corruption of data into middleware, 5) corruption of data out of middleware, 6) duplication of messages, 7) omission of messages, and 8) delay of messages. The effect of each of these modes will depend on the fault tolerance of the system as a whole. Middleware should be able to detect and reject any corrupted data given to it and raise appropriate error responses. This is also true for duplication and omission of messages. The fault injector framework detailed in this paper can detect these states via monitoring the SOAP message flow between various elements of the system. Crashes of services/hosting environments should be detected via time-out mechanisms. For this experiment the fault injector framework has no means of checking for this. It will be addressed in later research. More problematic is an operation that corrupts data leaving the middleware. When corrupt data is passed from one middleware layer to another (across a network boundary) this should be handled but when corrupt data is passed up to an application, a mechanism must be in place in the application to deal with this. The fault injector can detect this via monitoring the SOAP message exchange and detecting the invalid data being returned to the application. Another problematic area is that of a service hang. Whilst this may superficially appear as a service crash it is indicative of corruption in the hosting environment. Since it may present the same symptoms to the application level it will be harder to detect. Differentiating between a service hang and a server crash will be left for future research. Finally, delayed messages may cause errors due to service life span issues. The middleware should present relevant error conditions to the application for delayed messages. The application layer must ultimately handle these. The fault injector framework can handle this by delaying request/response packets. 4 Fault Injection Design The fault injector will consist of three elements: 1) the fault injector framework; 2) hooks into the SOAP API to pass SOAP messages through the fault injector; and 3) a user script to inject faults into the message stream. It is envisaged that future research will enhance the test infrastructure and extend the areas tested. 4.1 Fault Injector Framework Since SOAP messages are encoded in an XML based format, each message will have to be parsed and re- emitted to inject a faul
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!