Applying reflection for distributed administrative environments Theo de Ridder Prometa bv. (position paper for Workshop W5 "Object-Oriented Reflection and Meta-level Architectures" of ECOOP'92) Introduction In traditional administrative systems the emphasis is on the data independence of large amounts of data. Data independence is typically obtained by using relative simple datamodels and centralised databases. But in spite of simple datamodels real information systems appeared hard to build, modify, and maintain. Many of the problems of information engineering are due to scale: a huge amount of data, a wide range of involved people, a complex surrounding world, and massive mainframes. PC's represent a reaction on the centralistic bureaucracy of a mainframe culture. PC's do not only give office workers control again over their own daily data with cheap off-the-shelf packages, but they also offer graphical userinterfaces that replace the jacket of built-in sequential interactions by the freedom of direct manipulation. However the negative sides of PC's are becoming more and more clear also. People never work completely independent, they have to communicate with others inside and outside their organisation. Isolated PC's have to be integrated in networks, and this integration reveals some fundamental weaknesses of PC's. The basic operating system is unsafe, the inter-operability of applications is low, and there are problems with sharing, exchanging, validating and protecting data. The threat of viruses is not an accidental, but a logical consequence of the unhealthy architecture of a PC. >From a technical viewpoint workstations based on an object-oriented technology may have the best capabilities to establish communicative administrative systems. They fill in different gaps between PC's and mainframes. However in practice we are confronted with large existing databases containing critical data on the one hand, and with an enormous installed base of rather simple and vulnerable PCUs on the other hand. In a simple integration of these extreme worlds a PC is used just as a database front-end, offering multiple screens for retrieving and updating records. A more powerful and yet pragmatic approach is offered by the client-server model. An object-oriented datamodel is a way to extend this client-server model uniformly from a complete database-server down to small individual dataobjects. We will discuss a reflective data-oriented approach to enrich existing administrative systems with extensible object capabilities for communication in distributed environments. The kernel of our solution is a small interpretative engine (ALOM) that handles symbolic datastructures, containing passive and active data.The first implementation of ALOM is implemented in C and incorporated as externals in HyperCard. Standard tools for administrative datahandling There is quite a range of tools available for manipulating administrative data. Representative categories of such tools currently used in practice can be summarised with: - relational databases Relational databases like Ingres and Oracle are widely used for business data. The emphasis is on maintaining consistency of multiple tables used by multiple users. From a linguistic point of view relational databases can be seen as SQL servers. Many sophisticated front-ends generating SQL scripts are available. - spreadsheets Spreadsheets offer a very successful metaphor for end-user computing of datavalues based on a 2-dimensional representations of data and formula. - small databases For managing personal data on PCUs a number of cheap databases are available with user interfaces like Tquery by exampleU that are suitable for non- experts. - form packages Form packages represent data as electronic forms, exploiting the high quality facilities of modern displays and printers. - card packages Packages like Hypercard combine aspects of datasets, forms, and objects into the paradigm of a card. The emphasis is on rapid and flexible navigation through sets of cards with active data and dynamic behaviour. Most standard tools are rather weak in representing active data, or supporting communication. Representing active data with scripts in languages like SQL or HyperTalk is far from what the end-user should experience, and the capabilities of simple formula of spreadsheets are too limited. Considering the communicative facilities for distributed environments we see two main lines: or the tool itself is in control of distribution through a shared dataconcept combined with locking, or the data is exported, transported and imported as flat text files containing records with field separators like tabs. The first solution not only requires that a network is more or less homogeneous, but also that the same (expensive) tool is available at any place. The second solution is very simple and universal. However the exchanged data is not protected, and not self-describing. Our approach is to extend the second approach towards a data-oriented string representation that is suitable for data as well as behaviour. A reflective objectmodel is used to offer an explicit mechanism for protecting the exposure of hidden data and for prevention the import of unwanted behaviour. We have build a small dedicated interpreter in stead of using a full-blown object-oriented programming environment. Therefore the result can be made available on any existing platform without demanding many extra megabytes. The ALOM architecture ALOM (Association List Oriented Machine) is an interpretative system based on association lists as a unifying datatype. The concept of an association list is used as a bridge between a record with a variable number of datafields and an object with extensible slots for behaviour. Like Lisp there is no difference in program and data representations in ALOM. Choosing the richer type of an association list in stead of a bare list makes the internal and external representation of data very close to what is perceived by a user manipulating data. Choosing association lists in stead of pure objects makes direct access the default mechanism and the hiding of internal structure something that has to be added explicitly. Basic types within ALOM are name, symbol, number, string, binary and expression. Expressions are made a basic type to enable the option to evaluate them in a host environment. The transformation between association lists and objects is similar to the transformation between names and symbols in a language like Smalltalk. The transformation does not change the internal structure, but only the access mechanism. The reflective object schema of ALOM is implemented with three metaclasses: Object, Class and MetaClass. Object implements the general characteristics of objects, Class the general characteristics of classes, and MetaClass implements the closure of all metaclasses. To enable specific adaptations to the default class mechanism each class is described by specific instance of MetaClass. Each class exports explicitly the attributes that are accessible within subclasses. Objects can be extended with slots not described by their class. Because such extra slots may contain behaviour, there is a danger of unwanted access to carefully hidden instance variables. The export mechanism for subclasses is therefore also applied for instances. This makes the schema of ALOM in fact a hybrid between a prototype and an inheritance. approach. An interesting result is that it is quite easy and natural tot create specific objects in a declarative way in stead of the usual procedural way of sending a TnewU message to a class. The interpretation procedure of ALOM is basically: import symbolic data, activate and manipulate data, export symbolic data. During interpretation all data remains available in a write-once stringspace. Lazy evaluation optimises symbolic references temporally into direct references. There is no general garbage collection, but garbage is implicitly removed during export. All communication with a host environment is done through name binding. There are three scopes for names: local variables of behaviours, instance variables of objects, and global variables of the interpreter. Some globals are assumed to be available in any context as global knowledge. Globals can also be used to install specific context dependencies, or to mask all side-effects of imported behaviour. Some opinions The ALOM system is still in development. The basic mechanisms and a user- interface are implemented in a prototype for validation and feedback. Considering the main goals of ALOM however some first conclusions can be made. In general the concept of reflection seems applicable to make data-handling in distributed environments more flexible and suitable for manipulation in the context of client-server models. More specific the contribution of reflection can be seen in the support of: - a minimal implementation; - a declarative way of creating objects; - an explicit representation of global knowledge; - a save transfer of active data. A main aspect of our approach is the use of reflection for the implementation of mobile active objects. In a more philosophical sense this can be interpreted as a way to exploit the concept of a virus in a constructive and controlled way. It is a virus seen as a small cooperative assistant to enhance remote server capabilities. If this type of a virus can be made successful it would be a nice indicator of the power of reflection. References [1] A. Anjewierden, J. Wielemaker, "Extensible Objects", KADS P1098 Technical Report C1.6, University of Amsterdam, 1989. [2] M.P. Wijers, E.G.J. Bogaart, "IGOD, Interactive Graphical Object Database", Report RP/dvm-89/5, Software Engineering Research Centre, Utrecht, 1989. [3] Th.F. de Ridder, "Direct manipulation of active forms as a base for asynchronous groupware", In: R.P.H. Hendriks, Proceedings Conference "Groupware '91, the potential of team and organisational computing", Software Engineering Research Centre, Utrecht, 1991.