Information Technology Reference
In-Depth Information
In the rest, we assume the existence of a pre-defined function
Agreed2Join()
used by
services to decide whether they are willing to participate in compositions. Each ser-
vice may provide its own definition and implementation of the
Agreed2Join()
func-
tion. However, the way is
Agreed2Join()
defined is out of the scope of this paper.
Policy change
occurs if the provider updates one of its service policies. We adopt
a broad definition of policy, encompassing all requirements under which a service
may be consumed. We adopt the categorization proposed in [11] considering policies
as either vertical or horizontal. The vertical category refers to application domain-
dependent policies (e.g., shipping policy in business-to-business e-commerce). The
horizontal category refers to policies that are applicable across domains. It is com-
posed of three sub-categories: functional, non-functional, and valued-added. Func-
tional category describes the operational features of a Web service (e.g., in WSDL
[1,14], OWL-S [10]). Non-functional category relates to Quality of Service metrics.
The value-added category brings "better" environments for Web service interactions.
It refers to a set of specifications for supporting optional (but important) requirements
for the service (e.g., security, privacy, negotiation, conversation). Changes in the
policies of a participant WS
i
may impact the way a composite service CS
j
interacts
with WS
i
. Hence, they should be considered as logical faults. For instance, CS
j
invo-
cations to WS
i
may lead to run-time failures if WS
i
provider changed the input mes-
sage required by WS
i
(e.g., new message parameters added, changes made to data
types).
2.2 State of a Service
Soft-state signaling enables the propagation of bottom-up faults from participants to
composite services. The main idea of this class of signaling is that the
state
of each
participant is periodically sent to the composite service. The composite service will
then use the received state to determine whether there was any physical or logical
fault in the participant. Several questions need to be tackled when designing a soft-
state protocol: what is the definition of a state? And how is the state computed? We
will give answers to these questions in the rest of this section and paper.
The proposed framework must deal with all types of faults depicted in Fig 2.
Physical faults and status changes are detected by composite services in an
implicit
manner; if a node fault occurs or a participant is stopped/frozen, then the composite
service will not receive a state from that participant. The participation refusal fault is
explicitly
communicated by participants if they are not willing to be part of a compo-
sition.
Policy change faults are transmitted as part of the
participant's state
. To keep
track of policy changes, each participant WS
i
maintains a data structure called State
i
(Fig. 2). State
i
is defined by two attributes:
ChangeStatus
and
ChangeDetails
.
ChangeStatus
is equal to True if policy changes have been made to WS
i
. Several
changes may occur in WS
i
during a time period; details about these changes are stored
in the
ChangeDetails
set. Each element of this set represents a policy change; it is
defined by a couple (C,S) where C is the
category
of the policy and S is the
scope
of
the change. The initial values of ChangeStatus and ChangeDetails are False and
,
respectively. If a change (C,S) is detected on WS
i
, State
i
.ChangeStatus is set to True
and (C,S) is added to State
i
.ChangeDetails. The content of State
i
is periodically
∅
