Information Technology Reference
In-Depth Information
2.1 Bottom-up Fault Taxonomy
A fault management approach must refer to a taxonomy that describes the different
types of faults that composite services are expected to be able to manage. We identify
two types of bottom-up faults:
physical
and
logical
(Fig. 1).
Physical faults
are re-
lated to the infrastructure that supports Web services. In this paper,
the underlying
communication system is assumed to be failure-free
: there is no creation, alteration,
loss, or duplication of messages. However,
node faults
are still possible. A
node fault
occurs if the servers (e.g., application server, Web server) hosting a participant are out
of action.
Logical faults
are initiated by service providers; this is in contrast to physi-
cal faults which are out of service providers' control. We categorize logical faults as
status change
,
participation refusal
, and
policy change
.
Status change
occurs if the service provider explicitly modifies the availability
status of its service. The status may be changed through freeze or stop. In the
freeze
fault, providers shut down their services for limited time periods (e.g., for mainte-
nance, unavailability of a product in a supply chain's provider). In the
stop
fault,
providers make their services permanently unavailable (e.g., a company going out-of-
business).
Fig. 1.
Bottom-up Fault Taxonomy
Participation refusal
occurs if a service is not willing to participate in a given
composition. The way participation decision is made varies from a Web service to
another. We give below four techniques on how such decisions could be made:
•
A service load balancer may check that the server workload will not exceed
a given threshold if the service participates in a new composition. The
threshold could, for instance, be defined to maintain a minimum quality of
service.
•
A policy compatibility checker may also verify the compliance of the
service policies (e.g. privacy policies) with the composite service policies.
•
A service reputation manager may verify that the reputation (e.g., defined
by users' ratings) of the composite service is higher than a threshold set by
the participant.
•
A notification may be sent to the participant's provider who will decide
whether the service should participate in the composition or not.
