Information Technology Reference
In-Depth Information
Definition:
The state, denoted State
i
, of a participant WS
i
is defined by (ChangeS-
tatus,ChangeDetails) where:
•
ChangeStatus = True
⇔
changes have been made to WS
i
.
•
ChangeDetails = {(C,S) / C and S are the category and scope of a change in
WS
i
}.
•
Initially do: State
i
.ChangeStatus = False and State
i
.ChangeDetails =
∅
.
•
At the occurrence of a change (C,S) in WS
i
do: State
i
.ChangeStatus = True,
State
i
.ChangeDetails = State
i
.ChangeDetails
∪
{(C,S)}.
2.3 Fault Coordinators
In the proposed framework, fault management is a collaborative process between
architectural modules called
fault coordinators
. Each Web service (participant or
composite) has a coordinator associated to it. This peer-to-peer topology distributes
control and externalizes fault management, hence creating a clear separation between
the business logic of the services and fault management tasks.
Fig. 3.
Fault Coordinators
We define two types of coordinators (Fig. 3):
soft-state senders
(SS-S) and
soft-
state receivers
(SS-R). Each participant (resp., composite service) has a sender (resp.,
receiver) attached to it. A sender SS-S
i
maintains the State
i
data structure. To keep
track of its receivers, SS-S
i
maintains a Receivers(SS-S
i
) data structure. If WS
i
(at-
tached to SS-S
i
) participates in CS
j
(attached to SS-R
j
) then SS-R
j
Receivers(SS-S
i
).
SS-S
i
periodically sends State
i
to its receivers via Refresh() messages. The refresh
period is determined by the
∈
τ
SSS
timer maintained by SS-S
i
. A receiver SS-R
j
main-
tains two data structures: Senders(SS-R
j
) and
SSR
. Senders(SS-R
j
) is the set of send-
ers from which SS-R
j
expects to receive Refresh(). If WS
i
participates in CS
j
then
τ
