Testing Web Services through Transactional Patterns

Paulo Roberto Nunes

Universidade de So Paulo
So Paulo, Brazil
prnunes@ime.usp.br
Ana Cristina Vieira de Melo
Universidade de So Paulo
So Paulo, Brazil
acvm@ime.usp.br
ABSTRACT
Software technology has become essential since it is available
in most places. Powered by Internet, nowadays, information
quickly ows throw systems. Web services provide a stan-
dard way to meet these objectives, as they use common com-
munication pattern like XML and HTTP. The use of Web
services brings many benets. On the other hand, it also
brings some issues about reliability, availability and other
non functional problems. Transactional patterns are an al-
ternative to outline such problems. This paper presents an
eective way to certicate the correct use of those patterns
by applying perturbation and mutation testing techniques.
As a result, it is shown which of techniques are applicable.
1. INTRODUCTION
The integration between applications is increasingly
present. With the need for information and as new de-
mands arrive, service-oriented architectures gain evidence,
with Web Services, software designed to provide machine to
machine interoperability over a network [1]. Web Services
are means of requesting information through a network and
whose response is requested and informed in XML (extended
markup language) [1]. Today, they represent a technology-
based components and widely used to implement solutions
and systems [2].
The concept of making available dierent services allows
a scenario to be created. In such scenario, Internet plays a
data repository, where information and services can be used
anywhere in the world [3]. This environment has improved
interoperability, greater dynamism and exibility, especially
if compared to other platforms, such as Common Object Re-
quest Broker Architecture (Corba) [4]. However, it signi-
cantly aects non-functional attributes, eg reliability, avail-
ability, security, and others [5, 6]. In some scenarios with
the highest criticality, condence in a Web Service becomes
an important factor [6].
In order to solve this limitation, academic community and
even industry have spent a great eort to develop models
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for prot or commercial advantage and that copies
bear this notice and the full citation on the rst page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specic
permission and/or a fee.
SAC12 March 25-29, 2012, Riva del Garda, Italy.
Copyright 2011 ACM 978-1-4503-0857-1/12/03 ...$10.00.
focused on Quality of Service, specically Web Services[7],
and study alternatives to the problem, aiming reliability of
the services oered by them [8]. The approach diers from
the denition of standards towards development of tests to
ensure adequate coverage.
Many standards have been created with the objective of
establishing methods for Web Services compositions and
their behavior. The execution is correct if it reaches the
goal, or fail if the requirements are not met. When execu-
tions occur according to a predetermined pattern, behavior
of composite services is more predictable [9].
Another way to get a reliable service is by performing tests
to ensure the proper functioning of the whole service. When
a battery of tests is performed, the fundamental objective is
to evaluate if the service responds according to requirements,
whether functional or non-functional. However testing is
an expensive and dicult task, more specically to Web
Services, due to their peculiarities [10]. Testing techniques
applied to other paradigms such as object orientation and
procedural, are also generally applied to Web Services. But,
there are several specic characteristics that allow a better
exploitation of these techniques [11].
Among the current challenges is the task of making more
ecient the Web Services test activity, with the primary
purpose of increasing reliability. There is a lot of tool to
support non-functional testing [10, 11].
The objective of this study is to identify test requirements
to validate the suitability of the service and the applica-
tion according to a set of standards to ensure greater re-
liability of the system. In Section 2 are presented related
works. Section 3 highlights Transactional Web Services con-
cepts. Then, Section 4 presents an overview of Web Services
testing. Section 5 shows aspects about how Transactional
Web Services are compound. Section 6 discusses criteria
for Transactional Web Services Composition, illustrated by
Case studies in Section 7. Finally, Section 8 presents the
nal remarks.
2. RELATED WORK
Researches have addressed issues about availability and
reliability of Web Services[12]. Among the initiatives, we
can mention those that seek to ensure quality by setting
standards. On the other hand, there are other initiatives
that verify if the quality exists or not, through tests [13].
2.1 Pattern denition
The standardization of communication between services
contributes to interoperability, facilitating the execution of
their duties. Interoperability is the ability of multiple com-
ponents work together, exchanging information in a well-
dened process [14].
In his research, Saha describes a technique to ensure
greater reliability of sent data [15], based on fault-tolerant
algorithms. Another Sahas work focuses mainly at service
availability [16], through developing a reliable and exible
model.
Erradi et al. suggest the creation of a framework, MASC
(Manageable and Adaptive Service Composition), mainly
based on policies that govern failures management [17].
This is a pattern intercepts operations normally performed,
adding an extra layer of political architecture, allowing to
detect and treat a lot of failure types.
Bhiri et al. present the creation of a standard that consid-
ers the systems ow, keeping guarantees oered by trans-
actional methods [9]. Some factors may aect dependen-
cies between the requesting and requested services: De-
pendence and Activation Status Activation; Addiction Al-
ternative and Alternative condition; Dependence Condition
Abortion and Miscarriage, and Condition Dependence Com-
pensation and Compensation; Dependence Cancellation and
cancellation policy. Based on these items, denitions of con-
trol ow and ows of transactions were identied in order to
dene their own standards for such transactions.
Wen et al. also focus on the analysis of transactions ap-
plied to Web Services, but using BPEL (Business Process
Execution Language). It was developed a tool for validate
transactional properties in compositions of Web Services[18].
Out of the studied solutions, those involving specications
aimed at modeling transactions. Other solutions end up
helping more developers in the task of improving reliability
of web services facing problems such as unavailability, data
loss and security.
2.2 Web Services testing
Testing represents a key role in assessing systems. De-
spite of all studies have been conducted in research of Web
Services quality, it is necessary highlight the fact that some
requirements have been implemented [19].
Li et al. present a method of generating test cases from the
combination of features of WSDL and knowledge of the user
[20]. They present a tool called Gen-WSTD implementing
the dened method. Their tool allows users to customize
data types and select a specic rule for each type.
Out and Xu propose an approach in which SOAP mes-
sages are captured during the communication between ser-
vices and, based on them, test cases are generated by in-
serting the message failures [21]. These test cases evaluate
the behavior of the service in the presence of invalid mes-
sages. Also evaluating the behavior of an invalid data ser-
vices, Laranjeiro et al. present a tool called wsrbench
1
to
assess the robustness of a given Web Service [22].
In the research of Paradkar et al., is evaluated a test case
generation model [23]. The proposal presents a method for
generating test data based on fault models, in order to use
them to evaluate semantic web service, which are dened by
inputs, outputs, preconditions and eects - IOPE (Input,
Output, Preconditions and Eects).
Wombacher et al. dene a process for review BPEL speci-
cation and transformation in DFA [24]. Although the main
objective of the work is the facilitation of service discovery
1
Available at http://wsrbench.dei.uc.pt
in catalogs, it is possible to evaluate scenarios for testing,
considering variables such as transactional and conditions.
Sowmya and Ramsokul present a framework that veries
the appropriateness of implementing protocols Web Service
with the specications [25]. With the use of an ASEHA
(Asynchronous Extended Hierarchical Automata) used to
model functional aspects of the protocol, it is possible to
evaluate dierent transactional characteristics, for example,
atomicity. The Framework captures SOAP messages sent by
the service and confronts the implementation to its speci-
cation.
The need for tests is evident. Web Services present new
challenges and require further study, particularly on issues
related to the application of standards. This paper focuses
interoperability testing.
3. TRANSACTIONAL WEB SERVICES
3.1 Web Services
Web applications gained prominence in the world of infor-
mation technology and became a major mean of communica-
tion between suppliers and their customers. As technology
advances, applications become more complex and dynamic,
making e-business enter a new system development era[26].
In a service-oriented architecture (SOA) there is a Ser-
vice Provider, available through a communication proto-
col, Service Requisitor (also called a client or service con-
sumer) that uses the service and a Services Repository.
The repository contains the list of available services as well
as descriptions of their use, often fed by the various existing
providers.
The provider creates a WSDL (Web Services Description
Language)
2
from a specic service, detailing the interface:
operations performed by him; the inputs and outputs and;
its restrictions. Once created, the description is available
in the repository so that customers can use the service.
There are several of these repositories available on the Inter-
net, whose main purpose is to provide necessary information
about the various public services such as site access. Many
of these repositories provide some search criteria (for exam-
ple, by category), to facilitate access by customers.
For eective communication client-server, each client ap-
plication implements a boundary, which is responsible for
exchange of messages between client application and avail-
able service, following the specications of how to send and
receive information (for instance, using SOAP - Simple Ob-
ject Access Protocol
3
). For publication services, dynamic
queries and invocations through the Web [27], there is a
UDDI (Universal Description, Discovery and Integration)
standard proposed by OASIS
4
.
3.2 Transactional Web Services
According to Bhiri et al. [9], a Transactional Web Service
is a Web Service with special attributes, such as [28, 18]:
retriable: a service is retriable if within a nite tries it
will be concluded once;
compensatable: a service is compensatable if there are
compensation policies to undo what it has done;
2
W3C Web Services Description Language (WSDL) 1.1
3
W3C SOAP Version 1.2
4
Available at http://uddi.org/pubs/uddi_v3.htm
pivot: a service is a pivot if, once completed, it cannot
be undone.
Transactional Web Services can hold not just one of all
above properties, but a combined set of them, as long as
they keep a consistent combination. For instance, consis-
tent Transactional Web Services can be either retriable or
compensatable or pivot or both retriable and compen-
satable or both retriable and pivot.
In a system, a transaction can be formed by one or more
transition states. In a composition of Transactional Web
Services, a transaction allows combine Web Service transi-
tions, in order to keep whole system consistency. In other
words, the set of state and transitions depends on transac-
tional properties. Each service must have the states Initial,
aborted, active, canceled, failed, completed and the tran-
sitions abort(), activate(), cancel(), fail(), complete() [29].
Retriable and Compensatable Web Services has retry() and
compensate() transitions in addition, respectively. A sub-
set of such transitions describes Transactional Web Service
inner behavior (complete(), fail(), retry()), being named as
Internal Transitions. All other transitions trigger other Web
Services, thus, they are named External Transitions.
Definition 1. Transactional Web Services transi-
tions and States [29]
Possible Transactional Web Service states, their Internal
and External transitions are dened as following:
Ti = |complete(), fail(), retry() a set of Web Service
Internal Transitions;
Te = |abort(), activate(), cancel(), compensate() a
set of Web Service External Transitions; and
Sts = |Initial, aborted, active, cancelled, failed,
completed, compensated a set of Web Serviceinternal
states;
Definition 2. Transactional Web Service A Trans-
actional Web Service TWS(s
i
) is dened by the tuple
|Initial(s
i
), Ti(s
i
), Te(s
i
), Sts(s
i
), Bi, Be where,
Initial(s
i
) represents the initial state of s
i
;
Ti(s
i
) Ti represents a set of s
i
s internal transi-
tions;
Te(s
i
) Te represents a set of s
i
s external transi-
tions, started from s
i
;
Te
1
(s
i
) Te represents a set of s
i
s external transi-
tions, nishing at s
i
;
Sts(s
i
) Sts represents a set of s
i
s internal states;
Bi(s
i
) : Sts(s
i
) Ti(s
i
) Sts(s
i
) represents the re-
lation between internal transitions and s
i
s internal
states;
Be(s
i
) : Sts(s
i
) Te(s
i
) Sts(s
j
) represents the rela-
tion between external transitions started in s
i
and s
j
s
internal states [ j ,= i;
Be
1
(s
i
) : Sts(s
j
) Te
1
(s
i
) Sts(s
i
) represents the
relation between external transitions ending in s
i
and
s
j
[ j ,= i.
TWS denotes a innite set of all Transactional Web Ser-
vices TWS(s
i
).
Both type of transitions, internals and externals, allow
Web Services communication over messages exchange.
Definition 3. Given a message m
ij
M sent from a
service s
i
to a service s
j
, K
ij
= |c
1
, c
2
, ..., c
n
is the set of
all elds in m
ij
.
M represents a innite set of all messages m.
Proposition 1. Let s
i
and s
j
Transactional Web Ser-
vices. If te is a transition from s
i
to s
j
(whose sent message
is m
ij
), then te Te(s
i
) te Te
1
(s
j
) (s
i
, te, s
j
)
Be(s
i
)
Transactional Web Service behavior is given by all pos-
sible Transactional Web Service transition executions, in-
ternal and external. Its remarkable that inner and outer
transactional behavior can be set apart. In the same way,
it can be observed that all transitions and available states
for each Transactional Web Service depend on their trans-
actional properties. For instance, a Transactional Web Ser-
vice with pivot property nor cannot have a compensate()
method, neither a compensated state.
4. TESTING WEB SERVICES
Current web service testing approaches are not sucient
as they are more heterogeneous than components and ap-
plications web. Web Services may also be written in sev-
eral languages and they can be used for various operating
systems and run in containers of dierent application [30].
For web services, there is minimal control between provider,
consumer, and integrator, which directly aect the cost of
testing and QoS (Quality of Service) [31].
Thus, it is necessary to perform the test suite coverage in
key points, specically to Web Services, functional and non-
functional. Among the functional, if the service provides
appropriate responses in accordance with the specications
provided. But among the non-functional, should be evalu-
ated: the ability to respond eciently to a given number of
requests (performance), aspects of authorization, encryption
and protection against attacks (security); and adherence to
a particular set of pre established (interoperability). This
work approaches evaluation of interoperability testing.
After extensive research on the issues discussed today,
there is few references in the literature on specic Web Ser-
vices testing criteria [32, 14]. Some initiatives analyzed cur-
rent situation in order to assess Web Services issues [33, 14].
Since it is a distributed environment, some researchers argue
tests should be dierent from conventional [34, 35].
Analyzing a web service and comparing it with current
paradigms, especially object-oriented, we can classify testing
criteria into two types: criteria for functional testing, and
non-functional [14]. Many of the criteria applied to this
paradigm does not apply to service [12].
Considering aspects enable one to see service as a func-
tion available for remote use, you can use criteria that guide
unit tests assessing their functional characteristics. Depend-
ing on the implementation approach, the test criteria can be
varied. Blanco et al. [36] suggest adopting criteria for cov-
erage of state transitions, due to the model adopted. For
testing non-functional, many quality-related criteria can be
dened [37]. Aspects such as availability, reliability, secu-
rity and robustness, can be specied by SLA (Service Level
Agreement) and security requirements.
To make sure that the process works as expected, a set of
tests is executed to identify gaps and thereby improve the
nal product. In a process composed of services, the ideal is
that all of them have quality and their integration does not
compromise the composition.
There are perturbation techniques to test reliability of
Transactional Web Services compositions, and evaluate
them in isolation. Through these techniques, it is able to
explore test conditions and thus enhance the detection of
system problems. The set of techniques used by Melo and
Silveira [38] allows the automatic creation of test cases, using
as the basis submitted messages from one service to another.
Definition 4. Let PertDados be a set of all data pertur-
bation techniques, PertCom be a set of all communication
perturbation, and MutDados be set of all data mutation,
used by Melo and Silveira [38]. Thus:
PertDados = |string, boolean, numeric, data, bi-
nary, enumeration, fractionDigits, length, maxExclu-
sive, maxInclusive, maxLength, minExclusive, minIn-
clusive, minLength, pattern, totalDigits, whiteSpace
PertCom = |minOcurrs, maxOcurres, choice, any
element
MutDados = |divide, Multiply, Negative, Absolute,
Exchange, Unauthorized, Null, Incomplete, Inversion,
ValueInversion, Mod Len, Space
TEC = PertDados PertCom MutDados
Definition 5. Let s
i
be a initial state, s
j
nal state,
m
ij
a message sent from s
i
to s
j
, cT (m
ij
) is a set of
all test case generated based on m
ij
. Thus:
cT (m
ij
) = TT(PertDados, m
ij
)
Tc(PertCom, m
ij
) /T(MutDados, m
ij
)
where:
1. TT(pd, m
ij
) is a set of test cases generated according
to data perturbation and pd PertDados;
2. Tc(pc, m
ij
) is a set of test cases generated according
to communication perturbation and pc PertCom;
3. /T(md, m
ij
)is a set of test cases generated according
to data mutation and md MutDados;
m
ij
is used as a seed to originate test cases
TT(PertDados, m
ij
), Tc(PertCom, m
ij
) e
/T(MutDados, m
ij
). The validation of Transac-
tional Web Services belonging to the system through the
validation can occur in isolation, as well as verication
of the preconditions of each, as well as validation of the
result. Considering the ideal scenario, the execution with
valid data, is set for all services following a certain order,
exchanging messages with each other and returning the
system response in the nal state. However, in normal
use, there may be violation of preconditions or even the
sequence of use. In the example of travel system, it could be
a problem in communication between the airline reservation
systems, hotel reservation and payment. To avoid problems
with the payment system, it needs to make appropriate
treatments, forecasting situations where the data is lost, is
corrupted, or simply ignored.
Therefore, it is necessary to validate the entire process,
testing such situations, simulating scenarios in which losses
occur (or accidental changes) of data. You must also assess
whether the mounted ow and in which order the services
are vulnerable to problems in processing. For this validation
can be performed, you can create some test scenarios that
allow exploring situations:
1. Transactional Web Services isolated validation:
perturbation and mutation techniques are used for
Transactional Web Services validation;
2. Precondition and sequence validation: process
sequence is kept, applying perturbation in messages
(respecting preconditions);
3. sequence violation: changing the process sequence
and;
4. preconditions violation: process sequence is kept,
applying perturbation in messages, but violating pre-
conditions.
In the following sections possible situations are presented
in the composition of Transactional Web Services, highlight-
ing what alternatives can be identied to validate them sep-
arately and to validate that systems formed through a com-
bination of them meet the expected properties.
4.1 Isolated testing systematic
Web application, as isolated Web Services, needs a re-
markable reliability. The GenAutoWS tool uses perturba-
tion testing techniques and generates a huge test case set.
Melo and Silveira [38] show two ways to apply perturbation
on communication: RPC and Document, used according to
the established pattern. RPC way is designed for test the
services use of data, meanwhile, Document way allows tests
related to relationship and restriction.
Web Services have specic characteristics. As seen before,
GenAutoWS tool can automatically generate a test set to
Web Services. To generate tests that can validate and pro-
cess system transactions, the message exchanged between
services can be used as seed generating.
From unitys point of view, using perturbation techniques
(based on perturbation data types and restrictions), defects
are sought by performing tests of equivalence classes. The
data perturbation modies values through the use of infor-
mation on their type. These types are determined by the
XML Schema of the message itself. With the technique of
boundary value analysis, test cases can be prepared accord-
ing to the primitive type of entry. Similarly, for disturbances
in communication, taking the restrictions based on XML re-
lationships, it is possible validate Transactional Web Ser-
vicesingly. The mutation, another useful technique for vali-
dating isolated Transactional Web Services, is performed by
operators of mutation. These operators are applied in the
original message, increasing the chance of an error is iden-
tied, if any. As for the other techniques, the mutation is
applied to individual tests. In summary, the test set formed
by applying the three kinds of techniques, perturbation data,
communication and changing data is the following:
cT (m
ij
) = TT(pd, m
ij
)Tc(pc, m
ij
)/T(md, m
ij
).
Despite of having adequate coverage when they test them-
selves Web Services as units, in a composition of them (and
when it involves transactions), the set of tests is not su-
cient.
5. COMPOSING TRANSACTIONAL WEB
SERVICES
Web application can represent a composition of existing
Web Services. Such compositions are developed following
transactional patterns. When a system is built based on
two or more Web Services, it can be seen as a process, made
of a set of Web Services, being one initial, followed by its
transitions. There are precondition that must be true in
order to execute each Web Service. Transaction ow of the
Transactional Web Service Composition consists of a set of
external transitions between services. Each transition has
its own set of preconditions that must be met for transitions
from one state to another, or simply to invoke a particular
service. Consequently, there is a set of preconditions that
need to be respected to run properly.
All Web Service preconditions are a set of expected situ-
ations, without which there is no guarantee that the service
will operate as specied.
Definition 6. Service preconditions
Let Prop be a property, Prop is a function dening for
each transition of an external Transactional Web Service to
a property that it must ensure in order to be activated.
Prec : Te TWS Prop. s
i
, te [ s
i
TWS te
Te
1
(s
i
) Prec(te, s
i
) = Prop.
PROP denotes the innite set of all the properties that
Transactional Web Servicesshould ensure in order to be ac-
tivated.
Definition 7. Transactional Composite Web Ser-
vices [29]
A Transactional Composite Web Service, tcs
( Transactional Composite Web Service), is dened by
tcs = (tws TWS, Prec), where:
tws denotes the set of Transactional Web Services
compose the service (tws = |s
1
, ..., s
n
, s
i
is a Trans-
actional Web Service component of tcs)
TCS denotes a set of all Transactional Composite Web
Services. As a tcs can be composed by many Transactional
Web Services, their states are represented by: s.e), where
s tws and e Sts(s). Similarly, the transitions are also
represented with the identication of services that generate:
s.t()), where s tws and t Te(s).
Preconditions expresses, in form of dependency, the rela-
tionship between services, showing how they can be com-
bined. Certain services can inuence the behavior of others.
There are dependencies for the implementation of essential
services[9].
6. VALIDATING COMPOSITE TRANSAC-
TIONAL WEB SERVICES
6.1 Transaction Patterns
One requirement for having a reliable composition is the
non-existence of inconsistencies in control ow. To ensure
consistency between the transition and several calls between
services, Bhiri em et al. suggest using a context-free gram-
mar,for the propose of evaluate the quality of the specica-
tion of the connections[9].
As a result, transactional ow has some attributes:
each service is either retriable or pivot;
each compensate destine service must be compensable;
each compensate origin service must be retriable. It
also is valid for cancel or alternative services.
For the composition may be formed, it is necessary for a
given Transactional Web Service follow these characteristics.
Moreover, it is essential that appropriate transitions are car-
ried out in adequate conditions for their execution and that
the ow of control of their composition is consistent and
standardized.
6.1.1 Dependencies and Transition Conditions
As can be seen previously, a given state can contain pre-
conditions, which depend on the transitions to be performed.
Thus, for each transition occurs according to established
standards, service preconditions must be respected. In the
context of preconditions, execution dependencies end up ref-
erencing the relationship between services. Therefore, it is
necessary to describe them more accurately.
Definition 8. Property: Service Dependency
Let s
i
and s
j
be two Transactional Web Services,
s
i
.e [ and Sts(s
i
), s
j
.t
l
() [ t
1
T
1
(s
j
), dep(s
i
.e, s
j
.t
l
())
denes that e needed s
i
.e
k
be its current s
i
state aiming
s
j
.t
l
() transition.
The dependencies are in agreement with the situation.
Altogether, there are ve situations, described as following.
Activation: The set of preconditions for activation of a
service consists of situations that needed to be activated and
that the system remains in a consistent state. In a process
consisting of Transactional Web Services, the rst service to
be done has preconditions that are identical to the whole
process. For services that are not performed initially, the
precondition is that the preceding has been completed suc-
cessfully.
Dependency and Activation Condition: expresses the rela-
tionship that a given service has to be with other res, and
contain the necessary conditions for activation. The acti-
vation dependency, in a transition from s
i
to s
j
can be ex-
pressed as following:
depAtivation(s
i
, s
j
) = dep(s
i
.completed, s
j
.activate())
For s
j
be activated, it is necessary that s
i
is complete and
that its activation triggers the completion s
j
. The message
m
ij
in this case has the function enable s
j
, one can (or
more) eld c K
ij
take the information necessary to per-
form the activation. For example, for the inventory control
system records the sale of a product, it must be held be-
fore the sale of the item, ie, the realization of active service
volume debit;
Alternative: An alternative execution must necessarily
be caused by a failure. This allows the process to keep the
ow without the need to be stopped as there is an alterna-
tive service.
Alternative condition: allows you to dene the alternatives
in case of failure, as well as preconditions for each alterna-
tive is feasible. This allows the implementation of recovery
mechanisms, specifying that the execution of a second ser-
vice is a possible alternative should the primary fail. The
dependence of the alternative service s
i
for the service s
j
exists if the s
i
failure can activate s
j
, expressed as follows:
depAlternativa(s
i
, s
j
) = dep(s
i
.failed, s
j
.activate())
The message m
ij
be the function enable s
j
. She can carry
the information that s
i
has failed, but not necessarily for-
ever. For example, the core service delivery, when clicked,
shows a failure of execution, triggering the invocation of an-
other service delivery. The second need not know the rst
one failed, depending on need.
Abort: originated also from a failure can happen two
dierent scenarios: rst, the failure is simply responsible for
the interruption of the process, the second failure initiates a
cancellation of the service which then aborts the rest, who
therefore aborts the process ;
Abort Condition: allows stop the execution of a particular
service and prevent the system propagates a failure state. In
a transition service from s
i
to s
j
, s
j
is aborted if s
i
fails or
canceled. The relationship can be described as follows:
depAborto(s
i
, s
j
) = dep(s
i
.failed s
i
.cancelled, s
j
.abort())
This feature allows fault propagation from one service to
their successors. One or more elds of the message m
ij
can
report that s
j
must be aborted. For example, the process
of buying a product can be aborted if the low-inventory was
not completed;
Compensation: for this transition, similar to the tran-
sition of abortion, there are two sets of viable preconditions,
arising from a failure that triggers a compensation or, orig-
inated following a series of compensation;
compensate condition: denes a mechanism for recover-
ing from a given state through the implementation of state
compensation. This is by specifying the steps needed to se-
mantically undo what has been done by a particular service,
indicating what must be undone. A transition of compen-
sation, from a service s
i
to a service s
j
, occurs if s
i
fails, or
if the compensation of s
i
shoots compensation of s
j
. This
transaction is dened more specically as follows:
depCompensacao(s
i
, s
j
) =
dep(s
i
.failed, s
j
.compensate())
dep(s
i
.compensate(), s
j
.compensate())
For this situation, the message m
ij
can have in an informa-
tion eld that will trigger compensation of s
j
. For example,
assuming a sale on a particular product, the low inventory
is successful, however, to make the payment, it fails. The
compensation is to reverse the fall in the stock, thus undoing
what had already been done. That is, the failure of payment
triggers the reversal of low inventory.
Cancel: arises from a failure, which triggers a cancel-
lation. In this scenario, the precondition is determined by
failure of the previous service.
Cancel condition: allows you to set rules for cancellation
of certain services. It is similar to the abortion item, with the
dierence that the whole service is canceled. A transition of
cancellation from a service S
i
to s
j
service, occurs if s
i
fails
and triggers the cancellation of s
j
. This relationship can be
described as follows:
depCancelamento(s
i
, s
j
) = dep(s
i
.failed, s
j
.cancel())
The message m
ij
has the task of ring the cancellation
s
j
. Fields of m
ij
may contain information that s
i
has failed
and that this failure resulted in the cancellation of s
j
. For
example, suppose a particular accounting system does not
provide for cancellation, thus preventing a release of com-
pensation is made. In this situation, should the need arise,
the cancellation is made through a credit in another account.
6.1.2 Control Flow patterns and Transitions
In the context of Web Services composition, there are two
levels in the denition of control ows: the internal ow,
in which service performs its own operations according to
need and, the external ow, also known as coordination ow
(or orchestration), which organizes the inputs and outputs
of each Web Service, following a given sequence. The way
that the ow coordination is dened directly inuences the
quality and reliability of the composition [9].
Thus, van der Aalst and van Hee [39] have modeled se-
quence, AND-Split, AND-Join, OR-split, OR-Join, XOR-
Split and XOR-Join, from which, one can set standards for
the control ows and thus determining transactional pat-
terns. Such standards set by Bhiri et al. [9] are based on
models proposed by van der Aalst and van Hee.
A unappropriated construction or improper setting can
cause ow inconsistencies. For example, when an XOR-Split
is followed by an AND-Join: only one of two services, Web
ServicesWS 1 or WS 2, runs; in an AND-Join, it is ex-
pected the return of both. So, it is feasible ensure the con-
sistency of ow through the application of these patterns.
6.2 A systematic for Transactional Composite
Web Servicesreliable test based on trans-
action patterns
Through previously seen techniques, it is possible to ex-
plore test conditions and thus enhance the detection of sys-
tem problems. The set of techniques used by Melo and Sil-
veira [38] allows the automatic creation of test cases, using
as the basis submitted messages from one service to another.
6.2.1 sequence and precondition validation
In the execution of a process, there is a certain order in the
sequence. In this approach, we attempt to identify fault con-
ditions, without the process or result of the preconditions are
violated, acting directly on the messages exchanged. Thus,
situations caused by loss of information, interference prob-
lems in the middle or in the execution of services are simu-
lated. For example, it can happen all the preconditions for
the execution of a particular service are satised, however,
problems in information transmitted. The reliability of the
composition depends on the way such situations are outlined
in the event.
Independently of the types of input data for each service,
the perturbation with limit values apply. This type of dis-
turbance, based on all data types, when applied to specic
elds of the message, allows interfere with the way informa-
tion is transmitted between services.
The disturbance in restricted types, through the facets,
are used to dene valid data and invalid restrictions on
data types. Simulated situations through the operators
fractionDigits, length, maxLength, minLength, totalDigits,
whiteSpace, maxExclusive, maxInclusive, minExclusive and
minInclusive are already covered by disturbance-based limit
values of data type, but can also identify inconsistencies in
the solution. Operators enumeration, pattern to assess the
reliability of a similar service. That is, all the techniques of
perturbation-based facets contributed to this test scenario.
Together with techniques based on primitive types, we
have the set pd = PertDados accounting techniques that
help the generation of test cases. The disturbance of com-
munication enables creation of tests focused on the relation-
ship and constraints on the messages exchanged between
services. It is possible, for example, to simulate situations
of dependency between the services: if a particular service
s
i
needs to receive 3 responses from 3 other services, it is
part of the preconditions for implementation of s
i
the com-
pletion of the three services. If the message there is the 3 an-
swers, even with complete services (pr-condition satised),
the reliability will be compromised. These mutation opera-
tors are applicable: Exchange(c
1
, c
2
); Null(c), Incomplete(c),
Inversion(c), ValueInversion(c) and Mod Len(c).
For instance, assuming a sequence of two Transactional
Web Services s
i
and s
j
, witch external transition is triggered
by s
i
sending a message m
ij
to s
j
. Let s
i
.completed
Prec(te, s
j
). Thus, s
j
needs to be notied that s
i
is at
a completed status. Let c
k
be a eld in m
ij
, where
1 k n and n equals to all eld in m
ij
. The perturba-
tions Exchange, Null, Incomplete, Inversion, ValueInversion
and Mod Len, when applied to c
k
compromise the notica-
tion. Thereby, one can evaluate s
j
reliability, according to
the resultd. All other mutation operators presents no con-
tribution to the reliability evaluationin a precondition and
sequence validation. The complete set of test case is the
following::
cT (m
ij
) = TT(pd, m
ij
) Tc(pc, m
ij
) /T(md, m
ij
)
onde:
pd = PertDados,
pc = PertCom e
md = |Exchange, Null, Incomplete, Inversion, ValueInversion, Mod Len, Space.
6.2.2 Sequence Violation
Perform services discarding the order in which they are as-
signed can cause system problems. Through this approach,
one can evaluate the ability of each service to respond to ad-
verse situations, since it is not being executed in the order
originally proposed. This makes it possible to evaluate all
combinations of performance of the services that comprise
the process. However, the universe of tests becomes very
broad. For a process consisting of n services, we have n!
combinations, all are expensive to run.
Evaluating from the post-conditions of each service in the
context of rape sequence, it is expected that a failure in ex-
ecution, with the exception of services that are independent
of the previous execution of other services, called the initial
services of the process. Since there are no services previ-
ously performed in the ow, it is expected that there are no
failures.
However, for the other services of the process, the ex-
pected result is failure to perform. For this, the trouble is
the n messages services, to perform in isolation, without the
need to run the rest of the sequence in its entirety. That is,
for every s
i
tws, 1 i n, with s
i
is not original, simply
ensure that the process simulated with s
i
as initial failure.
Thus, for this approach, the set of test cases is the same test
isolated, so the application identical to that adopted in the
validation of individual Transactional Web Services. The
complete set of test cases is the following:
cT (m
ij
) = TT(pd, m
ij
)Tc(pc, m
ij
)/T(md, m
ij
)
6.2.3 precondition violations
With the sequence of the process unchanged and with no
disruption in the messages exchanged in compliance with
the preconditions, there is another scenario validation. In
this approach, the aim is to identify problems due to not
predicting certain behaviors in the system. For example, if
a particular precondition is violated, it is expected that the
system fails - it does not, or precondition was wrong, or the
system not treated properly.
By acting in the ow, without changing execution orders,
test cases presented by Melo and Silveira [38], because they
are directly linked to messages, add little to this approach.
That is, for the breach of preconditions, you must also per-
form other test cases. As Web Services are designed to be in-
dependent [40], by assumption, the state of a service is only
knowledge of the other services just by exchanging messages.
activation condition: For the condition of activation,
in a transition from s
i
to s
j
, is necessary for the service s
i
is complete. As in previous situations, the message sent to
s
j
indicates the completion of s
i
. To test this condition, it
is necessary that even s
j
receiving a message, it may not
contain information referring to the completion of s
i
. With-
out interfering in the meaning that the elds may have the
tests that allow this are the disturbances on data types that
deal with empty string, or 0 (which may mean, depending
on the context, the absence of information), as well as the
disturbance whitespace. The disturbances on communica-
tion minOccurs, maxOccurs, choice, and all anyelement also
enable the testing of this scenario, besides the mutation op-
erators Exchange(c
1
, c
2
), Null(c), Incomplete(c) and Space
(c).
For the status of activation, has been a test case of the
activation state s
j
without the state s
i
is completed. The
perturbation of the message between s
i
and s
j
will facilitate
the violation of the precondition.
Thus, applicable test cases in this scenario are as follows:
CT(m
ij
) = PD(pd, m
ij
) PC(pc, m
ij
) MD(md, m
ij
)
onde:
PD(pd, m
ij
) [ pd = |String, Numeric, Binary, WhiteSpace,
PC(pc, m
ij
) [ pc = |minOccurs, maxOccurs, choice, all, anyElement e
MD(md, m
ij
) [ md = |Exchange, Null, Incomplete, Space
Alternative condition: As an alternative, it is neces-
sary that the failure of s
i
triggers s
j
. However, the message
m
ij
contains no information related to the failure of s
i
.
Disturbances in this situation do not contribute in identify-
ing specic failures of this condition. As it is a XOR-Split, a
path does not necessarily knows about the existence of the
other. The perturbation for the Alternative condition does
not directly aect the test scenario. Thus,
PD(|, m
ij
) = PC(|, m
ij
) =
MD(|, m
ij
) = .
Similarly, in the alternative situation there is a test case
that activates state s
j
with state s
i
dierent from failed.
compensation condition: The condition for compensa-
tion is identied in a transition from s
i
to s
j
through the
message sent to s
j
with no information about the s
i
. Be-
cause it is also an XOR-Split, where a path does not neces-
sarily know of the existence of another, nor the disturbance
or the mutations directly aect the test scenario. Thus, the
tests presented in this case do not contribute, ie
PD(|, m
ij
) = ,
PC(|, m
ij
) = and
MD(|, m
ij
) = .
Condi cao de aborto: On the other hand, the conditions
for abortion are related to an abrupt halt in the process, do
not represent the right backdrop for running tests generated
based on perturbations. thus,
PD(|, m
ij
) = ,
PC(|, m
ij
) = and
MD(|, m
ij
) = .
cancellation condition: Finally, in the situation of can-
cellation can be validated through perturbation of operators
Exchange(c
1
, c
2
), Null(c), Incomplete(c), ValueInversion(c)
and Space(c). The disturbances on primitive data types
that deal with empty string, or 0 also contribute to these
tests, as well as restrictions on the disturbance whitespace.
Similar to the activation condition for the cancellation is to
inform relevant data that result from processing the service
of origin, which triggered the cancellation process.
Thus, it has been running a test case that triggers the
cancellation of s
j
with no failure in s
i
.
The set of test cases to the cancellation policy is as follows:
CT(m
ij
) = PD(pd, m
ij
) PC(pc, m
ij
) MD(md, m
ij
)
onde:
PD(pd, m
ij
) [ pd = |String, Numeric, Binary, WhiteSpace,
PC(pc, m
ij
) [ pc = |minOccurs, maxOccurs, choice, all, anyElemente
MD(md, m
ij
) [ md = |Exchange, Null, Incomplete, ValueInversion, Space
7. WEB TRAVEL - A CASE STUDY
To evaluate the criteria studied, it was constructed a
hypothetical scenario, which consists of a system that en-
ables customers to plan their trip using a single interface
to make the hotel reservation, purchase airline tickets, pay-
ment of both the request and delivery. Each service is oered
through Web Services, integrated to the Web Travel System.
By assumption, the client tells his origin, his destination,
departure date and return date. The system then informs
the available hotels and ight schedules that meet chosen
criteria. After selecting the hotel and airline, the system has
the date and time of ight, date, hotel check in and check
out time, room type, total price information and credit card
for delivery of tickets.
Such services are represented by services s
i
: s
1
is a Hotel
service; s
2
is a Flight service; s
3
is a Payment service; s
4
is a Delivery service 1 and; s
5
is a second Delivery service.
Thus:
tws = |s
1
, s
2
, s
3
, s
4
, s
5

As it is a process composed by Web Services, from the rst

data sent through the SOAP message, services communicate
with each other, generating a series of other messages. The
BPEL engine receives the rst message, creates the SOAP
messages that are sent to the service of hotel reservation and
ight booking.
After processing services, the BPEL engine organizes and
prepares answers the call to the next Web Service. The
service on the reservation of hotel rooms responds to the
request, stating that the request data can be properly
charged, The airline reservation service returns an XML
le containing the ight information, so that it can also be
charged,through invocation of the service s
3
. The trans-
mitted message from s
1
to s
3
is m
13
and the transmitted
message from s
2
to s
3
is m
23
.
The payment service can then be invoked. Gathering in-
formation provided at the beginning of the process with the
information received from the Flight reservation and Hotel
reservation services, the invocation message is created.
Similar to previous services, the Web Service payment
processes the request and returns information regarding the
consummation of the transaction. With this information,
the BPEL engine can then combine with other information
and form for the message delivery service s
4
.The message
m
34
is transmitted s
3
for s
4
. The process is conrmed
by the response of the servicewhich is used to compose the
process response.s
5
service is not invoked if the s
4
runs suc-
cessfully and so the message m
35
fails to be generated.
7.1 Techniques and Automatic test case gen-
eration
There are several transactional properties described in the
system that can be veried. Starting with the individual
services, one can evaluate the system units. The sequence
of execution is also subject to assessment, which may be
considered preconditions, especially in three critical points
for the composition: parallel execution of airline booking
services and hotel reservation (AND-SPLIT), the junction
at the time of starting the execution of the payment service
(AND-JOIN) and, to the exclusive delivery service (XOR-
SPLIT).
7.1.1 Test case for isolated services and sequence
validation
For Web Services hotel and the airline s
1
and s
2
, for ser-
vices to be initiated, the tests to be performed are the same
type of tests performed to validate the sequence. The only
restriction is just related to the input data for each service.
In this approach, the execution of validation in the form of
units of the system, tests were performed satisfactorily. Ac-
cording to the test case, the results were as expected - both
for failures as for successes. For example, in value inversions
for the FirstName and LastName are not expected fail-
ures. However, for value inversion of the elds from and
to is expected to be an inconsistency of data presented as
supposedly the date from must be smaller than the data to.
Thus, service returns an error message after running the test
case which reverses the eld values from and to.
For other services, payment and delivery, is expected a
failure as result.
For the evaluation of the sequence, using the techniques
outlined previously and test cases generated by GenAu-
toWSit holds a battery of tests, in order to certify the re-
sults. The tests are performed from the point of view of
unity, evaluating them isolated.
7.2 Preconditions and sequence validation
In addition to unit tests, also called isolated Web Services
tests, it is important to validate the preconditions in the se-
quence shown through the whole process. The critical points
of the process are the AND SPLIT, AND JOIN and XOR
JOIN. The AND SPLIT point starts the parallel execution
of reservation services for hotel and ight reservation. AND
JOIN The point is the junction of the responses and syn-
chronization services for the payment service is triggered.
The point of XOR SPLIT determines the performance of
only a unique service delivery.
For these situations, the approach is to evaluate the reli-
ability of critical points. The execution order and the pre-
conditions remain unchanged. Services s
1
and s
2
are the
rst service of process. There is no restriction that prevents
the execution of each one. The tests performed for evalua-
tion alone is enough. However, subsequent servicing, s
3
, s
4
e s
5
, have the necessary conditions for the tests. All previ-
ously dened test cases are applicable while maintaining the
preconditions and sequencing.
By running the test case that followed the technique Ex-
change, applied to elds FlightNumber and HotelId, it
was expected the system to fail to invoke the service s
3
.
However, a positive response is obtained. The system went
into an inconsistent state by accepting the invocation con-
taining invalid values. There are several ways to correct the
problem. One way to do it is through the implementation of
a somewhat more sophisticated mechanism that allows cer-
tify that the generated response is part of a same request.
For example, when starting the process identier is gener-
ated based on the date and time of commencement. From
this point, the codes have been exchanged between the ser-
vices that handle in its composition.
7.3 Precondition violation
Considering the violation of preconditions, the objective
is to evaluate how the system behaves if the preconditions
are not met. The composition of services s
1
, s
2
, ..., s
5
follow
specic patterns. To validate them, all test case seen in
previous section will be applied.
7.3.1 Flight and Hotel services
In Web Travel System, for Hotel and Flight services s
1
and s
2
, there are no conditions to be activated. If a request
is sent to any of these services which results in an inconsis-
tency, it should be treated by the service itself. For example,
to start a particular seat ight reservation, that seat must
be free. The same goes for a hotel room. But, as the goal
is to evaluate characteristics of transactional Web composi-
tions, these conditions are supposed to be treated properly
in the GUI system. Thus, under the transactional view-
point, there are no preexisting conditions for the activation
of both services.
By the attributes of the system, there is no alternative
services for s
1
and s
2
. In another scenario, you can deploy
services with alternative execution, or to a hotel with com-
fort and has the same availability, or other airlines that oer
other ights on the same date and time of the rst, which
has the same origin and same fate. Both services are not
subject to abortion. The failure of one must necessarily en-
sure that the other was not executed. Thus, there is no
position to abortion.
Regarding the conditions of compensation, there are three
situations: s
1
and s
2
fail not; s
2
and s
1
fail not; both s
1
and
s
2
fail. Note that if both are carried out successfully there is
need for compensation, not characterizing a necessary con-
dition for compensation. In all three situations, there is no
test cases based on change and disruption that contributes
to the identication of aws in this scenario. Finally, the
situation is not part of cancellation of the existing scenar-
ios.
7.3.2 Payment and Delivery services
The payment service s
3
and delivery services s
4
and s
5
several preconditions have to be run correctly. Activation
of the payment service should only occur in case of suc-
cessful execution of the previous (s
1
and s
2
). Activation of
the service delivery s
4
must occur through successful imple-
mentation of service s
3
. Since the activation of the service
delivery s
5
should only occur if the service performed s
3
has
been successful and that s
4
has suered a failure to perform.
The next step is to perform the tests. The results showed
no gaps in services. However, for services s
4
and s
5
were
noticed some unexpected situations in the system. The exe-
cution is exclusive: that is just one of the services should be
run. Running s
5
, even without fault in s
4
, there is a positive
response from the system, and it was expected a message of
inconsistency. That is, the precondition activation s
5
was
broken (it was necessary that s
3
state was successfully com-
pleted and that s
4
was in a state of failure, however, s
5
has
been activated s
3
in completed state successfully and s
4
with
state successfully completed).
Although the problem has been identied through the exe-
cution of test cases suggested by the data perturbation tech-
nique, one can identify the same problem through the exe-
cution of other test cases.
8. FINAL REMARKS
There are several challenges in Web Servicesimplementa-
tion. Many initiatives have emerged to overcome known
problems with the main objective of making the adoption of
Web Services simple and composite systems that they are
reliable. Among the ways to address the problems, are the
adoption of frameworks, usage patterns, transactional pat-
terns, and performing such tests. This research contributes
mainly on issues related to testing Web Services, by propos-
ing criteria that help to identify test cases for specic trans-
actional patterns.
As seen in sections 5 and 6, it was possible to analyze a
broad set of techniques for generating test cases and deter-
mine the coverage when employed in verication and valida-
tion Web Services and their composition. The application
of these techniques proved satisfactory for validation of pre-
conditions.
In addition, the analysis by applying the techniques make
it possible to evaluate thoroughly the characteristics of the
composition, the critical behavior of the system. Thus, al-
though some of the test cases to apply only to Web Services
pure, you can still get valuable information of composition
and how they can be tested.
Perturbation techniques and mutation presented by Melo
and Silveira [38] implemented in GenAutoWS have been al-
ready evaluated for applicability testing Web Services iso-
lated. When analyzing a system more fully, or more pre-
cisely integration points, there has been little information
about the eectiveness of the tests and what the best ap-
proach. Simply apply the test cases presented in a ad hoc
way can result in the desired situation.
The adoption of standards for composition Web Services
is an alternative to improve the interoperability of web sys-
tems. Transactional patterns are useful in building processes
based on such compositions. This study used as the applica-
tion of transactional patterns that let you combine Web Ser-
vices with specic characteristics, such as having the ability
to re-run, have conditions of compensation, among others.
Moreover, they are taken as a basis the set of techniques
of mutation and perturbation test data applicable to Web
Services. Based on the transactional characteristics and also
the set of test cases generated from the mutation and per-
turbation techniques, this paper seeks to identify certain
conditions to identify problems eectively in the composi-
tion of services, validate the condition of your use and as
ow of information can aect the behavior of the service as
a whole.
From the analysis of each technique as well as the anal-
ysis of the conditions of the standards, you get coverage
of techniques for each situation identied in the applica-
tion of transactional patterns. Such coverage can be veried
through the application in a case study, whose objective is
to seek to understand and demonstrate how to apply and
how is it possible to identify problems in the composition of
Web Services to the development of a process.
There is also a huge range of topics and issues to be ad-
dressed, all related to the topic discussed in this work. The
scope of the analysis was specic to transactional patterns
and also covers how mutation based tests and data pertur-
bation can contribute to the reliability of composition Web
Services. Other patterns, however, can be assessed, for ex-
ample security, exceptional treatment, among others. Sim-
ilarly, one can evaluate other testing techniques that guide
how the reliability should be obtained. All these tests con-
tribute to a clear denition of criteria, not just for testing
Web Services, but also for their own composition.
The denition of communication between Web Services
other item is likely to deepen. In this work we considered
the exchange of messages targeted for analysis. It is possible
to identify other means of extracting test conditions, thus
rening the systematic validation of service composition.
Acknowledgment
The authors would like to thank... more thanks here
9. REFERENCES
[1] W3C, The world wide web consortium (w3c), 2010,
disponvel em http://www.w3.org/, acessado em
fevereiro de 2010.
[2] H.-G. Gross, Component-based Software Testing With
Uml. SpringerVerlag, 2004.
[3] C. Ferris and J. Farrell, What are web services?
Commun. ACM, vol. 46, no. 6, p. 31, 2003.
[4] G. Alonso, F. Casati, H. Kuno, and V. Machiraju,
Web Services - Concepts, Architectures and
Applications, 1st ed. Springer, October 2003.
[Online]. Available:
http://www.worldcat.org/isbn/3540440089
[5] J.-C. Laprie, From dependability to resilience, in
Supplemental Proceedings of the International
Conference on Dependable Systems & Networks.
Anchorage, Alaska, USA: DSN, 2008, pp. 89.
[6] E. Chang, F. Hussain, and T. Dillon, Trust and
Reputation for Service-Oriented Environments:
Technologies For Building Business Intelligence And
Consumer Condence, 1st ed. Wiley, July 2006.
[Online]. Available:
http://www.amazon.com/exec/obidos/redirect?tag=
citeulike07-20\&path=ASIN/0470015470
[7] D. A. Menasce, Qos issues in web services, IEEE
Internet Computing, vol. 6, no. 6, pp. 7275, 2002.
[8] G. Dobson, Using ws-bpel to implement software
fault tolerance for web services, in EUROMICRO 06:
Proceedings of the 32nd EUROMICRO Conference on
Software Engineering and Advanced Applications.
Washington, DC, USA: IEEE Computer Society, 2006,
pp. 126133.
[9] S. Bhiri, C. Godart, and O. Perrin, Transactional
patterns for reliable web services compositions, in
ICWE 06: Proceedings of the 6th international
conference on Web engineering. New York, NY,
USA: ACM, 2006, pp. 137144.
[10] G. A. Di Lucca and A. R. Fasolino, Testing
web-based applications: The state of the art and
future trends, Inf. Softw. Technol., vol. 48, no. 12, pp.
11721186, 2006.
[11] C. Bartolini, A. Bertolino, S. Elbaum, and
E. Marchetti, Whitening soa testing, in ESEC/FSE
09: Proceedings of the the 7th joint meeting of the
European software engineering conference and the
ACM SIGSOFT symposium on The foundations of
software engineering. New York, NY, USA: ACM,
2009, pp. 161170.
[12] G. Canfora and M. Penta, Service-oriented
architectures testing: A survey, Software Engineering:
International Summer Schools, ISSSE 2006-2008,
Salerno, Italy, Revised Tutorial Lectures, pp. 78105,
2009.
[13] M. A. Friedman and J. M. Voas, Software Assessment:
Reliability, Safety, Testability. New York, NY, USA:
John Wiley & Sons, Inc., 1995.
[14] M. H. Mustafa Bozkurt and Y. Hassoun, Testing web
services: A survey, Department of Computer Science,
Kings College London, Tech. Rep. TR-10-01, January
2010.
[15] G. K. Saha, Fault tolerance in web services,
Ubiquity, vol. 2006, no. March, p. 1, 2006.
[16] , Transient software fault tolerance using
single-version algorithm, Ubiquity, vol. 2005, no.
August, 2005.
[17] A. Erradi, P. Maheshwari, and V. Tosic, Recovery
policies for enhancing web services reliability, in
ICWS 06: Proceedings of the IEEE International
Conference on Web Services. Washington, DC, USA:
IEEE Computer Society, 2006, pp. 189196.
[18] S.-T. Wen, Q. Li, L. Yue, and A. Liu, An approach to
validating transactional properties of ws-bpel
composition, in Fifth International Conference on
Semantics, Knowledge and Grid, 2009., vol. 2009, oct.
2009, pp. 216 223.
[19] D. L ubke, Unit testing bpel compositions, in Test
and Analysis of Web Services. Springer, 2007, pp.
149171.
[20] Z. J. Li, J. Zhu, L.-J. Zhang, and N. Mitsumori,
Towards a practical and eective method for web
services test case generation, in Automation of
Software Test, 2009. AST 09. ICSE Workshop on,
18-19 2009, pp. 106 114.
[21] J. Outt and W. Xu, Generating test cases for web
services using data perturbation, SIGSOFT Softw.
Eng. Notes, vol. 29, no. 5, pp. 110, 2004.
[22] N. Laranjeiro, S. Canelas, and M. Vieira, wsrbench:
An on-line tool for robustness benchmarking, in SCC
08: Proceedings of the 2008 IEEE International
Conference on Services Computing. Washington, DC,
USA: IEEE Computer Society, 2008, pp. 187194.
[23] A. M. Paradkar, A. Sinha, C. Williams, R. D.
Johnson, S. Outterson, C. Shriver, and C. Liang,
Automated functional conformance test generation
for semantic web services, Web Services, IEEE
International Conference on, vol. 0, pp. 110117, 2007.
[24] A. Wombacher, P. Fankhauser, and E. Neuhold,
Transforming bpel into annotated deterministic nite
state automata for service discovery, in In Intl.
Conference on Web Services (ICWS. IEEE
Computer Society, 2004, pp. 316323.
[25] P. Ramsokul and A. Sowmya, A snier based
approach to ws protocols conformance checking, in
ISPDC 06: Proceedings of the Proceedings of The
Fifth International Symposium on Parallel and
Distributed Computing. Washington, DC, USA:
IEEE Computer Society, 2006, pp. 5865.
[26] Y. Yang, Q. Tan, and Y. Xiao, Verifying web services
composition based on hierarchical colored petri nets,
in IHIS 05: Proceedings of the rst international
workshop on Interoperability of heterogeneous
information systems. New York, NY, USA: ACM,
2005, pp. 4754.
[27] M. P. Papazoglou, Service -oriented computing:
Concepts, characteristics and directions, in WISE 03:
Proceedings of the Fourth International Conference on
Web Information Systems Engineering. Washington,
DC, USA: IEEE Computer Society, 2003, p. 3.
[28] S. Mehrotra, R. Rastogi, H. F. Korth, and
A. Silberschatz, A transaction model for
multidatabase systems, University of Texas at
Austin, Austin, TX, USA, Tech. Rep., 1992.
[29] S. Bhiri, O. Perrin, and C. Godart, Ensuring required
failure atomicity of composite web services, in WWW
05: Proceedings of the 14th international conference
on World Wide Web. New York, NY, USA: ACM,
2005, pp. 138147.
[30] J. Williams, The web services debate: J2ee vs. .net,
Commun. ACM, vol. 46, no. 6, pp. 5863, 2003.
[31] S. Balasubramaniam, G. A. Lewis, E. Morris,
S. Simanta, and D. B. Smith, Challenges for assuring
quality of service in a service-oriented environment,
in PESOS 09: Proceedings of the 2009 ICSE
Workshop on Principles of Engineering Service
Oriented Systems. Washington, DC, USA: IEEE
Computer Society, 2009, pp. 103106.
[32] H. Huang, W.-T. Tsai, R. Paul, and Y. Chen,
Automated model checking and testing for composite
web services, in ISORC 05: Proceedings of the Eighth
IEEE International Symposium on Object-Oriented
Real-Time Distributed Computing. Washington, DC,
USA: IEEE Computer Society, 2005, pp. 300307.
[33] A. Barbir, C. Hobbs, E. Bertino, F. Hirsch, and
L. Martino, Challenges of testing web services and
security in soa implementations, in Test and Analysis
of Web Services. Springer, 2007, pp. 395440.
[Online]. Available:
http://dx.doi.org/10.1007/978-3-540-72912-9 14
[34] W. Tsai, R. Paul, L. Yu, A. Saimi, and Z. Cao,
Scenario-based web services testing with distributed
agents, IEICE transactions on information and
systems, vol. 86, no. 10, pp. 21302144, 2003. [Online].
Available: http://ci.nii.ac.jp/naid/110003213658/
[35] G. Canfora and M. Di Penta, Testing services and
service-centric systems: Challenges and opportunities,
IT Professional, vol. 8, no. 2, pp. 1017, 2006.
[36] R. Blanco, J. Garca-Fanjul, and J. Tuya, A rst
approach to test case generation for bpel compositions
of web services using scatter search, in ICSTW 09:
Proceedings of the IEEE International Conference on
Software Testing, Verication, and Validation
Workshops. Washington, DC, USA: IEEE Computer
Society, 2009, pp. 131140.
[37] V. Pretre, F. Bouquet, and C. Lang, Using common
criteria to assess quality of web services, in ICSTW
09: Proceedings of the IEEE International Conference
on Software Testing, Verication, and Validation
Workshops. Washington, DC, USA: IEEE Computer
Society, 2009, pp. 295302.
[38] A. C. de Melo and P. Silveira, Improving data
perturbation testing techniques for web services,
Information Sciences, vol. 181, no. 3, pp. 600 619,
2011. [Online]. Available: http://www.sciencedirect.
com/science/article/B6V0C-515SRJV-4/2/
d10fe4c467bfec9717327d6bc0f784ef
[39] W. van der Aalst and K. van Hee, Workow
Management: Models, Methods, and Systems.
Cambridge, MA, USA: MIT Press, 2004.
[40] L. Baresi and E. D. Nitto, Test and Analysis of Web
Services. Secaucus, NJ, USA: Springer-Verlag New
York, Inc., 2007.