Int. J. Simulation and Process Modelling, Vol. 3, Nos. 1/2, 2007
45
On composing Dependable Web Services using
undependable web components
Anatoliy Gorbenko
and Vyacheslav Kharchenko
Department of Computer Systems and Networks (503),
National Aerospace University,
Kharkiv, 61070, Ukraine
E-mail: [email protected]
E-mail: [email protected]
Alexander Romanovsky*
School of Computing Science,
Newcastle University,
Newcastle upon Tyne, NE1 7RU, UK
E-mail: [email protected]
*Corresponding author
Abstract: This paper proposes a novel approach to constructing and modelling Dependable Web
Services (DeW) that are built by composing web components that can be undependable. This is
achieved by applying a structured approach to the Web Services (WSs) development, based on
the Web Service Composition Actions (WSCAs) scheme and a corresponding event-driven
simulation model of composite WS. The dependability and fault-tolerance of composite WS is
achieved by employing forward error recovery based on multilevel system structuring enabling
application-specific exception handling.
Keywords: web service composition; dependability; error recovery; simulation.
Reference to this paper should be made as follows: Gorbenko, A., Kharchenko, V. and
Romanovsky, A. (2007) ‘On composing Dependable Web Services using undependable web
components’, Int. J. Simulation and Process Modelling, Vol. 3, Nos. 1/2, pp.45–54.
Biographical notes: Anatoliy Gorbenko received his PhD in Technical Science at the National
Aerospace University (Kharkiv, Ukraine). He is a Lecturer at the Department of Computer
Science and Network, National Aerospace University. His main research interests are computer
networks and web service security and dependability. He has published a number of research
papers in national and international journals and conference proceedings.
Vyacheslav Kharchenko received his PhD in Technical Science at the Military Academy named
after Dzerzhinsky (Moscow, Russia) and Doctor of Technical Science Degree in Kharkiv
Military University (Ukraine). He is a Professor and Head of the Computer Systems and
Networks Department, National Aerospace University, Ukraine. His research interests include
dependable computer systems, multi version design technologies, software verification and
expert analysis. He has co-authored more than 140 scientific papers, reports and book chapters,
more than 500 inventions, edited and co-edited nine books in these and related areas. He has been
the principal investigator of several projects on dependable systems development and a
consultant in a number of I&C NPP. Now he is a Leading Researcher on safety-related software
of State Science-Technical Center of Nuclear and Radiation Safety (Ukraine).
Alexander Romanovsky is a Professor at the School of Computing Science (University of
Newcastle upon Tyne, UK). He has been involved in a number of National and European projects
on various aspects of dependability, including the Design for Validation ESPRIT Basic Project,
the Diversity with Off-The-Shelf Components EPSRC/UK Project, and the Dependable Systems
of Systems IST Project. Now he is coordinating the Rigorous Open Development Environment
for Complex Systems IST Project. His research interests include dependability, fault tolerance,
software diversity, exception handling, system structuring for error confinement. He has
co-authored more than 130 scientific papers and book chapters, and co-edited seven books in
these and related areas.
Copyright © 2007 Inderscience Enterprises Ltd.
46
1
A. Gorbenko, V. Kharchenko and A. Romanovsky
Introduction
The WS architecture (Ferguson et al., 2003) is rapidly
becoming a de facto standard environment for achieving
interoperability between various software applications
running on a variety of platforms. This architecture supports
development and deployment of open systems in which
component discovery and system integration can be
postponed until the systems are executed. The individual
components (i.e., WSs) advertise their services via a registry
(typically developed using the UDDI standard) in which
their descriptions, given in a standard XML-based language
called Web Service Definition Language (WSDL), can be
looked up. After a WS capable of delivering the required
service has been found, it can be used or even dynamically
integrated into a composite WS.
Developing the WS architecture is in effect a further
step in the evolution of the well-known component-based
system development techniques supporting the integration
of Off-The-Shelves (OTS) components (Szyperski, 2003).
The main advances in the WS architecture have been made
by the standardisation of the integration process using a set
of interrelated standards, such as SOAP, WSDL, UDDI, etc.
These technologies provide easy interoperability between
software components developed by and deployed in
different organisations. WS are the OTS components for
which a standard way of advertising and employing
functionality has been widely adopted. The WS architecture
is now extensively used in developing various critical
applications, such as banking, auctions, internet shopping,
hotel/car/flight/train reservation and booking, e-business,
e-science, business account management. This is why
ensuring dependability in this architecture is an emerging
area of research and development (Ferguson et al., 2003;
Tartanoglu et al., 2003a).
System dependability is defined as the reliance that can
be justifiably placed on the service the system delivers
(Avizienis et al., 2004). There are four dependability
technologies by which dependability is attained:
•
rigorous design, which aims at preventing the
occurrence or the introduction of faults
•
verification and validation, which aims at reducing the
number or severity of faults
•
fault tolerance, which aims at delivering correct service
despite the presence of faults
•
system evaluation, which aims at estimating the present
number, the future incidence and the likely
consequences of faults.
The challenge in developing DeWs is posed by the specific
characteristics of this architecture, including its openness,
heterogeneity of components and platforms, asynchronous
nature of communication and autonomy of components.
In addition to that, the components to be integrated are
ready-made black boxes of unknown quality, which belong
to different organisations and are out of the control of the
systems using them.
WS composition is an emerging area of research
(Milanovic and Malek, 2004). The current work on WS
verification and validation is being carried out in several
directions, including testing (Tsai et al., 2004) and
model-based verification (Foster et al., 2003). A novel
approach to dependability evaluation focusing on
availability assessment is proposed in Kaaniche et al.
(2003). Paper (Tartanoglu et al., 2003b) analyses several
existing approaches to incorporating fault tolerance
measures (including both backward and forward error
recovery mechanisms) into the composite WSs.
In this work we focus on forward error recovery as one
of the main means of achieving WS fault-tolerance.
This type of recovery is usually implemented by exception
handling. Recovery by exception handling can require
considerable extra time, so the application of this type of
techniques should be accompanied by a thorough analysis of
its cost. This paper introduces a novel two-level exception
handling scheme to be used for building fault tolerant
composite WS and a simulation model developed to analyse
the scheme effect on the two dependability attributes:
reliability (probability of successful request processing) and
availability (mean request processing time). It is our belief
that these solutions will allow us to make considerable
progress towards achieving the ultimate goal: developing
approaches that make it possible to build dependable
composite WSs using undependable web components.
2
On Dependable Web Service (DeW)
composition
2.1 Web Service Composition Actions (WSCAs)
In our previous work we have developed a structured
approach to the composition of WS (Tartanoglu et al.,
2003b). WSCAs allow composite WSs to be structured
in terms of Coordinated Atomic actions (CA actions)
(Xu et al., 1995) that have a well-defined behaviour, both in
the absence and in the presence of service failures.
This solution has no impact on the autonomy of the
individual WSs, while exploiting their possible support for
fault tolerance (e.g., transaction support at the level of
each service). WSCA participants specify interactions with
composed WSs, stating the role of each WS in the
composition. Each WS is viewed as an external resource.
However, unlike the base CA action model, interactions do
not have to be transactional. The interactions adhere to the
semantics of the WS operations that are invoked.
The development process of a WSCA-based composite
WS comprises the definitions of the required abstract
interfaces of the component WSs that are to be
integrated and of the composition process that gives the
binding information as well as the WSCA standard and
exceptional behaviours. The scheme enforces recursive
(e.g., hierarchical) system structuring during the system
composition and supports forward error recovery as the
main means of providing fault tolerance. Each WSCA can
deliver a number of normal and exceptional outcomes.
On composing Dependable Web Services using undependable web components
metrics that characterise this function (its reliability,
security, execution time, etc.).
When an exceptional outcome is reported all responsibility
for the recovery is transferred to the higher level in the
system structure (the containing WSCA).
A component WS produces results of two main types:
a) success; b) failure. In some cases, a partial result also
can be provided in the ways which we explain later.
The behaviour of a component WSs may in some cases
depend on time.
2.2 Structured approach to Web Service (WS)
development
The structured approach we are putting forward is based on
the development of a composite WS built as a multilevel
hierarchy with regular and nested recursive structure.
The basic principles of the structured approach are as
follows:
•
•
Requests sent by the users to the composite
WS are handled as top level WSCAs. There are several
types of such Arriving Requests (ARs) to be processed
by the composite WS. The execution of each of these is
structured out of the execution of several Nested
Actions (NAs). This structuring is application-specific
and is defined during WS composition. The type of an
individual AR (corresponding to a WSCA, in the
general case) depends on the number and the types of
the NAs. In turn, each of the NAs is a WSCA of the
adjacent lower level, which can be also decomposed
into several NAs, and so on.
The composite WS has a multilevel hierarchical
structure (see Figure 1), which, as a whole, coincides
with the WSCA nesting scheme. The composite WS is
a ‘white box’. It contains a number of component WSs
that process separate parts of the ARs (i.e., a set of
nested WSCAs). For the composite WS any of the
component WSs is a ‘black box’. However, the
component WS inside also can be treated as a
‘white box’ which in turn is composed of a number of
component WSs at the next lower decomposition layer,
and so on.
Thus, at any decomposition level we can consider two
alternative views on the structure: the ‘white box’ one
(jth composite WS of ith level) and several ‘black
boxes’ (a set of component WSs related to the i, jth
composite WS), i.e., a composite WS is structured in
both the vertical and the horizontal directions, as shown
in Figure 1.
•
Generally, the component WSs at the bottom level of
the structure are the pre-developed services with known
or predicted characteristics (reliability, security,
dependability in general). New WSs are built by
composing in various ways these component WSs.
An individual component WS is described by its
functionality, i.e., the realised function, and a set of
47
•
To process WSCAs a composite WS executes a number
of corresponding operations by invoking one or several
component WSs and combining their results. Inside the
composite WS the following three types of the WSCA
processing result are defined:
•
if all of the NAs of a WSCA are successfully
completed by the set of the component WSs, the
overall result of the WSCA is successful
•
if not all of the NAs of a WSCA are processed
successfully, then the partial successful result is
produced
•
if all of the NAs of a WSCA are processed with
failures, then the result of WSCA processing is
erroneous.
Producing the results of the second type, called here
‘partial successful result’, depends on:
•
the type and the individual parameters of the
processed WSCA
•
the dependability characteristics of the composite
WSs
•
the dependability characteristics of all the
component WSs involved in the processing of the
WSCA NAs.
During the development of a composite WS, the designer
decides which of the component WSs to use depending on
their functionality, dependability and other characteristics
(e.g., performance, cost and time of development). The
overall structure of the composite WS will be defined by its
granularity.
Besides, each component WS that processes only
WSCAs of a specified type may be executed on a Dedicated
Server (DS). A better throughput can be achieved when all
WSCAs are processed in parallel on different DSs. In other
cases when several component WSs are executed on the
same server, WSCAs are processed in a parallel-sequential
mode. The application logic of the Composite WS can affect
the mode of request execution as well.
A more detailed description of the proposed approach
can be found in Gorbenko et al. (2004).
48
Figure 1
A. Gorbenko, V. Kharchenko and A. Romanovsky
Structure of a composite Web Service
2.3 Ensuring fault-tolerance and dependability
3
The Travel Agency (TA) example
High dependability and fault-tolerance of the composite
WS are ensured by using different kinds of redundancy
and diversity that are available at different levels
of the composite WS hierarchy. Developing fault tolerant
mechanisms for composite WSs has been an active area of
research over the last several years (see Tartanoglu et al.,
2003a, for a survey). In Tartanoglu et al. (2003b) the
backward (based on rolling system components back
to the previous correct state) and forward (which involves
transforming system components into any correct state)
error recovery for the WSs is discussed.
The WSCA concept for tolerating faults is based on
exception handling of two types: internal (i.e., inside the
component WS) and external (which requires cooperative
handling at the level of the composite WS) exception
handling. For example, an exception handler can implement
a simple backward error recovery using operation retry to
tolerate transient failures.
In our scheme the exception handlers of a WS can be
both application-specific and general. The approach in
Alwagait and Ghandeharizadeh (2004) uses general
exception handlers to ensure independence from the
physical locations of services. The DeW framework uses a
predefined ‘WebServiceNotFound’ exception to handle
situations when a service migrates by redirecting the
request to the new location known to the DeW middleware
component, which monitors the system configuration.
To demonstrate the WSCA scheme and WSs composition
we consider joint booking of accommodation and flights,
excursion and car hire using four separate component WSs.
Then, the composite WS operation is specified using
WSCAs as follows (Tartanoglu et al., 2003b). The top-level
TravelUser WSCA comprises the User and the Travel
participants; the former interacts with the user while the
latter achieves joint booking according to the user’s request
through call to the WSCA that composes the Flight, Car,
Hotel and the Excursion participants or only some of them.
An example of the diagrammatic specification of a
WSCA with booking of accommodation and flights is
shown in Figure 2. In the TravelUser WSCA, the User
participant requests the Travel participant to book a flight
ticket and a hotel room for the duration of the given stay.
This leads the Travel participant to invoke the joint booking
WSCA FlightHotel that composes the Hotel Web Service
and the Flight Web Service. The participants of the
FlightHotel WSCA respectively requests for a hotel room
and a flight ticket, given the travel itinerary and dates
provided by the user.
Each request is divided into reservation for the given
period and subsequent booking if the reservation succeeds.
If both the Hotel and the Flight participants raise the
unavailable exception, then concurrent exception resolution
applies. As a result the FlightHotel WSCA signals an
exception to the Travel participant of the TravelUser
On composing Dependable Web Services using undependable web components
WSCA, where the exception gets handled in a cooperation
with the User denoted by the grey box in the figure (e.g., the
user is requested to give alternative dates). In the case
where either the reservation or the booking of one of the
participants fails, the participant raises an exception
(unavailableHotel in the example) that is cooperatively
handled at the level of the FlightHotel WSCA. If one
participant has already confirmed a reservation, the booking
that has succeeded is cancelled and an unavailableHotel
exception is signalled to the calling TravelUser WSCA for
recovery with a user intervention (see Figure 2).
Figure 2
49
The logical subsystem of the simulation model defines a
set of ARs to be processed by the composite WS, a set of
the nested WSCAs on which each of the ARs can be
decomposed and a set of the component WSs that process
the defined type of nested WSCAs. The physical subsystem
of the simulation model (see Figure 3) defines a relationship
between the logical model and the overall hardware
architecture, taking into account the number of DSs and
theirs specialisation.
Figure 3
Physical model of composite Web Service
WSCA processing by the Travel Agency composite
Web Service
The failures are simulated in the following way. At the
second level of the model, the failures are represented as
the events in which the component WS cannot deliver the
service requested by WSCA cased by the following:
Note that if the handling fails and the cancellation is not
possible failure exception is signalled to the calling WSCA
providing it with the sufficient information about failed
operations to help later recovery.
4
Modelling of the composite Web Services (WSs)
dependability
In this section we describe a simulation model of composite
WS used for a specific target environment – the TA WS.
•
hardware faults
•
software faults
•
application-specific situations when component WS
cannot satisfy the WSCA requirements.
In case of failure, the component WS catches an exception
and activates the error handling mechanism. As a result of
error handling some of the failures will be tolerated inside
the component WS. The composite WS will not even know
about them (encapsulation of the internal behaviour).
Thus, for the nested WSCA, processed by a component
WS, two outcomes are possible:
•
The WSCA is processed successfully (including the
situations when a failure occurred but was tolerated
inside the component WS). The component WS returns
a normal result back to the composite WS.
•
The WSCA is processed with a failure not tolerated by
the error handling inside of the component WS. In this
case, the component WS propagates an exception to the
composite WS.
4.1 A general approach to modelling
We use a two-level WSCA-based approach for the
composite WS modelling. At the first level, we have a
composite WS which processes the input request stream
and returns outputs to the output stream. The ARs (WSCAs
of the first level) are decomposed into a number of nested
WSCAs (WSCAs of the second level). These nested
WSCAs are then processed by the corresponding
component WSs.
The failures at the top level of the model include the
exceptions propagated by the component WSs as well as the
exceptions raised by the composite WS itself when it detects
its own errors.
50
A. Gorbenko, V. Kharchenko and A. Romanovsky
These failures can also be tolerated using the error
handling by the composite WS. When the composite WS
fails to deliver the service required by an AR, it reports an
exceptional outcome to the output stream.
•
PReq[1..ReqCount] is an array which specifies the
arrival probabilities of the requests of each type.
•
MServ[1..ServCount, 1..CnCount] is an array which
specifies the set of DSs.
4.2 Assumptions and their foundation
Figure 4
Composite WS simulation schema
We simulate a specific behaviour of a composite WS under
the following assumptions:
•
The failures of the component WSs occur when the
component WSs fail to deliver the services that WSCAs
require.
•
These failures can be tolerated inside the Component
WSs by the error handling. The probability of tolerating
errors is given for each of the component WSs.
•
The time of error handling is equal to the normal
(without failures) execution time of the component WS.
•
When the component WS cannot tolerate a failure, it
reports an exception up to the composite WS.
•
The failures of the composite WS are reported as
exceptions propagated by them.
•
The probability with which the composite WS can
tolerate these failures is proportional to the ratio
between the number of nested WSCAs processed
without failures by the component WSs and the total
number of nested WSCAs.
•
The time of error handling executed by the composite
WS is equal to the normal (without failures) execution
time of the AR.
•
When the composite WS cannot tolerate these failures,
it reports an exceptional outcome to the output stream.
The simulation data and the recorded results are as follows.
•
ReqNo is the type of the current AR (1..ReqCount).
•
TReq is the execution time for the AR, in seconds.
•
CnOut[1..CnCount] is an array which specifies the
processing result of the nested WSCAs initiated by the
AR: ‘0’ – this WSCA is not executed (the AR does not
require this WSCA); ‘1’ – WSCA executes without
failures; ‘2’ – WSCA executes with a failure which is
tolerated by the error handling mechanism of the
component WS; ‘3’ – WSCA executes with a failure
which is not tolerated.
•
ReqOut presents the detailed processing result of the
AR. This includes ‘1’ – all nested WSCAs are
processed successfully; ‘2’ – several nested WSCAs are
processed with failures all of which are tolerated using
error handling inside the component WS; ‘3’ – several
nested WSCAs are processed with failures not all of
which are tolerated inside the component WSs,
however, the partially executed request is tolerated by
error handling of the composite WS; ‘4’ – several
(or all) nested WSCAs are processed with failures not
all of which are tolerated inside the component WSs
and the partially executed request is not tolerated by the
error handling mechanism of the composite WS.
•
ReqStat – execution outcomes of processing an AR
4.3 Specification of the input and output data
The input data and settings for the simulation are
(see Figure 4):
•
CnCount is the number of bottom-level WSCAs of
different types (equal to the number of the component
WSs processing them).
•
ReqCount is the number of different types of requests.
•
ServCount is the number of DSs on which the
component WSs can be deployed.
•
PCn[1..CnCount, 1..3] is a matrix which specifies the
probabilities of different outcomes of processing a
WSCA (failure free, tolerated failure and non-tolerated
failure) for each of the component WSs.
•
TCn[1..CnCount] is an array which specifies the
execution time of processing a WSCA without failures
for each of the component WSs, in seconds.
•
MReq[1..ReqCount, 1..CnCount] is a matrix which
specifies the set of ARs.
(IF ReqOut = {1, 2, 3} THEN ReqStat = 1 ELSE
ReqStat = 0): ‘1’ – the request is executed successfully
(including the situation when failures occurr, but they
are tolerated inside the component WSs or by the
composite WS); ‘0’ – the request is executed with
failures which are not tolerated.
•
ServLoad[1..ServCount] – array which specifies the
load time for each of the DSs during the processing of
an AR, in seconds.
On composing Dependable Web Services using undependable web components
4.4 Model structure
An event-driven simulation model of the composite WS is
proposed to analyse its overall performance as a function of
the number and characteristics of the component WSs.
The model is developed using the M-File programming and
is simulated in the MATLAB 6.0 environment. The internal
model structure (see Figure 5) includes the Request Random
Generator, which creates the ARs, the Request Composer
and the Server Loader distributing WSCAs to the
Figure 5
The proposed model is used to simulate the TA WS
taking into account the results stated in Tartanoglu et al.
(2003b).
The following input data and settings are used for the
TA simulation.
•
corresponding component WSs and the Result Analyser,
which processes statistical information and aggregates
results. Component WSs are implemented as program
functions by using the M-File language and invoked
by the composite WS, which is the main model function.
A particular type of the AR and the outcomes of WSCAs
processing are generated according to the specified
probabilities by using the MATLAB function ‘rand’.
All model settings and simulation results are represented in
the matrix form.
Travel Agency model (three-servers configuration) and partial simulation results
4.5 Foundation of input data values
•
51
There are four types of component WS (CnCount = 4):
•
CnWS1: ‘Booking of flight tickets’, which
process WSCA1: ‘Flight’
•
CnWS2: ‘Car hire’, which process
WSCA2: ‘Car’
•
CnWS3: ‘Hotel reservation’, which process
WSCA3: ‘Hotel’
•
CnWS4: ‘Excursion order’, which process
WSCA4: ‘Excursion’.
When error handling is used we assume that that there
are three possible outcomes for each of the composites:
•
PCn1(CnWSi): probability that the component
WSi processes WSCAi without failure
•
PCn2(CnWSi): probability that the component
WSi processes WSCAi with a failure tolerated
by the error handling inside of component
WSi
•
PCn3(CnWSi): probability that the component
WSi processes WSCAi with a failure not
tolerated by the error handling inside of
component WSi.
Table 1 shows the probabilities values of different
outcomes for each component WS used in the
simulation. These probabilities should be specified
for a particular WS by taking into account the results
of service testing and monitoring.
This will help us to analyse the effectiveness of the
proposed technique and the advantages gained during
WS development or reengineering.
52
•
•
A. Gorbenko, V. Kharchenko and A. Romanovsky
Suppose that the normal (without failure)
execution time of each component WS is as follows:
T(CnWS1) = T(CnWS2) = T(CnWS3) = T(CnWS4) = 0.1
sec. This time is chosen using our experiments within
the local network. Generally speaking, it depends on
the service function complexity, host performance and
network delays. The execution time of the real WS
deployed on the internet may be longer.
4.6 Simulation results
In simulations the seven types of request
(ReqCount = 7) that can arrive from the users to the
composite WS are used (see Table 2). Each type of the
ARs contains certain WSCAs. Thus, MReq = [1,0,0,0;
0,1,0,0; 1,1,0,0; 1,0,1,0; 1,1,1,0; 1,0,1,1; 1,1,1,1].
•
simulation results of the composite WSs with error
handling at the component and composite WS levels
are shown in Figure 6
•
simulation results for composite WSs without error
handling are given in Figure 7
•
Figure 8 shows the comparison of the number and the
request processing times of successful and unsuccessful
requests for composite WSs with and without error
handling.
•
Suppose that the probabilities of requests of
each type arriving are equal. Thus, Preq(ARi) =
1/ReqCount = 0.14286.
•
We experimented with several physical configurations
of the composite WS with one, two, three and four DSs.
For example, Figure 5 shows the structure of the
composite WS simulation model with the three DSs.
The ‘Booking of flight tickets’ and ‘Car hire’
component WSs are launched on the same server DS1,
whereas ‘Hotel reservation’ and ‘Excursion order’ are
launched on the Dedicated Servers DS2 and DS3 (i.e.,
ServCount = 3; Mserv = [1,1,0,0; 0,0,1,0; 0,0,0,1]):
•
Dedicated Server DS1 serves the component WSs
CnWS1 and CnWS2
•
Dedicated Server DS2 serves the component WS
CnWS3
•
Dedicated Server DS3 serves the component WS
CnWS4.
The initial settings and the results of a particular
simulation of the TA composite WS are shown on
Figure 5.
Table 1
Probabilities of the different outcomes for each
component WS
CnWS1 ‘Booking of flight tickets’
CnWS2 ‘Car hire’
CnWS3 ‘Hotel reservation’
CnWS4 ‘Excursion order’
Table 2
PCn1
0.50
0.50
0.50
0.50
PCn2
0.25
0.25
0.25
0.25
PCn3
0.25
0.25
0.25
0.25
Types of the Arriving Requests, processed by the
composite WS
WSCA1 ‘Flight’
WSCA2 ‘Car’
WSCA3 ‘Hotel’
WSCA4 ‘Excursion’
AR1 AR2 AR3 AR4
Yes
Yes Yes
Yes Yes
Yes
AR5 AR6
Yes Yes
Yes
Yes Yes
Yes
AR7
Yes
Yes
Yes
Yes
The results are obtained by averaging the simulation
outcomes of 1000 ARs.
These results are compared for the composite WSs
with and without the error handling mechanism under the
assumption that this mechanism is capable of tolerating all
detected faults.
Figure 6
Simulation results for a composite WS with error
handling
On composing Dependable Web Services using undependable web components
Figure 7
Figure 8
Simulation results for a composite WS without error
handling
Comparison of the number and request processing
times for a composite WS with and without error
handling
5
53
Discussion
The analysis above shows that the WSCA-based
composition of WSs and the use of exceptions handling
allow us to significantly increase the ratio of the
successfully serviced requests. At the same time, there is an
increase of the mean time of request processing.
However, employing more than one DSs allows us to
essentially decrease this time as Figure 8 clearly indicates.
We can conclude, therefore, that the performance of the
composite WSs depends significantly on the hardware
architecture and as the level of concurrency increases the
negative impact of the overhead owing to exception
handling decreases.
The results reported here have been obtained under the
assumption that the confidence intervals of the initial values
used in the simulation and the settings may be determined
using data from the previous experience or trustworthy
prediction methods. By changing parameters used in the
particular simulation set up (e.g., varying the values of the
times used and probabilities of the various events involved)
we can analyse whether the observed effects depend on the
values of the parameters or not.
For instance, for a wide range of parameters the negative
impact of exception handling on the performance is
observed (see Figure 8), in these cases extensive
concurrency of WSs with exception handling can be
recommended. Note, that the analysis above ignores
the additional cost caused by the increased level of
concurrency. Although it is clear that in some
application-specific situations, there will be no additional
cost. It is in our future plan to work on a refined model
dealing with this issue.
Acknowledgement
Vyacheslav Kharchenko has been partially supported by the
Royal Society grant (RS 16114). Alexander Romanovsky is
supported by FP6 IST RODIN Project (511599). We are
grateful to the anonymous reviewers for their valuable
comments.
References
Alwagait, E. and Ghandeharizadeh, S. (2004) ‘DeW: a dependable
web services framework’, 14th International Workshop on
Research Issues on Data Engineering: Web Services for
E-Commerce and E-Government Applications (RIDE’04),
Boston, Massachusetts.
Avizienis, A., Laprie, J-C., Randell, B. and Landwehr, C. (2004)
‘Basic concepts and taxonomy of dependable and secure
computing’, IEEE Transactions on Dependable and Secure
Computing, Vol. 1, No. 1, pp.11–33.
Ferguson, D.F., Storey, T., Lovering, B. and Shewchuk, J. (2003)
Secure, Reliable, Transacted Web Services: Architecture
and Composition, MS and IBM Technical Report,
http://www-106.ibm.com/developerworks/webservices/library/
ws-securtrans.
54
A. Gorbenko, V. Kharchenko and A. Romanovsky
Foster, H., Uchitel, S., Magee, J. and Kramer, J. (2003)
‘Model-based verification of web service compositions’,
Automated Software Engineering (ASE) Conference,
Montreal, Canada.
Gorbenko, A., Kharchenko, V., Popov, P., Romanovsky, A. and
Boyarchuk, A. (2004) Development of Dependable Web
Services out of Undependable Web Components, School of
Computing Science, University of Newcastle upon Tyne, UK.
Kaaniche, M., Kanoun, K. and Rabah, M. (2003) ‘Multi-level
modelling approach for the availability assessment of
e-business applications’, Software Practice and Experience,
Vol. 33, No. 14, pp.1323–1341.
Milanovic, N. and Malek, M. (2004) ‘Current solutions for
web service composition’, IEEE Internet Computing, Vol. 8,
No. 6, pp.51–59.
Szyperski,
C.
(2003)
Component
Software:
Beyond
Object-Oriented Programming, Addison-Wesley, Harlow,
England, p.608.
Tartanoglu, F., Issarny, V., Levy, N. and Romanovsky, A. (2003a)
‘Dependability in the web service architecture’, Architecting
Dependable Systems, LNCS 2677, Springer-Verlag, Berlin,
Heidelberg, Germany, pp.89–108.
Tartanoglu, F., Issarny, V., Romanovsky, A. and Levy, N. (2003b)
‘Coordinated forward error recovery for composite web
services’, 22th Symposium on Reliable Distributed Systems
(SRDS), Florence, Italy.
Tsai, W-T., Chen, Y., Cao, Z., Bai, X., Huang, H. and Paul, R.J.
(2004) ‘Testing web services using progressive group testing.
Advanced workshop on content computing’, in Chi, C-H. and
Lam, K-Y. (Eds.): Content Computing, Advanced Workshop
on Content Computing, AWCC 2004, Springer, pp.314–322.
Xu, J., Randell, B., Romanovsky, A., Rubira-Calsavara, C.M.F.,
Stroud, R.J. and Wu, Z. (1995) ‘Fault tolerance in concurrent
object-oriented software through coordinated error recovery’,
25th International Symposium on Fault-Tolerant Computing,
(FTCS-25), Pasadena, California, USA.