webcom.core.naming.NameGenerator

Node names can be generated either a priori by the developer of the graph or, more typically, when the name is needed to make a security decision about the node. Generating names for nodes entails

public class SimpleReductionRule extends ReductionRule {

public SexpList reduce(SexpList Name) {

//Extract Function tuple from Name and return this as a new // S-Expression.

SexpList newname = new SexpList(extractFunction(Name)); return (newname);

} }

Figure 6.23: The implementation of a simple reduction rule’s reduce(n)

examining the node at a particular point in time and extracting the relevant details.

The name of a WebCom node is returned by its name generator. The name generator examines an instance of a condensed node and extracts the relevant details. Name generators are used to create fresh names for nodes. When WebCom loads a graph for execution, theNamingManagerModule identifies the nodes without names in the graph and generates names for those nodes. A node’s name is generated using an internal condensed graph examiner class. This examiner can investigate the internals of a loaded condensed graph on a “read-only” basis.

As nodes in condensed graphs refer to each other, their names will also contain references to other node names. In Section 6.2.2 we discussed the potential for self-referencing names. As each node’s destination can be another node operand, the name of the destination node must also be included in the original node’s name. However, as the destination node will also have a reference to the original node, care must be taken to avoid recursive loops. When a node name is generated, this situation must be addressed.

The solution is to apply specific reduction rules when generating the name of a node’s operand and/or destination. We use, respectively, theOperandNameGeneratorclass and theDestination- NameGeneratorclass to accomplish this goal. These name generators are in fact special reduction rules that are only called by the name generator. Their specific task is to prevent name recursion. For example, the simplest approach to preventing name recursion is to apply tuple elimination rules to the inputs and/or outputs of a node, removing any reference to the current node.

public WebComName generateNameForNode(Node node, ReductionRule reduxrule, String Domain)

public void setOperandGenerator(OperandNameGenerator operandGenerator) public void setDestGenerator(DestinationNameGenerator destGenerator)

NameGeneratorclasses are called byNamingManagerModulesto generate new names for nodes. The application interface for this class is relatively simple, with the most significant method being theng.generateNameForNode(n,r,d)performing the name generation. Name gen- eration can be potentially application specific. In most cases application requirements are handled by customised reduction rules. In Chapter 8, we will examine some specific WebCom applications.

6.6 An API for Naming in WebCom 109

webcom.core.naming.DestinationNameGenerator

Destination name generators generate representive names for the destination of a node. When a node’s name is generated, it is important to prevent recursion in the destination. In Section 6.2.2, we identified the problem of self referencing names. Destination and operand name generators address this problem by explicitly preventing recursion. These name generators act as reduction rules that are applied to the names of destination nodes to derive a non-recursive representation of that node. However, they are called name generators as these reduction rules are only used during name generation. DestinationNameGeneratorsare exclusively called byNameGenerators.

protected String generateNameForDestination(CondensedGraph cg, int DestinationNodeID);

The dng.generateNameForDestination(g, did)is the only major method in this class. As it is only called from a name generator, condensed graph internal representation is used to identify the specific destination node. The reference version of this class simply returns the function tuple of the destination node’s name, such as shown in Figure 6.23. This is equivalent to applying the haskell reduction rule functiondestReduxRuleshown in Figure 6.24.

retainFunc :: Name -> Name retainFunc (Snam d g f i o) = f destReduxRule :: Name -> Name

destReduxRule (Snam d g f i o) = (Snam d g f i (map retainFunc o))

Figure 6.24: A destination reduction rule retaining the function tuple

In this example, the retainFuncfunction is used instead of applying the domain, graph, input and output tuple elimination rules. However, as destination name generators use the inter- nal condensed graph API to determine the nodes in question, standard reduction rules cannot be substituted.

webcom.core.naming.OperandNameGenerator

Operand name factories are the corollary to destination name factories. They are specific reduction rules that address the potential for mutual recursion in the names of operands. OperandNameGen- eratorsare also exclusively called byNameGenerators.

protected String generateNameForOperandNode(CondensedGraph cg, int OperNodeID); public String generateNameForOperandValue(Object Input);

As with destination name generators, the main method in an operand name generator is the

ong.generateNameForOperandNode(cg, oid) method. This method investigates the operand node and extracts a representation of the operand node.

Unlike Destinations, operands may, when the operand node has executed, consist of the result of the operand node. In condensed graphs, a result can be anything, ranging a simple numerical value to complex objects such as a spreadsheet. When an operand has returned a result, the operand name generator can use theong.generateNameForOperandValue(i)method to extract a representation of this result and use this to refer to the operand.

In some cases, it is more important to specify where the operand result came from rather than the value itself. In Section 6.5, we described some history based naming policies. The operand name generator is an important part of such policies. In such cases, the operand name generator has the ability to look at the historical path the operand has taken to this point. A representation of this historical path can then be used as the name of the operand. This capability can be used, for example, to enforce history-based security policies, such as high watermark or Chinese wall [40] policies.