SUPPORTING PERSISTENT RE-LOCATABLE OBJECTS IN THE ANSA ARCHITECTURE N. Davies, G. S. Blair and J. A. Mariani Distributed Multimedia Systems Group, Department of Computing, Lancaster University, Bailrigg, Lancaster, LA1 4YR, U.K. telephone: +44 (0)524 65201 e-mail: nigel,gordon,
[email protected] ABSTRACT The ANSAware distributed systems toolkit provides facilities for object creation and invocation in heterogeneous distributed environments. ANSAware is being used at Lancaster as part of a broad platform to support the development of distributed multimedia applications. However the platform, and specifically ANSAware currently provides no support for object persistence or re-location. This paper describes the implementation of a number of enhancements to ANSAware which provide the necessary support. The approach taken, termed management by exception, is evaluated with regards to its performance and failure characteristics.
1. Introduction This paper describes work carried out as part of the Zenith project 1 aimed at producing a platform to support distributed multimedia design environments. Such environments, which include office information systems, geographical information systems and integrated project support environments, have a number of common requirements including the need to manipulate highly structured and possibly distributed multimedia objects. The problems of providing a platform to support such activities are compounded by the need to provide high performance (in order to support the more demanding media types) whilst working within the proposed ODP (Open Distributed Processing) architectural framework (to support applications in a heterogeneous environment) [Blair,91]. The programming interface for the platform being developed at Lancaster is based on work from the ODP community and in particular from the ANSA/ISA project [ANSA,89a]. All services are treated as objects, i.e. encapsulations of state and operations defined on that state. This allows programmers to interact with services in a uniform manner, irrespective of their implementation (hardware or software) and location (on a workstation or on specialised multimedia hardware). Services may be distributed, in which case communications between services is via remote procedure call. We call this collection of services the base service platform (figure 1).
1 Zenith is a DTI/SERC funded collaborative project involving Lancaster University, the University of
Kent and British Telecom Labs. Internal Report No: MPG-92-04, Computing Department, Lancaster University, Bailrigg, Lancaster, LA1 4YR, January 1992. Submitted to Software Practice and Experience.
Management
End Users Design Environments Complex Objects Base Services Figure 1 : The Zenith Architecture The base service platform implementation is based on the ANSAware software suite [ANSA,89a]. This provides a partial implementation of the computational model described above allowing the creation and invocation of objects in a heterogeneous environment. Extensions to the basic ANSAware software have been made to support group invocation [Coulson,91a], and new services have been added to support multimedia devices and communications [Coulson,91b]. On top of the base services platform additional services are implemented which provide specialised support for design environments. These services include facilities for specifying, creating and manipulating complex multimedia objects [Kemp,91]. Using both base and extended services a number of applications have been written. These include a multi-party audio and video conferencing facility, a video jukebox and a multimedia presentation system. However ANSAware, and hence the base service platform does not at present provide support for object persistence or re-location, two features required to support the large number of objects generated by design environments. In this paper we focus on extensions to ANSAware, and the implementation of a number new services which together provide the required support. The remainder of the paper is structured as follows. Section 2 describes in some detail the ANSA architecture, and the ANSAware software suite. Section 3 discuses our approach to modelling object persistence and re-location in Zenith. Section 4 then describes the implementation of this model using enhancements to ANSAware and a number of new services. Section 5 presents an evaluation of our approach. Section 6 contains plans for future work in this area and section 7 some concluding remarks.
2. The ANSA Architecture The ANSA/ISA project aims to define a complete framework for the design and construction of distributed systems. The scope of the architecture is wide and takes on board the full range of issues from overall business objectives to detailed implementation choices. The complexity inherent in this broad view is managed by partitioning the architecture into five viewpoints: enterprise, information, computational, engineering and technology. The work described in this paper focuses on the computational and engineering viewpoints which are described in more detail below. 2.1. ANSA computational model In the ANSA computational model, all interacting entities are treated uniformly as objects, i.e. encapsulations of state together with operations defined on that state. Objects are accessed through interfaces which define named operations together with constraints on their invocation. Interfaces are first class entities in their own right, and references to them may be freely passed around the system. Interface references are also the sole entities which may be passed to and from operations as arguments and results. Operations may return different combinations of types of interface reference in different circumstances: these are known as alternative terminations.
2
Services are made available for access by exporting an interface to a trader. The trader therefore acts as a database of services available in the system. Each entry in this 'database' describes an interface in terms of an abstract data type signature for the object and a set of attributes associated with the object. A client wishing to interact with a service interface must import the interface by specifying a set of requirements in terms of operations and attribute values. This will be matched against the available services in the trader and a suitable candidate selected. Note that an exact match is not required: ANSA supports a subtyping policy whereby an interface providing at least the required behaviour can be substituted. Finally, once an interface has been selected, the system can arrange a binding to the appropriate implementation of that object and thus allow operations to be invoked. In Zenith all objects appear as ANSA services, including both 'system' and 'application' created objects. 2.2. ANSA engineering model The engineering viewpoint sets out specifications, guide-lines and concepts by which an abstract computational model may be realised at a systems level. A.P.M. Ltd. have released a software system, known as ANSAware, which is a partial implementation of the computational model. In particular it does not enforce the computational model requirement that all operation arguments and results are interface references: most arguments and results are passed by value. In engineering terms, the ANSAware package is a fairly complete implementation of the ANSA engineering model as described in the ANSA Reference Manual [ANSA,89a]. To provide a platform conformant with the computational model, the ANSAware suite augments a general purpose programming language (usually C) with two additional languages. The first of these is IDL (Interface Definition Language), which allows interfaces to be precisely defined in terms of operations as required by the computational model. Interface definitions are processed to produce client and server stubs for each operation. The second language, prepc is embedded in a host language, such as C, and allows interactions to be specified between programs which implement the behaviour defined by these interfaces2. Specifically, prepc statements allow the programmer to import and export interfaces, and to invoke operations in those interfaces. These statements are preprocessed to form calls to the appropriate stubs. Stubs/ Interpreter
Stubs/ Interpreter
Sessions
Sessions
Execution Protocols
Execution Protocols
Message Passing Services
Message Passing Services
Figure 2 : The layers involved in an ANSA invocation In the engineering infrastructure, the binding necessary for invocations is provided by a remote procedure call protocol known as REX (Remote EXecution protocol). This is layered on top of a generic transport layer interface known as a message passing service 2 In the future these two languages will be replaced by a single language called DPL (distributed
processing language). This new language should not be confused with earlier versions of prepc which were also referred to as DPL.
3
(MPS) (figure 2). A number of additional protocols may be included at both the MPS and the execution protocol levels and these may be combined in a number of different configurations. The infrastructure also provides an interpreter which supports lightweight threads within objects in order that multiple concurrent invocations can be dealt with. All the above engineering functionality is collected into a single library, and an instance of this library is linked with application code to form a capsule. Each capsule may implement one or more computational objects. In the UNIX operating system, a capsule corresponds to a single UNIX process. Computational objects always communicate via invocation at the conceptual level but, as may be expected, invocation between objects in the same capsule is actually implemented by straightforward procedure calls rather than by execution protocols. ANSAware currently runs on a variety of operating systems platforms including UNIX, VMS and MS-DOS.
3. Modelling Object Persistence and Re-Location in Zenith A key aim of the Zenith project is to provide a platform which is flexible enough to support a full range of design environments. The requirement for flexibility arises as a result of two distinct characteristics of the project: the broad range of design environments which it is trying to support, and the need to cater for multimedia information. We consider each of these requirements in more detail below. There have been a number of attempts to build object management systems which support either a single design environment (e.g. integrated project support environments [Moore,88]) or a range of design environments (e.g. [Thompson,89], [Hornick,87], [Fisherman,87]). Most of the projects in the latter category have recognised the need for a flexible approach to service provision in order to meet the differing requirements of design environments. However, most of these systems allow the selection of services at configuration or compile time rather than supporting the dynamic selection of services at run-time. This ties the system into supporting only the design environments for which it was configured, often making evolution, or the provision of support for multiple design environments difficult. Incorporating multiple media types into a system requires a flexible approach to object management. Objects of different media types are likely to have very different characteristics. For example, an object which contains a sequence of colour video is likely to be several tens or hundreds of megabytes in size and require specific storage, processing and display hardware. Compare this to an object which represents a simple integer counter. A system which wishes to support this wide range of objects must be able to manage each object, or group of objects as a separate unit. However, whilst careful management is necessary in such an environment [Anderson,90] it is important to ensure that management overheads are not sufficient to cause an unacceptable reduction in the performance of the system. The approach to providing object persistence and re-location described in the remainder of this paper attempts to address these issues. Dynamic selection of services at run-time is supported through the use of the trading concept (see section 2.1). Flexibility is provided by maintaining a clear separation between mechanisms and policies. Mechanisms are provided by autonomous objects via their interfaces. Policies are implemented by manager objects which use the available mechanisms to influence the behaviour of objects. Finally, management overheads are reduced to a minimum in normal circumstances. 3.1. Basic management interface All Zenith objects support a basic management interface. This interface comprises the following operations:
4
Passivate: Zenith objects may be in one of two states, either active or passive. Passivate is used to signal an object that it is about to loose its thread of control. The object must save its state in a form from which it may subsequently continue executing, and surrender its resources. Activate: This is used to restore a passivated object. The object retrieves its state and continues execution from the point at which the passivate operation was invoked. Note that activation is implicit in invocation (see section 3.2). Checkpoint: This is used to record significant stages in the objects history. To avoid making policy decisions within the object, the client of the checkpoint operation must supply an empty checkpoint container into which the server can checkpoint its state. This allows maximum flexibility: not only can clients specify the required behaviour of the checkpoint object (fault-tolerant, immutable etc.), they also have full control over previously created checkpoint objects allowing them to determine (for example) the length of checkpoint history to maintain. AssumeCheckpointState: AssumeCheckpointState is used to instruct an object to assume a state that has previously been checkpointed. This mechanism may be used for providing objects with fault tolerance, supporting transaction schemes, or for transfering state between replicated group members. Move: Objects in Zenith are said to reside on nodes3. Individual nodes may be grouped into clusters. Move causes an object to move from its current node to a specified destination node. The object is passive for the duration of the movement. Using this basic management interface objects may be controlled either by an application, or by a management component of the Zenith system. Note however that objects are viewed as autonomous entities. Whilst the basic management interface can potentially be used to control the object, it is the object itself which chooses whether or not to service these requests. 3.2. Persistence and re-location transparency Once objects have been moved or passivated using their basic management interface their invocation becomes a potentially complex task. Invocation in a distributed system may encompass a number of distribution transparencies (see table 1) [Rodden,91]. These transparencies can be used to selectively mask out certain details of the underlying system from the application or user.
3 At this stage it may be assumed that a node is equivalent to a physical site such as a workstation,
though this is not necessarily the case (see section 6.3)
5
Transparency Location
Central Issue
Result of Transparency
The location of an object in a distributed environment.
User unaware of the location of services.
Access
The method of access to objects in a distributed system.
All objects are accessed in the same way.
Migration
The re-location of an object in a distributed environment.
Objects may move without the user being aware.
Concurrency
Shared access to objects in a distributed environment.
User is unaware of other users accessing shared data.
Replication
Maintaining copies of an object in a distributed environment.
System deals with consistency of copies of an object.
Partial failure in a distributed environment.
Problems of failure are masked from the user.
Failure
Table 1 : A Summary of Distribution Transparencies Whilst the ANSA architecture encompasses all of the transparencies listed above, the current implementation of ANSAware fully supports only access transparency. Location transparency is provided in a limited sense; users are not aware of the location of the service they invoke. However, since the interfaces services export contain the server's address, servers must remain fixed at their location in order that clients can invoke them. Complete location transparency would allow clients to locate servers even if they move between invocations. This is what we term re-location transparency, or full location transparency (the effects of movement during object invocation is covered by migration transparency [ANSA,89a]). We can extended the list of transparencies above to include the notion of persistence transparency. As discussed in section 3.1, objects may be in one of two states, either active or passive. Given that we anticipate a system constructed from many objects, with each active object mapping onto a UNIX process, at any given point in time many objects will be passive. However, we wish to present to the programmer a view of a world composed entirely of active objects, i.e. a world composed entirely of objects ready to receive invocations. This we term persistence transparency, the central issue in which is the activation and passivation of objects, and the result of which is that all objects appear active at all times. Hence, we may assume that if we wish to provide persistence transparency, activation must be implicit in invocation.
4. Implementation Our implementation of persistence and location transparent invocation consists of two distinct aspects. Firstly, the basic ANSAware invocation mechanism has been extended. This is discussed in section 4.1. Secondly, a number of new services have been added. These are described in section 4.2. 4.1 Extensions to the ANSAware invocation mechanism The current ANSAware engineering realisation of interface references (as described in section 2) is as record variables (C structs):
6
typedef unsigned long ChannelId; typedef unsigned char InterfaceId [20]; struct{ unsigned long int length; unsigned char *data; } CapsuleAddress; struct{ unsigned long int type; CapsuleAddress capsule; ChannelId channel; } AddressRecord; struct{ unsigned long int length; AddressRecord *data; } AddressHint; struct{ InterfaceId id; AddressHint ah; } InterfaceRef;
The address record contained within the address hint represents the physical location of the server object at the time it exported (created) the interface reference. In current versions of ANSAware this may be only a single address (despite the data structure definition). However, by extending this system such that clients previously maintaining a single address instead maintain a list of address hints [ANSA,89a], a substantial increase in flexibility is gained. For example, the first of these addresses could be the physical address at which the client believes the service object resides. All things being equal, invocation then simply involves sending a message to this address. However, the server would be free to move to any of the addresses in the address hint. The client would simply try each address in turn until the server was located. Still further flexibility can be gained if address hints can be dynamically updated to contain new address records when an invocation fails. This is the approach used to provide object persistence and location transparency in Zenith. Clearly such an approach requires some intelligence in the client. In fact the client's actions when attempting to invoke a service object (using an appropriate address list) may be summarised as follows; done = FALSE; while ((done==FALSE) and (there are address records left to try)) { if (try a message send == ok) { wait for a reply; if (reply received) if (reply==more address records) { update address hint; reset pointer to the top of the address hint; } else /* reply was data */ done=TRUE; } else { /* the invocation failed */ dispose of the address record; move the pointer to the next address record to try; } }
7
This algorithm highlights the fact that it is possible for any object which the client happens to call upon in an attempt to find the required service object to change the list of addresses that the client will subsequently search. This is important since it allows updates of the address list to be passed back to clients. Implementing these new features required changes to both the prepc language and to the capsule's interpreter (see section 2.2). The changes to prepc allow servers to specify a list of addresses with which to form an interface reference. These changes have affected the trader$Export and binder$CreateIR operations. Both these operations allow the server to produce an interface reference. This interface reference may then be passed to clients so that they can invoke the server. The Export operation also causes a copy of the interface reference to be registered with the trader. The old and new syntax of Export is show below. !
/* old format */ {eh}P->A
T+
X
T
T
A->P->M->A
T+
T+
X
X
A->P
T+
X
T
T
A->P->M
T+
T+
X
X
Table 3 : Failure Characteristics Key to table 3 : T the invocation will take the same time whether this component fails or not. T+ the invocation will take longer if this component fails. X the invocation will fail if this component fails. A the object is active. P the object is passive. M the object has moved.
Note that invocations only fail if (a) the target object has been passivated and the resource manager for its node has failed, or (b) the target object has moved and the location manager which recorded this fact has subsequently failed. The first case (a) is acceptable, since we may equate failure of a node's resource manager to failure of the node itself, in which case the object will be unreachable anyway. The second case (b) may be avoided by (as suggested in section 4) including other managers in the address list which are used in these circumstances to search clusters for target objects whose movement records have lost. It is also worth noting that invocations never fail as a result of a port manager failing, at worst they may take considerably longer than anticipated.
6. Future Work 6.1. Extending management by exception In this paper we have described how the philosophy of management by exception may be applied to two transparencies: persistence and re-location. However, the same general mechanisms and philosophy may also be used to provide other features such as access control.
12
For example, consider the object access architecture being developed by our coworkers on the Zenith project at the University of Kent. All objects which offer a service maintain an internal cache of {client identifier, permissions, expiry date} triples. When an object receives an invocation it checks in its table that the client has appropriate permissions, and that these permissions have not passed their expiry date (expiry dates may be specified either in terms of the number of invocations for which a given set of permissions is valid, or in terms of absolute time). If there is no entry in the table, or the entry which is there has expired an exception is raised. This causes an access manager to be consulted. The access manager checks to see if the client should have access to the server, and updates the server's cache table accordingly. Clearly the degree of security, and the overheads incurred are directly dependent on the life-time of the permissions. If permissions are only valid for a short period of time (or number of invocations) then frequent checks by the access manager will be required. However, if the permissions are set to last for a longer period of time then the overheads incurred will be fewer, but the security of the system will be weakened, since changes to a clients permissions may take longer to filter through to all objects. This area is currently under further investigation. More details may be found in [Davy,91a]. 6.2. A management framework All of the work described in this paper is aimed at supporting transparent object invocation. The benefit of the system described is that in 'normal' circumstances, that is if the object is both active and has not moved since the last invocation, the client will pay no extra overheads. Resource, location and port managers assist in achieving object invocation. They do not implement any particular policy with respect to resource management. Specifically, they do not make decisions to either move or passivate objects. These decisions must be made by clients, or by managers acting on their behalf. The cost of object invocation is directly related to the nature of the policies these clients or managers implement. For example, a policy which requires the passivation of all objects as soon as possible (presumably because resources are scarce) will result in high costs for object invocation. Clients whose target objects are managed according to a more flexible policy which attempts to keep recently invoked objects active are likely to have significantly lower invocation costs. Given the importance of managing objects according to policies tailored for their particular requirements there is a clear need for multiple managers implementing different policies. Sometimes these managers will be required to implement polices for a single object. More typically however they will need to manage multiple objects according to a single policy. There has been a significant amount of research aimed at modelling this scenario. For example the Domino project [Sloman,89] uses the concepts of domains to structure a world of objects for management purposes. A domain may be defined as an object whose purpose is to represent a set of objects which may be resources, workstations, processes etc., depending on the purpose for which a particular domain is defined [Moffett,90]. Objects must belong to at least one domain but may belong to multiple domains. As objects, domains may themselves be members of domains leading to hierarchies of domains. Other projects such as the META project use groups to enable managers to communicate with managed objects [Marzullo,90]. In the case of META these groups correspond to ISIS process groups [Birman,89] which provide facilities such as event-ordering gaurentees which significantly simplifies the implementation of managers. In Zenith we have adopted a hybrid approach based on the notion of object groups. These groups are based on the concept of interface groups found in [ANSA,90]. Each group supports a number of interfaces, including a management interface and at least one service interface. The management interface contains operations for controlling the membership of the group. The service interface allows invocation of the members of the 13
group as a collective entity. The results of invocations are either collated into a single result or are presented to the client as a list of results, one from each member of the group. We have been using object groups for a number of months to build distributed multimedia applications [Davies,91]. However, to support the type of structuring provided by domains object groups needed to be extended to include the notion of hierarchical groups. This allows an object group to join an existing object group as a subgroup. Invocations addressed to the super group can then be selectively sent to the subgroup if required. We are currently evaluating this approach not only as a means of structuring for management but as a generally useful concept for building distributed applications. 6.3. Capsule based migration A weakness with our current implementation is that the unit of movement is the capsule (see section 2.2). When a single computational object is implemented in each capsule this does not present any problems. However if multiple objects are implemented in a single capsule then they must be treated as a single unit for the purposes of persistence and relocation. In addition the mapping between objects and capsules must currently be decided by the programmer at compile time (see [Davies,91] for further information on the problems of mapping multiple computational objects into single capsules). To address these problems we are currently investigating the provision of support for inter-capsule migration of computational objects. We intend to model capsules as nodes with their own resource managers. The existing mechanisms described in this paper will be used to support transparent invocation of passive and re-located objects. The new capsule-based resource managers will use a form of dynamic-linking to allow new computation objects to be activated within executing capsules [Davy,91b]. This will allow the dynamic reconfiguration not only of the capsule to workstation mapping but also of the object to capsule mapping.
7. Conclusions This paper describes extensions to the current version of ANSAware to support persistence and full location transparency. The enhanced ANSAware now forms part of the Zenith base service platform which is being used to underpin a number of new services aimed at providing facilities for the construction of distributed multimedia design environments. We have shown that persistence and location transparency may be incorporated into such a system without incurring undue overheads in all but exceptional cases, and that the resulting system behaves well in the face of system object failures. We believe that the approach of management by exception will form a suitable basis for tackling other management issues in Zenith including access control.
Acknowledgments The work described in this paper was conducted as part of the Zenith Distributed Multimedia Object Management System Project funded by the Information Engineering Directorate of the DTI/SERC (under Grant GR/F 37627). The authors would like to acknowledge their co-workers on the Zenith project: Carole Snape, Martin Davy, Zarine Kemp, Peter Linington, Elizabeth Oxborrow and Roy Thearle. Thanks are also due to Geoff Coulson and Neil Williams for their helpful comments during the course of this work.
8. References [ANSA,89a] A.P.M. Ltd. "The ANSA Reference Manual Release 01.00", A.P.M. Cambridge Limited, UK, March 1989.
14
[ANSA,89b] A.P.M. Ltd. "ANSA: An Engineer's Introduction to the Architecture", A.P.M. Cambridge Limited, UK, November 1989. [ANSA,90] A.P.M. Ltd. "A Model for Interface Groups", A.P.M. Cambridge Limited, UK, 1990. [Anderson,90] Anderson, D.P., S. Tzou, R. Wahbe, R. Govindan, and M.ּAndrews. "Support for Continuous Media in the Dash System", Proc. of the 10th International Conference on Distributed Computing Systems, Paris, May 1990. [Birman,89] Birman, K., K. Marzullo "ISIS and the META project", S U N Technology, Summer 1989. [Blair,91] Blair, G.S., G. Coulson, N. Davies, and N. Williams. "Incorporating Multimedia into Distributed Open Systems." Proceedings of EurOpen'91, Tromsø, Norway, 1991. [Coulson,91a] Coulson, G., J. Smalley, and G.S. Blair. "Implementation of a Group Invocation Architecture in ANSA", Internal Report, Lancaster University, August 1991. [Coulson,91b] Coulson, G., G.S. Blair, N. Davies, and N. Williams. "Extensions to ANSA for Multimedia Computing", Internal Report No.: MPG-90-11, Lancaster University, June 1991. [Davies,91] Davies, N., G. Coulson, N. Williams, and G.S. Blair. "Experiences of Handling Multimedia in Distributed Open Systems", to be presented at the 3rd International Symposium on Experiences with Distributed and Multiprocessor Systems (SEDMS III), Newport Beach, California, March 1992. [Davy,91a] Davy, M.J. "Object Access in Zenith", Zenith Report, Computing Laboratory, University of Kent, April 1991. [Davy,91b] Davy, M.J. "Using Dynamic Link Editing with ANSA", Zenith Report, Computing Laboratory, University of Kent, September 1991. [Fisherman,87] Fisherman, D.H., D. Beech, H.P. Cate, C. Chow, T. Conners, J.W. Davis, N. Derrett, C.G. Hoch, W. Kent, P. Lyngbaek, B. Mahbod, M.A. Neimat, T.A. Ryan, and M.C. Shaw. "Iris: An Object-Oriented Database Management System", ACM Transactions on Office Information Systems, Vol.: 5 No.: 1, January 1987. [Hornick,87] Hornick, M.F., and S.B. Zdonik. "A Shared, Segmented Memory System for an Object-oriented Database." ACM Transactions on Office Information Systems, Vol.: 5 No.: 1, January 1987. [Kemp,91] Kemp, Z., M. Davy, P. Linington, E. Oxborrow, and R. Thearle. "ZENITH: An Object Management System for a Distributed Multimedia Environment." Internal Report, Computing Laboratory, University of Kent, 1991. [Marzullo,90] Marzullo, K., R. Cooper, M. Wood, and K. Birman. "Tools for Distributed Application Management", Report TR 90-1136, Department of Computer Science, Cornell University, July 1990. [Moffett,90] Moffett, J. "Delegation of Authority using Domain-Based Access Rules", Domino Project Report B1/IC/1, Imperial College, January 1990.
15
[Moore,88] Moore, D.J., P.A. Drew, M.S. Ganti, R.J. Nassif, S. Podar, and D.H. Taenzer. "Vishnu: An Object-Oriented Database Management System Supporting Software Engineering.", Proc. COMPSAC'88, The 12th International Computer Software and Applications Conference, Chicago, USA, October 5-7, 1988. (IEEE Comp. Soc. Press 1988), Pages: 186-192. [Rodden,91] Rodden, T., and G. Blair. "CSCW and Distributed Systems: The Problem of Control" Second European Conference on Computer-Supported Cooperative Work (ECSCW '91), Amsterdam, The Netherlands, September 25-27, 1991. Pages: 49-64. [Sloman,89] Sloman, M., and J. Moffett. "Managing Distributed Systems", Domino Project Report , Imperial College, UK. September 1989. [Thompson,89] Thompson, C., D. Wells, J. Blakeley, T. Bannon, J. Chen, S. Ford, T. Ekberg, A. Gupta, J. Joseph, E. Perez, D. Sparacin, B. Peterson, M. Shadowens, C. Wang, and S. Thatte. "Open Architecture for Object-Oriented Database Systems", Technical Report 89-12-01, Information Technologies Laboratory, Computer Science Center, Texas Instruments Incorporated, Texas. December 1989.
16
