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()
Search WWH ::




Custom Search