next up previous
Next: Exception handling Up: Implementation issues Previous: Implementation issues


Composing programs

Programs are made out of statements and variables. In a BATCHING Program, each statement corresponds to a ConcreteControlStructure or concrete Command. Variables are instances of a ConcreteVar class. To build a program, clients declare an object of the Program class and invoke its constructor method.

Ideally, the client side for an instance of BATCHING would be exactly like the code of a client making direct calls to the server; i.e. like a client not using BATCHING at all. In practice, ConcreteControlStructure constructors (which are functions) are used. Thus, code in the client for a Program looks like the code that the user would write without using the pattern. Command objects are not declared; they are built with functional constructors.

To allow usage of expressions within the Program, subclasses inheriting from an Expr class can be provided (see figure 6). Expr is a functional service representing an expression, and can be used as a function within expressions.

Figure 6: Expression Hierarchy
\begin{figure}
\epsfig{file=expr.eps} \end{figure}

Program variables are stored in a table. They contain initial values as well as intermediate values and results of the program execution at the server side. To build that table, the programmer of the client must declare an object of the class VarTable. When variable objects are constructed, they are constructed and stored in that table with an initial value, if any, and their mode in, out, inout, or local. When a variable table is sent to the server, only values of in and inout variables have to be copied to the server. After the execution of the program, out and inout variables are sent back to the client. Variables on the table can be consulted and modified on both sides.

The adequacy of the implementation of the table depends on the context of the pattern instance. For example, it can be interesting in an operating system to implement the table as a chunk of raw memory, while a remote server could represent it as a heterogeneous list of concrete variables.

BATCHING programs have the advantage that most of type-checking is done at compilation time. Note that server calls are type-checked, because the parameters of constructors of server call commands are typed.

Revisiting our example, the code for the cat program is shown in figure 7. In the figure, constructors are functions that build objects within the program. In this example, SeqCtrlStruct and WhileCtrlStruct are ConcreteControlStructures of the language. Open, Close, Read, and Write are classes derived from Program and clients invoke their constructors to let the Program issue calls into the server. Program variables are stored in the vars variable table. In this case, f1, f2 and car are local variables, so their mode is local.

Figure 7: Program for Cat
\begin{figure}
\begin{center}
\begin{verbatim}VarTable vars;
Program program;
In...
...lose(f2)
));
execute(program, vars);\end{verbatim}\end{center}\par\end{figure}

Finally, note that the concrete instruction set used through this section is just an example. Any other one, like a byte-code based program could be used too. Instruction sets suggested in the pattern are very simple compared to the ones used in other systems. For instance, $\mu$Choices [9] and Aglets [12] use a Java interpreter. A Modula-3 compiler is used in SPIN [4], and NetPebbles [11] uses a script interpreter.
next up previous
Next: Exception handling Up: Implementation issues Previous: Implementation issues
Francisco J Ballesteros
1999-09-22