|
|
1 Introduction |
|
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.
- We first give an overview of the system in Section 2.
- The functional aspects of the system are then presented in Section 3.
- User interfaces are discussed next in Section 4.
- In Section 5, non-functional features are then specified.
- Section 6 concludes the report with a quality plan.
|
1.1 Terminology |
|
Some of the terms appearing in this document are defined
in Terminology specifications.
|
2 Overview |
|
The SCHEMESTATION operating system is a proposed agent/actor-based
distributed operating system featuring:
- persistent actors
- transparent migration of actors
- high level of abstraction
- trust-based security structure
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.
|
2.1 SCHEMESTATION operating system architecture |
|
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.
Fig. 1. Actors and domains in SCHEMESTATION
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.
Fig. 2. Trust relationships between domains
|
3 Functionality |
|
The developed prototype must contain the following functionality:
- It can be run in a supported UNIX environment.
- It can be used to simulate multiple domains and the communications
between them. Some objectives are to be able to simulate communication
faults easily and to observe the amount of data transferred between
distinct domains.
- It is possible to observe the internal workings of a domain
to some extent (system debugging).
- Domains are able to run multiple actors that execute byte code
instructions.
- The memory model for individual actors is a list-structured heap.
Every actor has one heap that is read and modified by the
byte code program.
- Actors are able to send and receive messages.
- There is simulation for some I/O facilities, at least for
a text-based terminal, in order for the user(s) to be able
to communicate with the system.
- A cross-compiler exists for generating byte code programs from
a dialect of Scheme.
- The notions of trust relationships and cryptographic authentication
are considered and support for them exists.
- Actors are persistent over multiple simulator executions
as long as the simulator is started and
terminated using procedures defined by the system designers.
- Some example applications are developed in order to demonstrate
system use. These applications could include:
- some kind of a shell
- electronic mail system between SCHEMESTATION users
- distributed games
- compiler running in the SCHEMESTATION system itself
|
4 User Interface |
|
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.
|
5 Non-Functional Features |
|
|
5.1 System Performance |
|
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:
- It must be possible to run hundreds of actors inside one domain.
- It must be possible to simulate tens of mutually communicating
domains simultaneously.
|
5.2 Usability |
|
The issue of usability is divided into two subrequirements.
- It must be able for an average computer science student to learn
to use the system in reasonable time.
- A computer scientist should be able to understand the design
and implementation details of the system in reasonable time,
and to extend and modify the simulator when necessary.
|
5.3 Failure Situations |
|
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.
|
5.4 Documentation |
|
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:
- System installation instructions
- System design overview
- System design details
- System implementation documentation
- Compiler manual
- Compiler design documentation
- Instructions for extending and modifying the simulator when necessary
- Description of the example programs distributed
|
5.5 Portability |
|
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.
|
6 Quality Plan |
|
The most important of the goals of this project are enumerated below
in the order of precedence.
- That the implementation of the system is easily understandable
for computer scientists, and for at least some
computer science students.
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.
- That the system is able to simulate actors running asynchronously,
and that a user is able to observe the results of this simulation.
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.
- That programming new actors and incorporating them into the system
is moderately easy.
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.
- That the performance of the system is on a level that the system
is practical to use.
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.
- That the system design is well documented.
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.
- That the system is portable to major UNIX systems.
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.
- That the system has some value as an educational tool.
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.
- That during the project most people have fun for most of the time.
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.
|