Franz J. Hauck, 03/21/95, Jürgen Kleinöder, 11/93

PM Object Model

The major goal of PM is the design of an adaptable operating system. To support this goal we defined two design criterions:

Uniformity The object model should be uniform. There should not be two, or even more, different kinds of objects with different semantics as seen in several object-oriented systems: e. g. Argus or Clouds-Distributed Eiffel.
Orthogonality Orthogonal features of the object model should be described independently. This criterion allows a maximum of reusability, because all features can be adapted without affecting others.

The object model consist of an application system which defines application objects, of a distribution system which defines the configuration of the application and its distribution, and of a coordination system which defines the coordination of application objects.

Application System

The basis of the PM object model is similar to Emerald. Objects are the smallest entities for distribution. Nearly everything is an object [Hau93c]. There is only one kind of objects, even Integer values are first class objects. Objects contain references to other objects. References are bound to named variables which are part of an object. Methods are named components of objects. A method can be invoked when another invocation has access to a reference to the object which contains the method.

Method invocations can be synchronous (the caller waits for the result of the invocation) or asynchronous (the caller can go on with its computation and can claim the results later). Asynchronous invocations are attached to handles. Handles support a blocking and a non- blocking wait operation as well as direct and blocking access to the results of the invocation (Wait-by-Necessity) [RiK94]. Up to now, there is no possibility of using multicasts or different protocols of interactions by application programmers, but the handles are similar to meta-objects and could be an entity to place user defined protocols in the future.

The computations can be annotated by three orthogonal computing guarantees: tentative, progressive, and isolated. These represent the three found orthogonal dimensions of the ACID acronym known from transactional computing (ACID Fission) [Eir94].

Inheritance is modelled as a special aggregation relation which can be typed and dynamically bound like normal object references. This allows the distribution of an object of a subclass on the boundary between sub- and superclass. Additionally it is possible to change base classes in a type-safe way [Hau93b]. This is important for maintenance of class libraries.

Distribution System

In contrast to Emerald, distribution is described in a separate distribution language [Fäu93]. Thus, distribution can be changed without affecting the application program. Distribution is inferred by relations between objects. Possible relations are called collocated (objects should be placed on the same node), dislocated (objects should be placed on different nodes), and unspecified. A separate system called Distribution System controls these relations. It allows the definition of initial relations between the application objects. The dynamic behavior of distribution is described by cooperations. Cooperations are part of the distribution system. They are instantiated and deleted by events. Possible events are begin and end of invocation, creation of objects etc. A cooperation changes a defined set of relations between certain objects dynamically during its lifetime. Thus, migration of objects can be controlled by cooperations.

A second set of relations is used to describe the protection domains of objects. Collocated objects are placed in the same virtual address space, dislocated objects have to have their own address space. The protection domains are orthogonal to distribution.

Coordination System

As well as distribution, concurrency control is separated from application programming as much as possible. A Coordination System defines the concurrency control inside of the application objects. Coordination objects of the Coordination System are attached to application objects and control the internal activities of the attached objects (cooperative coordination) [Pru94]. It is possible to attach one coordination object to several application objects. Coordination objects may interact with each other to control a set of objects in a defined way.