Frequently, policies are constructed to consider the historical contexts of a computation. For exam- ple, access control mechanisms, such as Separation of Duties [135], Chinese Walls [40, 58, 106] and High Watermark [180] policies, all depend on the history of the computation in order to make deci- sions. Other types of policy, such as a reactive load balancing policy that bases its future scheduling decisions on the load of the resources utilised to date, can also rely on the contexts that a compu- tation has passed through. With condensed graphs, the context information is stored in the node names. Thus, in order to make an history-based decision for a condensed graph, the relevant con- textual information must be extracted using history-based reduction rules
A nodenhas a name(Snam d g f i o)whose attributes provide the names of execution contexts for domain (d), application graph (g), function (f), list of inputs (i) and list of outputs (o), respectively. The history reduction of the name of nodenis defined as
tupleElimination(Snam d g f (map tupleReduction i) o)
wheretupleEliminationandtupleReductionrepresent the application of tuple elimina- tion and tuple reduction rules, respectively. The tuple reduction rule is only applied (using themap
function) to the inputs. Themapfunction applies the function, in this casetupleReduction, in turn to each member of a list. This characterises history reduction as the inputs to a node specify the path that the execution has taken to this point.
Example 6.11 To perform a history based policy decision, we take the inputs to a node and reduce
their execution contexts. Figure 6.15 shows a representation of such a rule in the form of a function
saveDomHist.
This reduction rule defines that an execution context should contain the context(s) of the in- put(s). The relevant details, in this case the domain tuple, from the input tuple is extracted and
6.5 History-based Names 103
saveDomHist :: Name -> Name
saveDomHist (Snam a b c [(Snam v w x y z)] e) = (Snam a b c [v] e)
Figure 6.15: A simple Reduction Rule to retain domain history
integrated into the name of the current context. This replaces the domain tuple of the current con- text with the domain of the input. This reduction rule is applied to the input tuple of the name, that istupleElimination(Snam d g f (map saveDomHist i) o). This is a very simple example of atupleReductionreduction rule.
△
Example 6.12 A more useful example of this type of reduction rule can be seen in Figure 6.16.
In this example, the domain of the input replaces the domain of the current context only when the domain of the input is strictly “greater” than the domain of the current context. The saveDom
function acts as filter. If it is applied to each node in the graph in turn, then it ensures that the “greatest” domain is retained in every name.
saveDom :: Name -> Name
saveDom (Snam a b c [(Snam v w x y z)] e)
| a < v = (Snam v b c [(Snam v w x y z)] e) | otherwise = (Snam a b c [(Snam v w x y z)] e)
Figure 6.16: Domain ordering rules
In Section 6.3, we described how to define an ordering between names using the Ord rela- tion. In Figure 6.17, we explicitly define the ordering(Pnam "Alice")<(Pnam "Bob")<
(Pnam "Claire").
instance Ord Name where
Empty <= x = True
(Snam a b c d e) <= (Snam v w x y z) = (a <= v) && (b <= w) &&
(c <= x) && (d <= y) && (e <= z) (Pnam "Alice") <= (Pnam "Bob") = True
(Pnam "Bob") <= (Pnam "Claire") = True
(Pnam p) <= (Pnam q) = p == q
(Lnam l) <= (Lnam m) = l <= m
x <= y = x == y
Figure 6.17: Definition of theOrdrelation.
△
Example 6.13 A node that is to be executed in domainClairehas the name: (Snam (Pnam "Claire") (Pnam "MathGraph") (Pnam "MulFunction")
If we apply thesaveDomreduction rule to this name, then the reduced name becomes: (Snam (Pnam "Bob") (Pnam "MathGraph") (Pnam "MulFunction")
[((Pnam "Bob") (Pnam "MathGraph") (Pnam "DivFunction") [] [])] [] )
This means that the node will now be executed in domainBob. Such reduction rules could be used to help ensure data. For example, results of executions, is not sent to inappropriate domains, or computations executed on inappropriate resources. However, enforcing such requirements is the responsibility of the relevant policy enforcement mechanism. △
6.5.1 Naming Grid Submissions
The computational Grid allows the sharing of compute resources between different organisations. WebCom, using condensed graphs, can be used to create Grid applications [124]. As Grid appli- cations execute across many domains, it is important to ensure that application components can be referred to properly wherever they execute.
Example 6.14 A national compute Grid is organised in a tiered structure. In order to support system
policies, the name of context where every job (graph) is submitted must be retained in every node name. The Grid resources are structured to allow job submission at various layers in the overall architecture, shown in Figure 6.18.
Regional Local Local Regional Local Local Regional Local Local
National
Portal
Figure 6.18: GRID Portal Structure.
In this architecture, jobs can be submitted at national, regional or local portals. The specific policy requirement is that a computation launched at a regional or local portal must not move up the architecture, even though the portals are interconnected. For example, when a job is submitted on a regional portal, it can move down to local resources underneath that regional portal, but not up to the national portal or across to other regional portals. We call this a “ceiling” restriction and can specify it in a naming policy.
6.5 History-based Names 105
This requirement can be described by a reduction rule that maintains the submission portal as part of each node’s name. For example, the travel agent condensed graph application shown in Figure 6.3 can be submitted to a Regional portal. The name of the portal becomes part of the name of every node in the submitted graph.
(Snam
(Lnam ["Grid Ireland","Munster","UCC","Compute Cluster"]) (Pnam "eBookers")
(Lnam ["eBookers","RentCar"]) [(Lnam ["eBookers","BuySeat"])] [(Lnam ["eBookers","Print"])] )
Figure 6.19: The name for theRentCarnode, executing on a particular GRID resource. Normally the domain portion of a name is defined as the computational resource that is execut- ing, will execute, or has executed, the node, when this is known. When making a naming policy decision about a node, the ceiling reduction rule is applied to the name of the node.
saveDom :: Name -> Name
saveDom (Snam a b c [(Snam v w x y z)] e)
| a < v = (Snam v b c [(Snam v w x y z)] e) | otherwise = (Snam a b c [(Snam v w x y z)] e)
Figure 6.20: Ceiling Reduction Rule
The tuple reduction rule,saveDom, shown in Figure 6.201, is an example of such a reduction rule. When applying this rule, we assume that the names we are applying it to are of the correct form. When used with an appropriate definition of theOrdrelation, this rule ensures that the parent graph’s domain is maintained within the node name and thus the ceiling is never exceeded. The
Ordrelation would be similar to the relation shown in Figure 6.17, but with Local < Regional <
National △
6.5.2 Web Services Policy
Up to this point, we have seen how reduction rules that can be applied to names to ensure existing information is retained. However, this is only one application of such rules. Reduction rules can also be used to inject new information into a name.
Example 6.15 Airlines have business relationships with specific hotel and car rental companies.
For example, in Ireland the Hertz car rental company gives specific discounts to customers who fly with either Aerlingus and Ryanair; in contrast, Easyjet discounts Europcar. Another example is when flying into London on an Irish airline, customers are recommended to stay in one of the
Jury group’s hotels. We can represent these types of relationship using reduction rules in the web services graph shown in Figure 6.3.
selectCarCo :: Name -> Name
selectCarCo (Snam a b c [(Snam v w x y z)] e)
| ((v == (Pnam "Aerlingus")) && (c == (Pnam "RentCar")) = (Snam a b c [(Snam (Pnam "Hertz") w x y z)] e) | ((v == (Pnam "Easyjet")) && (c == (Pnam "RentCar"))
= (Snam a b c [(Snam (Pnam "Europcar") w x y z)] e)
| otherwise = (Snam a b c [(Snam v w x y z)] e)
Figure 6.21: Airline Car Rental preference rules
Figure 6.21 defines such a reduction rule. The selectCarCoreduction rule matches the domain that an input node has executed in with known airlines. If the current node is aRentCar
node, then it updates the domain name of the current node to that of the airline’s car rental partner. If an unknown airline is selected, then no change is made to the node name.
△
This example identifies some interesting possibilities. As the naming model is outside of the condensed graph model, it is possible to use the naming system to effect where nodes in the graph are scheduled. WebCom can use these names to help determine where to schedule nodes. The flexibility of the naming system is of the order of an additional programmable system outside of the condensed graph model. The question now arises: are these programmable side-effects an advantage or a hindrance to the condensed graph model? Traditionally in the condensed graphs model, side effects are frowned upon. However, a number of features in individual applications rely on side effects. For example, a side effect can be used to support concurrency in condensed graphs [134]. Another example of a common side effect is how files are transfered between resources for certain condensed graphs applications. This is also provided outside of the model.