The SCHEMESTATION project involves designing and implementing a prototype of a new distributed agent-oriented operating system carrying the name of the project.
The main use of the finished prototype is to be scientific research. The prominent objective of creating the prototype is to provide an environment for experimenting with distributed agent-based operating systems.
This document is structured as follows.
Some of the terms appearing in this document are defined in Terminology specifications.
The SCHEMESTATION operating system is a proposed agent/actor-based distributed operating system featuring:
In this project, a prototype of this operating system is built on the top of a UNIX environment. More specifically, a simulator is designed that runs as a set of UNIX user-level processes. The UNIX system to be used for development is not specified. However, the system should be easily portable to most major UNIX systems in order to make the system useful for research in heterogenous environments.
Any tools available are allowed to be used during development. However, it must be possible to build the resulting, final system using standard or other common UNIX tools also. Common GNU tools are included in this set, for example the GNU C compiler and GNU make.
The general architecture of the SCHEMESTATION operating system is presented here. The unit of execution is an actor (or agent). Actors are contained in domains. Inside one domain every actor must have a unique address (name). This restriction does not apply to actors in different domains. Because actors inside one domain share an address space, domains are expected to correspond often to logical or physical computers or CPUs. One workstation running the SCHEMESTATION operating system could be one domain.
The actors communicate using asynchronous message passing. Communication can happen inside one common domain (intra-domain communication) or across domain boundaries (inter-domain communication). These two forms of communication do not have any fundamental differences, though.
Actors are able to migrate from one domain to another. Migration is transparent. This means that other actors communicating with the migrating one do not need to know about the migration act nor to respond to it in any special way. This all is illustrated in Fig. 1.
Communications between domains are cryptographically secured. This is not enough, however, for ensuring a secure computation environment as some domains might be malicious or just untrustworthy. For this reason trust relations can be maintained between domains, and these relations can be used as a basis for deciding upon certain acts. For example, in Fig. 2 three domains are shown which have the following trust relations: Domain 1 trusts Domain 2 to be a good source and good target for migration (i.e. it is safe to move actors to run in Domain 2, and also to receive actors from Domain 2 to be executed locally). Domain 2 trusts Domain 1 similarly. However, between Domain 2 and Domain 3 migration can happen only from Domain 2 to Domain 3 as Domain 3 does not trust Domain 2 to be a good target for migration; nor does Domain 2 trust Domain 3 to be a good source. These trust relations are use by the domains to control actor migration.
The developed prototype must contain the following functionality:
There are actually two user interfaces in the system. First, there is the interface between the user and the simulator; second, there is the simulated interface between the user and the SCHEMESTATION system (i.e. the simulated terminal).
The choice of the nature of both of these interfaces is free as long as the other requirements specified are fulfilled.
The project is about creating a simulator, and the performance issues concerning simulators are to some extent secondary. However, the following rough limits for acceptable system performance are set:
The issue of usability is divided into two subrequirements.
The simulator itself should be reliable and work correctly in normal working conditions (i.e. fail only when there is a hardware or software failure somewhere else affecting the system).
Actors failing to perform their tasks due to logical errors in the algorithms they use or due to invalid byte code instructions etc. should be handled by the simulator as specified by the operating system design.
As the resulting tool is directed towards scientific use, the quality of detailed documentation is important.
In particular, the following documentation is required to exist in some form in addition to full source code:
The system should be easily portable to most major UNIX systems. However, the portability need not to be tested for all of them. Parts of the software that are most likely to have system dependencies should be isolated to modules of their own in order to make their modification as easy as possible, should portability problems nevertheless occur.
The most important of the goals of this project are enumerated below in the order of precedence.
Achieving this goal can be observed during the project by examining the chosen design principles and the written source code. Discussions with the client are held to ensure that the client, who is a computer scientist, is able to comprehend what has been done and agrees with it.
This goal is tried to achieve by (1) using a well-defined coding policy, (2) making the system design modularly and (3) discussing with the client.
It is easy to observe whether or not this goal has been achieved at the later parts of the project. If this goal fails, the whole project can be seen as failed. The main method for ensuring that the goal will be achieved is to keep care of that the project schedule is not much late. Small lateness does not endanger this goal, as more project work has been scheduled after this main functionality has been reached. Lateness endangers the work at the end of the project, but not this goal as it should be achieved before the end stages.
This goal is tried to achieve by completing the main parts of the system, even if some kind of failure causes the project not to achieve all of its goals.
This goal is a high-level quality and usability goal. During the project progress towards achieving it can be observed by examining the implemented and emerging user interfaces of the simulator and the [cross-]compiler. It should be possible to create new types of actors without knowing about the details of the compiler and the simulator.
This goal is tried to achieve by keeping user interfaces as simple as possible, or at least by allowing the user to use a simple interface if he or she wishes so.
Achieving this goal can be observed, before the project ends, by measuring the performance of the prototypes created during the project. It is assumed that the final performance of the system does not differ drastically from that of the prototypes due to spiral-like development process. Thus whether or not this goal will be reached can be observed from the prototypes. The problem is that some parts of the system are prototyped only at the later stages of the project. This problem must be solved by using conservative estimates of the complexity of the subparts of the system that are not yet implemented when the prototype performance is measured.
To elaborate, it is planned that first the operating system kernel is implemented and then a simple user environment and example programs are created on the top of the kernel. Thus the subparts that do not exist at first are those that are programmed on the top of the kernel and use the SCHEMESTATION virtual machine. If the complexity of these high-level subparts can be approximated then the resources they consume can be calculated by projecting the approximations onto the known behaviour of the virtual machine and the other parts of the kernel system.
This goal is tried to achieve by (1) using algorithms with low asymptotic complexity whenever feasible, (2) optimizing the most time-critical parts of the implementation to an extent and (3) documenting how the practical performance of system is affected by the underlying hardware configuration.
This goal is achieved if there exist understandable documents that (1) describe the system so that it is possible to use it without knowing the details of the implementation and (2) describe the implementation so that it is possible to understand parts of it without knowing the details of the other parts.
This goal is tried to achieve by intertwining the technical documentation process with other development.
This goal is assumed to be relatively easily achieved. It is tried to achieve by (1) creating the system so that system dependencies can be easily handled, and then (2) finding out the portability problems via testing and then fixing them before the final product is released.
This goal is a consequence of all the previous goals, plus that its licencing policy allows it to be used for educational use. This is tried to ensure by giving all the rights to the product not only to the project members but also to Helsinki University of Technology, which is a body providing education.
Achieving this goal can be observed during the project by measuring the overall happiness of the project members. It is tried to achieve by (1) not imposing unrealistic requirements on the project members and (2) everybody trying to do his best, and a bit but not too much more.