Information Technology Reference
In-Depth Information
these policies depending on pre-defined parameters. In [7], we define a Petri Net
model for the specification of high-level recovery policies in composite services.
These recovery policies are generic directives that model exceptions at design time
together with a set of primitive operations used at run time to handle the occurrence
of exceptions. The proposed model identifies a set of recovery policies that are use-
ful and commonly needed in many practical situations. Details about the tech-
niques for fault reaction are out of the scope of this paper. We assume the exis-
tence of a procedure React (FT, SS) implemented by each composite service to re-
act to faults. The FT parameter is the fault type and takes one of the following val-
ues: “Refusal” to refer to a participation refusal fault, “No Refresh” to refer to the
non-reception of a Refresh() message (i.e., physical fault or status change), and
“policy” to refer to a policy change fault. The SS parameter refers to the sender of
faulty participant; the reaction mechanism may in fact vary from a participant to
another.
3 The Fault Propagation Protocol
In this section, we describe the algorithms executed by senders and receivers for
propagating bottom-up faults. We assume that WS
i
(with SS-S
i
as attached sender)
participates in CS
j
(with SS-R
j
as attached receiver). As mentioned in Section 2.1, we
assume that there is no creation, alteration, loss, or duplication of messages. The
propagation protocol adapts the well-know soft-state signaling described in [8,16] to
service-oriented environments. It enables the propagation of participation refusal
and policy changes faults to receivers. Physical faults and status changes are implic-
itly propagated to receivers if the latter do not get Refresh() messages from faulty
senders.
3.1 Soft-State Sender Algorithm
Table 1 gives the algorithm executed by SS-S
i
. SS-S
i
receives two types of messages
from SS-R
j
: Join(SS-R
j
) and Leave(). Join(SS-R
j
) is the first message that SS-S
i
re-
ceives from SS-R
j
; it invites WS
i
to participate in CS
j
(lines 1-10). SS-S
i
calls the
Agreed2Join()
function to figure out whether WS
i
is willing to participate in CS
j
(see
Section 2.1). If
Agree2Join(SS-R
j
)
returns False, SS-S
i
sends the Decision2Join(SS-
S
i
,False) message to SS-R
j
. Otherwise, SS-S
i
adds SS-R
j
to its receivers. If SS-R
j
is
the first receiver of SS-S
i
, SS-S
i
initializes State
i
and starts its
τ
SSS
timer. Finally, SS-
S
i
sends its decision to SS-R
j
through the Decision2Join(SS-S
i
,True) message. At any
time, SS-S
i
may receive a Leave() message from SS-R
j
(lines 11-13). This message
indicates that CS
j
is no longer using WS
i
as a participant. In this case, SS-S
i
removes
SS-R
j
from its receivers.
At the detection of a policy change (with a category C and scope S) in WS
i
(lines
14-17), SS-S
i
sets State
i
.ChangeStatus to True. SS-S
i
keeps track of that change by
inserting (C,S) in State
i
.ChangeDetails. In this way, the state of SS-S
i
to be sent to
receivers at the end of
SSS
cycle includes all changes that have occurred during that
cycle. At the end each period (denoted by
τ
τ
SSS
timer), SS-S
i
sends a Refresh()