Information Technology Reference
In-Depth Information
faulty senders (selected randomly). Fig. 6 shows that the
τ
SSR
timer value has an
impact on the fault propagation time. The smaller is
τ
SSR
, the shorter is the fault
propagation time.
False faults
refer to the situation where receivers assume faults that did not occur
in their senders. Fig. 7 depicts the relationship between false faults and timer differ-
ence (i.e.,
τ
SSS
-
τ
SSR
). We set
τ
SSR
to 20s and vary
τ
SSS
from 20s to 25s, 30s, 35s, 40s,
etc. Fig. 7 shows that false faults occur if
τ
SSS
-
τ
≥
0 (i.e.,
τ
≥τ
SSR
). In addition, the
SSR
SSS
bigger is
SSR
), the larger is the number of false faults. These faults
correspond to cases where Refresh() messages are sent after the end of the corre-
sponding
τ
SSS
(compared to
τ
τ
SSR
cycles.
80
70
60
50
40
30
20
10
0
0
5
10
15
20
25
30
35
40
45
50
Time r Diffe re nce
Fig. 7.
Relationship between τ
SSS
and τ
SSR
and impact on False Faults ratio
5 Related Work
Mechanisms that support fault management in software systems have been around for
a long time. Workflow has traditionally been used to deal with faults in business
processes. Faults in workflows have usually been modeled as exceptions. SOAs
consider faults as the rule, and any solution to fault management would need to treat
them as such. Traditional software engineering solutions for fault management (e.g.,
exceptions and run-time assertion checking) have hard-coded, internal, and applica-
tion-specific capabilities that limit their generalization and reuse. They disperse the
adaptation logic throughout the application, making it costly to modify and maintain
[4]. These factors have actuated research dealing with the concept of self-healing
systems. A comprehensive survey of major self-healing software engineering
approaches is presented in [5]. However, such approaches focus on “traditional”
applications
not
service-oriented. The peculiarity of faults, interaction models, and
architectural style in SOAs as well as the autonomy, distribution, and heterogeneity of
services make these approaches difficult to apply in SOAs.
Current techniques for coping with faults in SOAs allow developers to include
constructs in their service specifications (e.g., fault elements in SOAP and WSDL,
exception handling in BPEL). Such techniques are static, ad hoc, and make service
