Abstract
M.Sc.
In a society that is becoming increasingly reliant on information, it is necessary for information to be stored efficiently and safely. Database technology is used to store large chunks of information efficiently, while database security is concerned with storing information securely. More complex computer applications (CAD/CAM, multimedia and Groupware) led to then development of object-oriented programming, with object-oriented databases following shortly after. Object-oriented databases store the data of object-oriented systems efficiently and permanently. They provide a rich set of semantic structures that allows them to be used in applications where other database models are simply inadequate. In federations consisting of several interconnected databases, security plays a vital role in the proper management of information.
This work describes a Secure Distributed Object Environment (SDOE) infrastructure. It is designed to be implementation-oriented, on which strict theoretic prototypes such as SPOP (Selfprotecting Object Prototype) can be built. SPOP is a prototype of a secure object-oriented database and is based on the SPO database model of Olivier.
To describe federated database architectures (used by SDOE and SPOP), it is necessary to understand the architecture of federated database systems. Reference architectures for federated database systems are discussed first and a comparison is drawn between two prominent reference architectures. We proposed a generalised reference architecture based on these two architectures. created in order to make the use of object-oriented programming in a distributed environment as problem free as possible.
A marshal buffer structure will be discussed thirdly. The latter structure is used to contain procedure parameters during an RPC (Remote Procedure Call). Fourthly, the communications infrastructure necessary to support higher-level services is discussed. The infrastructure is implemented in Linux (a UNIX variant), and this approach has provided several interesting challenges.
The fifth discussion will deal with the requirements for a name service. A name service is necessary if objects were to be used transparently (without reference to their current locations in the federation).