![](bg2.png)
2 SOFTWARE IMPLEMENTED
FAULT INJECTION INTO
WEB-SERVICES
The goal of software implemented fault injection
(SWIFI) is to ensure robustness testing, as it has been
mentioned in the introduction of this paper. Accord-
ing to (Crnkovic, 2002, p. 198), the fault injection into
a software component means to artificially corrupt a
function of this component, input data consumed by
the component, or output data produced by the com-
ponent and sent to its successors, to observe how the
component, the successors, or the whole system be-
haves. To perform this tasks, a fault injection tool has
to inject one or more faults into a software component
under test and to help to analyse the consequences of
potential failures. By simulating the faults in various
software components, we determine whether or not
their failures can be tolerated.
According to (Hsueh et al., 1997), SWIFI tech-
niques can be classified into two types, compile-time
injection and run-time injection. In the first technique,
a source code is modified to inject simulated faults
into a software component in its compile-time. In the
second technique, the software component’s function-
ality or data are modified in its run-time.
The compile-time injection requires availability of
the source code of a software component provided by
its developers or obtained by its disassembling. This
technique does not require any modifications of the
component’s run-time environment, and therefore, it
is applicable especially in the case of in-house de-
veloped software components deployed into different
uncontrollable environments. The compile-time in-
jection into web-services with available source codes
can be done by common SWIFI tools without any
specialisation to web-service technologies.
During the run-time injection, a software compo-
nent is executed as a “black-box” in a special run-
time environment without need of any modifications
or recompilation of the component’s source code. The
run-time environment enables a tester to modify the
component’s control-flow and internal memory (inva-
sive testing) as well as input and output data trans-
mitted via the component’s interfaces (non-invasive
testing). In the case of the run-time injection into a
web-service, a run-time modification of the service’s
control-flow or its internal memory does not require
any knowledge of a web-service technology contrary
to a modification of data transmitted via the service’s
interfaces, which are technology dependent. For the
first type of modifications, common SWIFI tools can
be used while the second type of modifications re-
quire SWIFI tools specialised for web-services.
The SWIFI tools for the run-time injection into
web-services usually act as HTTP proxies encapsulat-
ing web-services under test, or they can be integrated
into web-servers providing run-time environments for
the web-services (i.e. service containers).
2.1 SWIFI Tools for Web-services
This section describes the state of the art for the
SWIFI tools specialised for (non-invasive) run-time
fault injection into web-services. In addition to
the specialised tools, also SWIFI tools providing
network-level fault injection, such as DOCTOR (Han
et al., 1993) or ORCHESTRA (Dawson et al., 1996),
can be used for the fault injection into web-services to
corrupt the services’ messages without understanding
their content, i.e. a particular web-service technology.
WS-FIT (Looker et al., 2007) is a tool implement-
ing targeted perturbation of web-services’ RPC pa-
rameters as well as generic network-level fault in-
jection, which can be applied to a range of other
RPC-based middlewares, such as DCE, DCOM, and
CORBA. To enable the run-time fault injection into
web-services, WS-FIT requires to insert a hook code
into a SOAP stack of web-servers providing run-
time environments for the web-services to capture
SOAP messages. A reference implementation of
WS-FIT includes its integration into service contain-
ers of Apache Jakarta Tomcat web-servers versions 4
and 5. The implementation of WS-FIT tool is not
publicly available.
wsrbench (Laranjeiro et al., 2008) is a publicly
available on-line tool for robustness testing of SOAP-
based web-services represented by their WSDL de-
scriptions. The tool acts as a web-service client which
automatically generates SOAP requests according to
a given test-case specification (e.g. to call a web-
service with parameters outside a given domain, etc.).
This approach allows to test only single services, but
not service compositions. Faults also cannot be in-
jected outside parameters of a web-service’s opera-
tions, e.g. to test a corruption of message headers.
WSInject (Valenti et al., 2010) is a fault injection
tool for testing single and composed web-services.
It allows to inject both communication and interface
faults, i.e. to simulate a network-level malfunction as
well as wrong service calls which do not match their
descriptions. The tool acts as a HTTP proxy inject-
ing faults into passing SOAP messages while trans-
mitting non-SOAP HTTP messages without modifi-
cation. WSInject is able to inject faults into service
compositions, but it is not applicable to web-services
using non-SOAP technologies (e.g. RESTful web-
services).
ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems
378