Call-out Bracket Methods in Timor

J. Leslie Keedy, Klaus Espenlaub, Christian Heinlein and Gisela Menger, University of Ulm, Germany

ARTICLE

Abstract
This paper extends the concept of qualifying types by describing how their implementations can include not only bracket methods which are applied when a method of a target object is invoked, but also further "call-out" bracket methods which can be applied to invocations by the target object of the methods of other objects. This additional technique can be used for example to provide enhanced synchronisation in qualifying types, as an aid to confining the activities of an object, and as a means of providing parallel activities associated with the sending and receiving of information, e.g. encryption and decryption, data compression.

1 INTRODUCTION

In an earlier paper we have described the concept of qualifying types, i.e. types whose objects (known as "qualifiers") can dynamically qualify the behaviour of objects of other types (known as "targets") by means of bracket methods [5]. As presented in that and earlier papers [2-4], qualifying types permit modules to be written in the programming language Timor¹ which can, for example, provide such general services as synchronisation, protection and logging. The bracket methods which carry out such activities are applied to the incoming invocations of a target object's methods. A technique for statically incorporating qualifying types into other types was presented in [6].

The present paper extends the concept of qualifying types by describing call-out bracket methods as a new category of bracket methods. These function in a similar way to those of normal bracket methods with the difference that they are applied to the outgoing calls which an object might make to the methods of other objects. Call-out brackets can for example be used to release the semaphores acquired on entry to an object when this calls the methods of further objects. They can also be used to implement information confinement policies for objects or to journalise communications with other objects.

The bracketing of outgoing calls from a source object might also be coupled with a complementary bracketing of incoming calls to a target object to provide services which require parallel activities when passing and receiving information, such as encryption and decryption, data compression and expansion, etc.

It is assumed that readers are familiar with the basic idea of qualifiers [5, 6], so that we do not here repeat information about the structure of Timor nor how qualifiers work in general. In the current paper we refer to the bracket methods described in the earlier papers as call-in bracket methods.

2 CALL-OUT METHODS: AN OVERVIEW

As a first illustration of the idea behind call-out methods we define a type whose instances are able to qualify target objects such that whenever an instance method of the target is invoked mutual exclusion is guaranteed and whenever the target invokes any other object the mutual exclusion is released, but this is then claimed again as the outgoing call returns to the method of the target. Here is a type definition:

and now an implementation:

As this is not a paper on synchronisation we refrain from a discussion of the usefulness of such a module, except to point out the obvious: that a thread which uses such a qualifier has no guarantee that the state of the target will be the same before and after it calls out to another object.

From the viewpoint of the design of the Timor language we see that call-out methods are listed in a callout clause, which is similar to the qualifies clause for call-in bracket methods (as described in [5]). In the above example all calls out of the target to any other object are handled by the same call-out code.

The definitions of the bracket methods for incoming and outgoing calls have the same syntax. The difference in their meaning is illustrated in Figure 1:

Call-in bracket methods "catch" a client's method invocation to the target (qualified) object, and begin executing their own code as defined in the qualifies section. If the call-in method executes a body statement the target method is then invoked. If the target itself then calls some other object (the "call-out" object), the qualifier's call-out bracket method(s) (defined in a callout section) "catch" this invocation on the way out. If the call-out bracket method then executes a call statement the call-out object is then called (or the next call-out bracket is activated). After the called object returns the call-out method continues execution at the statement following the call statement, and when this exits a return is made to the target object, or to the call-out bracket from which it was invoked.

A client object and a target object can of course both be qualified (usually by different qualifying objects, although we will see later that it sometimes makes sense for the same qualifier to qualify both). If a client object has a qualifier with call-out methods these methods are executed before the call-in methods of a qualifier associated with the target (cf. Figure 2):

3 DEFINING CALL-OUTS FROM OBJECTS

Like call-in qualification, call-out qualification can be defined to apply either to any interface or to a specific view or type interface. However, whereas the counterpart of the bracket methods for call-in qualification are the methods of the object with which the qualifier is associated, the counterpart of the bracket methods for call-out qualification are the methods of other objects which it invokes. Since the type of an object is not normally the same as that of the objects which it invokes, there is no implied type relationship between call-in and call-out types. Thus for example call-ins might be applied to a specific view or type while the call-outs might refer to any type, or a qualifying type might define only call-ins or call-outs.

An Example of Standard Call-ins and Call-outs: Monitoring

Following a callout any clause only standard call-out methods, i.e. methods defined to qualify all methods of the called object, or more specifically its op (writer) or enq (reader) methods, can be defined. Such qualification can be useful not only to support synchronisation (as illustrated in section 2) but also for example to monitor the activity of a target object, e.g. by maintaining counts of calls:

with an implementation:

An Example of Standard Call-outs: Information Confinement

A qualifying type need not define call-in bracket methods. To illustrate how call-out methods alone can be usefully defined we consider how simple information confinement policies might be enforced, beginning with a type Confined which ensures that its target object does not make any calls whatsoever to other objects (and therefore cannot release information, as Timor strictly enforces the information-hiding principle [8]):

Although this type would be useful in many circumstances, it would often be desirable to enforce confinement policies which allow specific calls to be made. In this case the type Confined can be expanded, using a variant of normal inheritance which allows bracket methods to be inherited. In Timor the programmer has a choice between subtype polymorphic type inheritance (using the keyword extends) and interface inheritance without polymorphic implications (keyword includes). Here we choose the latter to define a qualifying type which only allows its target to make calls to the print method of a specific printer object. First we define a view which includes the permitted print method, then the qualifying type:

This type contains two callout sections, one of which is inherited from Confined. The new callout section, which is more specific and therefore has priority, defines what happens if an object containing the view Printer is called by the target. In this case the standard call-out bracket method (for all) is effective if the more specific method print has not been invoked. The overall effect is that only print calls to the correct printer are permitted. The inherited callout section (for any) defines what happens if objects of any (other) type are called, i.e. the object cannot make calls to objects other than the printer. Here is an implementation:

The built in expression calledObject returns a value of type ObjId, which is a special type whose values are unique object identifiers. It can be used in both call-in and call-out bracket methods to determine which object is being called. Timor supports several such pseudo-identifiers which allow a bracket method to determine the environment in which it is working. However, the protection mechanisms provided by Timor are not the subject of this paper, and are therefore not described here in detail.

The effect of this qualifier is that the only call-out which a target object can make is a print call to a defined printer. Hence it is confined to using this printer. With call-out qualifiers in Timor any confinement policy known to us, including for example the Bell-LaPadula model [1], can be straightforwardly implemented.

Combining Call-in and Call-out Brackets: Communication Services

As we have seen in the examples of synchronisation (section 2) and monitoring (section 3) it is sometimes useful for a qualifying type to include call-in and call-out brackets which are designed to be applied to the same target object (cf. Figure 1). However, it can be equally useful in some cases to define a qualifying type which has call-out designed to operate in one target and call-in brackets designed to operate in another. Examples of this kind of communication service include compression or encryption of data in a call-out bracket of a sender object complemented by decompression or decryption in the call-in of the same call in a receiver object, cf. Figure 3.

To illustrate this we define that text can be transmitted as a parameter to a method transmit, which is defined in a view that can be incorporated into many types.

Here is a skeletal implementation:

In the example it is assumed that the same encrypting object is used to bracket both the sender and the receiver. If the call is a local method call this could be useful, for example to hide the content of the message from later call-out and call-in brackets which might potentially contain trojan horses. In the case of a remote procedure call in a conventional environment, the desired effect could be achieved by having separate instances of the qualifier at the different locations, each initialised with the same keys and using the same algorithm. A symmetrical encryption algorithm is assumed, but alternative encryption qualifying types could be developed which use asymmetrical encryption algorithms.

4 USING CALL-IN AND CALL-OUT BRACKETS DYNAMICALLY

Qualifying types can either be associated with individual target objects dynamically, by placing them in a List<:Qualifier*:> [5] or bracketing can be defined statically in type definitions [6]. In this section we consider how the dynamic case is affected by call-out brackets.

Using Both Call-in and Call-out Brackets on a Target

In the normal case all the bracket methods (for call-in and for call-out) of a qualifier which appears in a List<:Qualifier*:> are applied to the target as appropriate. Thus an object can be instantiated as follows if it is to be exclusively synchronised when its methods are called and the synchronisation released when it makes nested calls (cf. section 2):

Using Call-out Brackets to Implement Pipes

In some cases qualifiers may only have call-out brackets, for example to transform the output of an object for use as the input of another object in a manner resembling Unix pipes. Suppose for example that the method printOutput of objects of type Atype sends a text file to a specific printer by invoking the latter's print method (described earlier in the view Printer). If the user wants to reorganise the output, e.g. by first sorting it, then truncating the first 50 lines, he might use two call-out qualifiers (of types Sorter and Truncater), which in their call-out brackets for print manipulate its Textfile parameter as appropriate. To set up the "pipe" he could use the following code:

He could then create an object of type Atype, which is qualified by these qualifiers:

As will be explained in section 6, the order in which call-out brackets are executed is the reverse of their order in the qualifier list. To print the sorted and truncated text file he then simply invokes the printOutput method of myObject:

This example uses a list literal to associate the qualifiers with the object to be qualified. This is appropriate if myObject is used once only. However, if myObject is intended for frequent use with different qualifiers in a "pipe" then it could be set up as follows:

Subsequently myList could then be changed by inserting new qualifiers and removing existing ones, as described in [5].

The advantage of using call-out methods in conjunction with myObject, rather than similar call-in brackets of the Printer object invoked, is that each user can trim his own output as he wishes, without affecting other users of the Printer object.

Rules for Selecting Call-in and/or Call-out Brackets on an Individual Basis

As we saw in section 3, the call-in and call-out brackets of the same qualifier may need to be associated with different targets (e.g. a sender and a receiver) and it must therefore be clear what bracket methods should be applied to a target, the call-in methods, the call-out methods, or both. The technique adopted to achieve this in Timor is based on the idea that a reference for a qualifying type (i.e. a subtype of the type Qualifier) has two boolean values associated with it indicating whether the call-in and call-out brackets of the referenced qualifier are "active". This is the "normal" state of these indicators when a reference is declared and initialised to null, but bracket methods can be deactivated by using the arrow operator -> in a reference expression. If the arrow appears before the reference expression then the call-out brackets are deactivated (and the call-in brackets remain active), while its use following the expression deactivates the call-in brackets (and indicates that the call-out brackets are active). The arrow operator can only be used once in a reference expression.

It is an error, detected at compile-time, if the arrow operator is used with any reference which is not for a qualifier, or for a qualifier reference which does not have the kind of brackets which are to remain activated. Once deactivated for a reference, bracket methods cannot be reactivated in association with the currently bound qualifier.

Assignment statements and parameter initialisations which have a reference with deactivated bracket category in the source reference result in the same restriction being set on the target reference, i.e. a restriction is not a permanent property of a reference as such, but only in so far as it is bound to a particular qualifier. Thus if an assignment statement has on the left side a reference with deactivated call-out brackets and the reference being assigned has deactivated call-in brackets, the result is that the reference on the left side becomes identical with that on the right side, without a run-time error occurring.

It is not considered to be an error to deactivate a bracket method category which has already been deactivated.

With this background, the Timor rules for dynamically selecting call brackets can now be formulated as follows:

a) If a qualifier has both call-in and call-out brackets, but only its call-in bracket methods are to be applied to a particular target, the programmer deactivates the call-out brackets by prefixing the qualifier's reference with the operator ->.

b) If a qualifier has both call-in and call-out brackets, but only its call-out bracket methods are to be applied to a particular target, the programmer deactivates the call-in brackets by placing the operator -> after the qualifier's reference.

c) If the operator -> is not used, all the bracket methods (call-in and/or call-out) associated with a qualifier in a List<:Qualifier*:> are applicable to a target.

To heighten the clarity of programs it is recommended that bracket methods are deactivated as they are inserted into qualifier lists.

Using the Rules for Communication Services

A user wishing to send an encrypted message (cf. section 3) could set up the sender and receiver objects as follows:

where the type Sender is defined as follows:

with an implementation such as:

and the type Receiver includes the view Transmission.

Using the Rules to Mask Out Call-in or Call-out Brackets

The above rules can be used not only to control communication services. They can also be used simply to mask out either the call-in or call-out brackets of a qualifier. For example a user wishing to monitor only the calls from an object using CallCounting (cf. section 3) might proceed as follows:

The arrow operator can also be used in a parameter to the insert method of List, but only in the context of insertion into a qualifier list, e.g.

5 STATIC TYPE DEFINITIONS WITH CALL-OUT BRACKETS

The syntax for declaring qualifiers statically for a new type was described in [6], a knowledge of which is assumed in this section. In the normal case, if a qualifier which has call-out brackets in its type definition appears in a static type declaration the call-out brackets are applied in an analogous way to their dynamic use. In this section the various possibilities, including restricting the use of call-in or call-out brackets are illustrated.

Static Call-in and Call-out Brackets for the Same Target

To define a Thing which is statically bracketed by the call-in and call-out brackets of ReleasableMutex is trivial:

Static Call-out Brackets

Users can feel more confident that their information is secure if a print spooler is available which has been statically confined to accessing only a specified printer. For this purpose we assume the existence of a type Spooler, which extends the Printer view (i.e. has the method print as defined in section 3). In a new type ConfinedSpooler this could be statically confined by an instance of the type PrinterConfined (also defined in section 3) as follows:

This might be implemented along the following lines:

Masking out Brackets

Masking out either the call-in or call-out brackets statically (in the following example to apply only call-out brackets) can be achieved as follows (using a static version of the example in section 4):

Here is an implementation:

In the case of static declarations the arrow operator is associated (as a prefix for call-in brackets, as a suffix for call-out brackets) with the type name of the qualifier in both type definitions and their implementations. This can only occur in a qualifyingList (see the EBNF syntax definition in section 3 of [6]). A compile time check is carried out to ensure that the type in question has bracket methods of the type indicated.

Notice that the use of an arrow in association with a type name is not to be understood as a property of the type being declared, but indicates merely that any qualifier being assigned (in an implementation) to the static qualifier will automatically have the corresponding bracket category deactivated (if it is not already deactivated, in the case of a reference).

As references for external qualifiers can be passed into the maker of a statically qualified type [6], the arrow operator can also be associated with a type name (with the same meaning) in the parameter list of such a maker, but only where the type definition contains a qualifyingList with an entry for the same type and with the same use of the operator. This rather unusual rule has two advantages. First, it allows the invoker of a maker to see the restriction without having to examine the code of an implementation. Second, it allows the condition to be checked at compile time (at the point in the client code where the maker is invoked).

Communication Services

We now define an encrypting communication service in which sender and receiver are statically bracketed. In this example we confine the sender to using the Transmission view (assuming that a type TransmissionConfined has been defined by analogy with PrinterConfined in section 3) and the receiver to printing out the message to a defined printer). Whereas the confinement bracketing can be defined "by value", the encryption is defined by reference cf. [6], allowing the sender and receiver to share the same qualifier. We begin with the sender:

The receiver definitions are as follows:

Other cases, such as the simulation of Unix pipes, present no problems in static definitions, although to define pipes statically would defeat their purpose from the viewpoint of flexibility.

6 SCHEDULING MULTIPLE QUALIFIERS

As was discussed in detail in [5], call-in bracket methods in a qualifier list are applied to the target object from left to right, i.e. the first qualifier in a qualifier list (or in the static case in a qualifyingList [6]) is applied, if it has a matching bracket method, then the second qualifier in the list, etc. In contrast, call-out qualifiers are applied in the reverse order of the list, i.e. from right to left. This has the effect that when a qualifier contains both kinds of bracket methods, these are nested as illustrated in Figure 4:

In this example the first entry in the qualifier list is the qualifying object 1, followed by the qualifying object 2.

7 RELATED WORK

The relation between qualifying types with call-in bracket methods and other work was discussed in detail in [5, 6]. Here it remains for us to discuss work related to call-out brackets. And here we have the problem that no such work is known to us.

What can be said however, is that there is clearly a close relationship between a call-out bracket associated with a client and a call-in bracket associated with its target. Thus it might appear that some of the examples in this paper can be handled by techniques which we have previously compared with call-in brackets. For example, combining call-in and call-out brackets for a single target (cf. ReleasableMutex in section 2) can be simulated using aspect oriented programming (AOP) techniques (cf. [7]). This is possible because AOP in effect allows program text to be cut and pasted into a class. Hence it can be effected at arbitrary points in a text, either where an object starts executing (cf. call-in) or where it calls another object (cf. call-out). But call-out brackets associated with one object (e.g. a sender) and call-in brackets associated with another object (e.g. a receiver) cannot be provided as a single AOP "module" in the way that this is possible in Timor. In addition, the other comments made in our comparison with AOP in [5] still apply, e.g. regarding the restrictions arising from (a) not distinguishing between op and enq methods, (b) operating at the source or bytecode level and thus affecting all objects in a class, (c) not being able to associate a qualifier with a group of objects, (d) not treating qualifier methods as independent methods but as new methods of the class, etc.

A significant advantage of call-out methods is that they can be different for different callers of the same destination object. This is important for example in simulating Unix pipes. On the other hand it is sometimes desirable, as when confining a printer spooler, to ensure that the same call-out bracket methods (which guarantee the confinement) are statically defined and cannot be changed by different users.

8 CONCLUSION

The call-out bracket technique extends the notion of qualifying types as described in earlier papers (e.g. [4-6]) to allow the calls out of a target module to be bracketed in a similar manner to the calls into the target. This considerably extends the usability of qualifying types, for example by allowing more complex synchronisation and monitoring policies to be defined and implemented. It also opens new possibilities in the area of computer security, particularly in providing a technique which allows such protection features as information confinement policies and modular encryption techniques to be implemented at the programming language level². It also introduces the possibility of providing a flexible Unix-like pipe mechanism at the programming language level.

ACKNOWLEDGEMENTS

Special thanks are due to Dr. Mark Evered and Dr. Axel Schmolitzky for their invaluable contributions to discussions of Timor and to the ideas which have been taken over from earlier projects. Without their ideas and comments Timor would not have been possible.

Footnotes

¹ www.timor-programming.org

² This parallels our work in the operating system area, where the SPEEDOS operating system (cf. www.speedos-security.org) supports the notion of bracket methods for call-ins and call-outs at the system level.

REFERENCES

[1] D. E. Bell and L. J. LaPadula, "Secure Computer Systems: Mathematical Foundations," Mitre Corp., Bedford, Ma. ESD-TR-73-278, 1973.

[2] J. L. Keedy, M. Evered, A. Schmolitzky, and G. Menger, "Attribute Types and Bracket Implementations," 25th International Conference on Technology of Object-Oriented Languages and Systems, Melbourne, 1997, pp. 325-338.

[3] J. L. Keedy, K. Espenlaub, G. Menger, A. Schmolitzky, and M. Evered, "Software Reuse in an Object Oriented Framework: Distinguishing Types from Implementations and Objects from Attributes," 6th International Conference on Software Reuse, Vienna, 2000, pp. 420-435.

[4] J. L. Keedy, G. Menger, C. Heinlein, and F. Henskens, "Qualifying Types Illustrated by Synchronisation Examples," in Objects, Components, Architectures, Services and Applications for a Networked World, International Conference NetObjectDays, NODe 2002, Erfurt, Germany, vol. LNCS 2591, M. Aksit, M. Mezini, and R. Unland, Eds.: Springer, 2003, pp. 330-344, http://link.springer.de/link/service/series/0558/papers/2591/25910330.pdf.

[5] J. L. Keedy, K. Espenlaub, G. Menger, and C. Heinlein, "Qualifying Types with Bracket Methods in Timor," Journal of Object Technology, vol. 3, no. 1, pp. 101-121, http://www.jot.fm/issues/issue_2004_01/article1, 2004.

[6] J. L. Keedy, K. Espenlaub, G. Menger, C. Heinlein, and M. Evered, "Statically Qualified Types in Timor," Journal of Object Technology, vol. 4, no. 7, pp. 115-137 http://www.jot.fm/issues/issue_2005_9/article5, 2005.

[7] G. Kiczales, E. Hilsdale, J. Hugonin, M. Kersten, J. Palm, and W. G. Griswold, "An Overview of AspectJ," ECOOP 2001 - Object-Oriented Programming, 2001, Springer Verlag, LNCS, vol. 2072, pp. 327-353.

[8] D. L. Parnas, "On the Criteria To Be Used in Decomposing Systems into Modules," Communications of the ACM, vol. 15, no. 12, pp. 1053-1058, 1972.

About the authors

		J. Leslie Keedy recently retired from the position of Professor and Head, Department of Computer Structures, University of Ulm, Germany, where he lead the Timor language design and the Speedos operating system design groups. His email address is keedy@jlkeedy.net. His biography can be visited at http://www.jlkeedy.net/biography_short.php
		Klaus Espenlaub completed his Ph.D. in Computer Science at the University of Ulm in 2005. Currently he works as a research assistant in the Department of Computer Structures at the University of Ulm. His research interests include secure operating systems, protection mechanisms and computer architecture. His email address is espenlaub@informatik.uni-ulm.de.
		Christian Heinlein received a Ph.D. in Computer Science from the University of Ulm in 2000. Currently, he works as a scientific assistant in the Department of Computer Structures at the University of Ulm. His research interests include programming language design in general, especially genericity, extensibility and non-standard type systems. His email address is heinlein@informatik.uni-ulm.de.
		Gisela Menger received a Ph.D. in Computer Science from the University of Ulm in 2000. Currently she works as a scientific assistant in the Department of Computer Structures at the University of Ulm. Her research interests include programming language design and software engineering. Her email address is menger@informatik.uni-ulm.de.

Cite this column as follows: J.L. Keedy, K. Espenlaub, C. Heinlein, G. Menger: “Call-out Bracket Methods in Timor”, in Journal of Object Technology, vol. 5, no. 1, Januar - Februar 2006, pp. 51-67, http://www.jot.fm/issues/issue_2006_01/article1

Previous column