Requirement
−match:str *
*
Figure 7.1: Resource object model. A resource consists of characteristics, require-ments, and preferences. Requirements are a sub-class of characteristics, and preferences are a sub-class of requirements.
7.2 Preference Semantics
While requirements allow a decision on a possible composition through matching, preferences allow a process of ranking alternative valid compositions. The matcher supplies the ranker with a set of resources and the preferences to base the ranking on.
It may also specify how many resource compositions need to be returned, allowing the ranker to stop once that has been achieved, although this discussion will not dwell on such implementation optimisations. An alternative use of a ranker is to screen resources prior to matching, then feed the “most preferred” resources from a pool to the matcher. This is an area for future research and is not discussed further here. In any case, preferences are applied to resources and resource compositions independently of requirements – only resource characteristics are considered when ranking based on preferences.
All preferences must have a rank attribute with a numeric value. Lower values indicate a higher rank. Preferences are processed in rank order, and applied to the characteristics of the initial resource set. For any tied preference ranks, the ranker may make an arbitrary and possibly random choice of order between tied preferences. The preference name specifies the characteristic dimension to which the preference applies. As with characteristics and requirements, the ranker is free to apply transformations to the dimensions of preferences or characteristics and their
7.2 Preference Semantics 149
values when performing the ranking operation.
7.2.1 Ranking Algorithm
The first iteration of the ranking algorithm operates on the full set of resources supplied to the ranker, and considers only the single highest rank preference. Sub-sequent recursive iterations use lower rank (or “next-tied-rank”) preferences in order, and are only applied to sub-sets of resources which were ranked identically by the earlier iterations. If there remain tied resources after all preference ranking has been applied, the ranker may arbitrarily or randomly order the tied resources. Algorithm 7.1 describes the Ranking procedure, although ignoring the “top-N” optimisation parameter which allows early termination once N “best” resources are found.
Listing 7.1 illustrates a single task resource and five executor resources. For simplicity, there are no requirements (meaning all executors will match the task), and only the task specifies selection preferences. It can be seen that the first priority is to order the executors by cost, from low to high (i.e. preferring lower cost executors). The second priority is to order the executors by mhz (which, in this example, represents processor speed and is a rough measure of relative performance), from high to low (i.e. preferring faster CPUs). The first preference based on cost will result in a resource ordering of: h{B, C}tied, E, A, Di. Only executors B and C tied, therefore the next ordering based on mhz will only be applied to them.
This results in the sub-ranking of: hC, Bi, and therefore the final executor resource ordering would be: iC, B, E, A, Dh. D comes last as it is not ranked by either of the two task preferences.
7.2.2 Preference Ordering Operators
The match attribute, which is mandatory for preferences, specifies the ordering of resources, while the optional preference value (and associated type attribute) act as a modifier on that ordering. Note that “ordering” may only be evaluating set membership of a resource (e.g. “prefer resources located in France”). Table 7.1 describes a base set of preference operators and their interpretation both with and without a value.
The ranking operators are very similar to the requirements matching compara-tors of Table 5.2, however with different interpretations of specified and unspecified values. In addition, two distance operators close and far are added. Most of these operators require the ranker to have a concept of ordering in the value space (<, >=,
Algorithm 7.1 Resource ranking algorithm, using a hierarchical preference set.
Require: {R} resource set Require: {p} preference set
Ensure: hRiranked is ordered according to the preference set function Rank({R}, {p})
if {R}.length <= 1 then
⊲ One or fewer resources in set, therefore no need to rank
hRiranked← {R}
else if {p} =∅ then
⊲ No preferences, therefore nothing to base ranking on
hRiranked← {R}
else
⊲ Ranked result set of resources is initially empty hRiranked←∅
⊲ Sort preferences {p} in ascending order according to their rank hpisorted ← Sort({p}, key=p.rank, order =“<”)
⊲ Sort resources according to top preference (may produce tied resource sets) ptop ← hpisorted.head
h{Rtie}ii ← Sort({R}, key=ptop.dimension, order =ptop.match)
assert ∪ih{Rtie}ii = {R} ⊲ This is a partition of {R}
assert ∩ih{Rtie}ii =∅ ⊲ All resources in {R} are in exactly one {Rtie}i set foreach {Rtie}i in h{Rtie}ii
⊲Recursively rank tied subset {Rtie}i
⊲based on remaining preferences hpisorted.tail hRiiranked ← Rank({Rtie}i, hpisorted.tail)
⊲Append ranked list {Ri}ranked onto final result {R}ranked ← hRiranked.append(hRiiranked) end foreach
end if
return hRiranked
end function
7.2 Preference Semantics 151
< task name = " p r e f j o b" >
< prefs >
< cost rank = " 1 " match = " <" / >
< mhz rank = " 2 " match = " >" / >
</ prefs >
</ task >
< e x e c u t o r name = " A " >
< chars >
< cost > 15 </ cost >
< mhz > 3800 </ mhz >
</ chars >
</ e x e c u t o r >
< e x e c u t o r name = " B " >
< chars >
< cost > 10 </ cost >
< mhz > 2400 </ mhz >
</ chars >
</ e x e c u t o r >
< e x e c u t o r name = " C " >
< chars >
< cost > 10 </ cost >
< mhz > 3000 </ mhz >
</ chars >
</ e x e c u t o r >
< e x e c u t o r name = " D " >
< chars >
< si2k > 2.0 </ si2k >
</ chars >
</ e x e c u t o r >
< e x e c u t o r name = " E " >
< chars >
< cost > 12 </ cost >
</ chars >
</ e x e c u t o r >
Listing 7.1: A task specifying a set of preferences to sub-select from a group matched executors.
Comparator Sym. Meaning Meaning
(value unspecified) (value specified)
less than < prefer lower prefer resources closer but less than preference value, then any resources with equal or higher values
less than <= prefer lower prefer resources closer but less than
or equal or equal to preference value, then
those with higher values greater than > prefer higher prefer resources closer but
but greater than preference value, then those with equal or lower values greater than >= prefer higher prefer resources closer but greater
or equal than or equal to preference value,
then those with lower values
equal = prefer resources prefer value
with dimension
not equal = prefer resources prefer any other value
without dimension
close >< n/a prefer resource values closer to
preference value
far <> n/a prefer resource values further from
preference value
Table 7.1: The base set of preference operators for resource ranking, and their interpre-tation with specified and unspecified values.
> and >=), or a measure of distance (<> and ><). Two (= and !=) only require the ability to evaluate set membership. It is left to the specific implementation to de-termine a definition of ordering and distance, as well as behaviour in the event that the ranker, for a particular dimension, cannot order or determine distance between characteristics.