Information Technology Reference
In-Depth Information
associate with the processing of local etiquette message box) might be programmed to
generate fitness function events — either reaching threshold values, or every change.
We shall now demonstrate, starting with node's bootsrapping how fitness function
can help to modify e-rules towards increasing fitness of a node and a community.
3.3 Bootstrapping
On boot a node is assigned default role[s] and a purpose, this is done by enforcing
locally the two rule sets — policy and etiquette. Policy set is node's role refined into a
set of fully specified policies — rules defining node's functional behaviour choices.
Etiquette is the refinement of node's purpose with regard to autonomic communica-
tion; the purpose is enforced by a set of etiquette rules defining choices in node's
community behaviour. Role and purpose are local names persistently identifying boot
configuration of a node; these names unambiguously point to node's storage areas
where fully parametrised policy set and yet behaviour-independent etiquette rule sets
are stored.
The boot manager keeps the values of role (
Role
) and purpose (
Purpose
), passes
them for kernel initialisation and writes in a bootstrap log file the two values. After
kernel initialisation is done, the log file is appended by the refinement of role — pol-
icy and by the refinement of purpose — etiquette. There is no assumption that boot
configuration is conflict free, especially with regard to the agreement between
Pur-
pose
and
Role
; it is assumed however that role-defined
Policy
rules have higher prior-
ity than purpose-defined
Etiquette
. The assumption is motivated by the fact that
Eti-
quette
might need to be further refined (constrained) by policies depending on a situa-
tion in concern; the result of this refinement process is a set of e-rules — fully speci-
fied etiquette rules. Thus, e-rules and policy rules form a consistent and locally con-
flict-free set of rules, however only until the need for further refinement is identified.
Consider node
D
with a bootsrap purpose defined by E0 - E3, it is refined to a
bootsrap etiquette (14), with square brackets to denote optional extensions
D
E
1
→
1
⁄
y
•
[
1
⁄
y
]
D
1
,
D
2
,
;
D
E
2
→
y
D
1
•
1
⁄
y
D
1
+
[
y
D
2
•
1
⁄
y
D
2
]
+
[]
y
Y
1
+
+
[
y
Y
2
]
(14)
,
,
,
,
,
,
;
N
n
D
E
3
→
(
y
D
1
•
1
⁄
y
D
1
•
1
⁄
x
Y
)
•
1
⁄
t
Y
+
[]
,
,
,
where
y
D
1
,,
are variables to be instantiated with D's workflows as defined by
policies, note that these variables are generic functionalities (
g
1
,
g
2
,
... in Fig. 1);
y
Y
1
y
D
2
…
,
,
,,
are variables to be instantiated by similar workflows of not yet known
community member
Y
.
Each policy from a policy set is represented as <event: condition, action>, where
action is one of the node's functions, as in (6). A mapping from the policy set to the
set of workflows returns a list of workflow identifiers that are the values that instanti-
ate all variables in (14), thus the etiquette is refined by the mapping into a fully speci-
fied set of e-rules. In other words, the mapping function identifies for e-rules all
workflows that are managed by policies, i.e that are potentially changeable by con-
text.
y
Y
2
…
,
,
