to the value space of requirements in dimension y (although, of course, transform-ers may map characteristics from x to y). For example, it does not make sense to state whether or not characteristics {cx1, cx2, cx4} are “inside” the value space of ry2, although the figure suggests this is possible. Requirements can only be ap-plied to characteristics with which they are comparable – that is, based on their (dimension,type) pair, possibly after transformations by the comparator. As dis-cussed earlier in Section 5.4 any comparison operation with values which are not comparable must return false.
Figure 6.8: Two requirements in different dimensions, collectively defining a multi-dimensional value space.
6.3 Matching Semantics
The semantics of composing Ra with Rb are that every requirement in resource Rb must be matched (satisfied) by at least one characteristic in resource Ra. The de-fault match operation is equality (i.e. the comparator equal() or operator “=”). As before, the matching operation will utilise comparators which may perform transfor-mations on either the requirement or characteristic as part of the matching process.
The operator ⇒ is used to express this resource matching relationship. The equiv-alent in the functional form is asymatch(Ra, Rb), as shown in Equation 6.10, where
≡bool represents boolean equivalence, meaning asymatch() returns true when the ⇒ relation holds and false otherwise. This will be discussed further in Section 6.6.1.
Appendix C.12 also provides a formal definition of this and the other matching functions in Haskell.
Ra.chars ⇒ Rb.reqs ≡bool asymatch(Ra, Rb) (6.10) Matching is a special form of set comparison (see Section 5.6) where the super-set of characteristics (the second operand) is replaced with a requirement set from the base resource Rb. It is acceptable to have characteristics in the candidate resource Ra outside of the value space of this set, so long as at least one candidate resource characteristic is found for each base resource requirement. This is described formally in Equation 6.11 and can be expressed more succinctly as Ra ⇒ Rb, as shown in Equation 6.12. Ra.charsRb is the set of characteristics in Ra that satisfy the requirements of Rb. The universal quantifier ∀ in Equation 6.11 is essential. If it is not satisfied (i.e. if any requirement is not satisfied) then the matching characteristic set is empty. The idea is that the match set for a candidate composition contains the selection of characteristics from one resource which have satisfied the requirements of another resource. If the set of requirements have not been satisfied, then there is no match, and the match set must be empty. Partial match sets, which will be discussed in more detail later, provide a mechanism for capturing the set of characteristics which partially match a set of requirements. It is important to observe that a single requirement may define a range of acceptable values, while each characteristic defines at most a single value (unspecified characteristics are an exception to this).
Ra.chars ⇒ Rb.reqs ,
The semantics of a requirement are that any single characteristic in its value space will satisfy it, therefore a candidate resource with characteristics outside the base resource’s requirements set may be acceptable. Figure 6.9 illustrates this, showing CharsA1 to have additional characteristics in dimensions x and z, but for all requirements in ReqsB1, there is a characteristic in CharsA1. These same two resources are shown in Listing 6.2. At first appearance it seems the concept of
6.3 Matching Semantics 125
Listing 6.2: Two resources A and B which satisfy A ⇒ B.
“subset”, as presented in Equation 6.3, has been reversed. However, if another requirement set ReqsB2 is considered which includes a requirement w1 in addition to those in ReqsB1, then it can be seen that CharsA1 does not satisfy this requirements set. CharsA1 has no characteristics in the dimension w and therefore cannot satisfy the new requirement. This is illustrated in Figure 6.10. For this reason, the relation
⇒ is synonymous with the relation ⊆m (indicating a matching subset), where the subset symbol clearly indicates that – at least some of – the characteristics form a non-null subset of the collective value space of the requirement set. This property is essential when the issue of transitivity of the matching relation ⇒ is discussed.
CharsA1
Figure 6.9: Characteristic set CharsA1 is a matching subset of requirements set ReqsB1
CharsA1
z1
y1
y1
z1 z2
; ReqsB2
x1
dim x
w1
dim w
dim z dim y dim x
x1 x2
dim y
dim z
Figure 6.10: Characteristic set CharsA1 is not a matching subset of requirements set ReqsB2 because it cannot satisfy the requirement rw1.
6.3.1 Symmetric Matching
Given that both resources in a match operation may have characteristics and re-quirements, the concept of symmetric matching is defined in Equation 6.13. This is where Rais matched to Rb (i.e. Rasatisfies Rb’s requirements) and Rb is matched to Ra. This will be discussed in more detail later in Section 6.6. The symmetric match operator ⇔ is used to indicate this, and the equivalent function is peermatch2() as shown in Equation 6.14.
Ra⇔ Rb , Ra ⇒ Rb∧ Rb ⇒ Ra (6.13)
Ra⇔ Rb ≡bool peermatch2(Ra, Rb) (6.14)
6.3.2 Transitive Properties
Combining Equation 6.11 with the earlier discussion on characteristic and require-ment subsets (Sections 5.6 and 6.1), there are two important observations which will be used later in the discussion of resource templates in Section 8.2. These are the foundation of an efficient resource matching mechanism. The first concerns charac-teristic supersets. If Ra ⊆char Rb, then the characteristics of Rb are a superset of those in Ra. If Ra ⇒ Rx then the set of characteristics in Ra satisfies the require-ments of Rx. It is clear that a superset of those characteristics (namely those in Rb)
6.3 Matching Semantics 127
will also satisfy Rx, therefore Rb ⇒ Rx also holds. This is expressed in Theorem 6.3.1.
Theorem 6.3.1. If Ra⊆char Rb and Ra⇒ Rx then Rb ⇒ Rx Proof.
Ra ⊆char Rb ≡ Ra.chars ⊆ Rb.chars by equivalence (Eq. 5.14) Ra⇒ Rx≡ Ra.chars ⊆m Rx.reqs by equivalence (Eq. 6.12)
= Rb.chars ⊆m Rx.reqs by definition (Eq. 6.11)
≡ Rb ⇒ Rx by equivalence (Eq. 6.12)
The second observation is the requirement analog of this. If Rx ⊆rs Ry, then the requirements of Rx are more restrictive than those in Ry. If Ra⇒ Rx, then the set of requirements in Rx are satisfied by the characteristics of Ra, then it is clear that a less restrictive set of those requirements (namely those in Ry) will also be satisfied by Ra, therefore Ra ⇒ Ry also holds. This is expressed in Theorem 6.3.2.
Theorem 6.3.2. If Ra⇒ Rx and Rx ⊆rs Ry then Ra ⇒ Ry
Proof.
Ra ⇒ Rx ≡ Ra.chars ⊆m Rx.reqs by equivalence (Eq. 6.12) Ra.chars ⊆m Ry.reqs by definition of Rx ⊆rs Ry(equation6.8)
Ra⇒ Ry by equivalence (Eq. 6.12)
6.3.3 Partial Match
The idea of a partial subset, introduced in Section 5.6, has an analogue in the con-text of matching: a partial matcher. This is relevant when seeking to compose resources selected from a large pool, where the composition will possibly follow a two stage strategy, with the first stage evaluating compositions based on a limited set of dimensions, and a subsequent stage which evaluates the full set of dimensions or the remainder of the dimensions. Two examples of this are in the presence of dynamic properties, where the initial partial match considers only the static prop-erties and subsequent match operation utilises the dynamic dimensions, and with
resource templates where an initial partial match is done against a representative resource template which does not contain the full set of dimensions of the final
“actual” resource. The partial matching operation only operates on the set of di-mensions shared with both resources. This is indicated by ⇒p or in functional form as pmatch(). It is defined in Equation 6.15 where ReqsB/DA∩B indicates the dimen-sions not shared with A are hidden from B before the match is done (that is, the dimensions DA∩B are temporarily removed). Hiding these dimensions leaves only the desired requirements in B.
Listing 6.3 shows two abstract resources C and D where C ⇒ D. This is illustrated in Figure 6.11. Here some of the requirements specify a range. Note that cx3 and cz4 in resource C are not part of the matching set, but other characteristics in those dimensions satisfy the requirements.
Figure 6.11: Characteristic set RC.chars is a matching subset of requirements set RD.reqs
Listings 6.4 and 6.5 augment the example task and executor descriptions shown earlier in Listings 5.1 and 5.2 respectively. They add requirements to the resource descriptions. Here pentium ⇒ testjob1, meaning the executor pentium satisfies
6.3 Matching Semantics 129
<C >
< chars >
<x > 1 </ x >
<x > 3 </ x >
<y > 2 </ y >
<z > 2 </ z >
<z > 4 </ z >
</ chars >
</ C >
<D >
< reqs >
<x match = " <" > 2 </ x >
<y > 2 </ y >
<z match = " >" > 1 </ z >
<z match = " <" > 3 </ z >
</ reqs >
</ D >
Listing 6.3: Two resources C and D which satisfy C ⇒ D.
< task name = " t e s t j o b 1" >
< chars >
< n o r m _ c p u type = " hr " > 2 </ n o r m _ c p u >
< mem type = " MB " > 180 </ mem >
< disk type = " MB " > 500 </ disk >
</ chars >
< reqs >
< os > linux </ os >
< s o f t w a r e > python </ s o f t w a r e >
< mhz match = " >= " > 2500 </ mhz >
</ reqs >
</ task >
Listing 6.4: Requirements for a task resource
the requirements of task testjob1, however testjob1 ; pentium. This example will be discussed in the following sections.
< e x e c u t o r name = " p e n t i u m" >
Listing 6.5: Requirements for an executor resource