Zenith system for object management in distributed multimedia design environments

Zenith system for object management in distributed multimedia design environments

Z P Kemp, E A Oxborrow, M J Davy, P F Linington, R Thearle, G S Blair*, P Dark*, N A Davies*, J A Mariani* and C Shape*

The paper describes the Zenith research project, which is being carried out at the Universities of Kent and Lancaster, UK. It is a research prototype of an object management system that is intended to meet the data-management requirements of the next generation of application domains, such as office information systems, integrated project support environments, and geographical information systems. Zenith is designed to provide a flexible and adaptable platform for the management of distributed multimedia objects, on top of which specialized applications can easily be built. The design of the system reflects this goal. The object- management layer provides the high-level abstractions required for managing complex objects, and the base-services layer is responsible for the management of primitive entities stored on conventional and specialized devices, while maintaining appropriate location, media, and other transparencies. The earlier sections of the paper briefly discuss the background to the project, including the context of the Zenith environment and the philosophy that underlies its design. Subsequent sections concentrate on the object model and the object-oriented design of the prototype system architecture. Finally, the current status and implementation issues are presented, followed by some brief concluding remarks.

data management, multimedia, object management, object models, object-oriented database systems, distributed systems

various additional ones ~. A response to these needs has been the development of a range of database systems that are rooted in varying ways in the object-oriented para- digm 2 8. Although various attempts have been made to arrive at a consistent universally accepted definition of 'object orientedness '9, a single object-oriented model has yet to emerge. A survey and comparison of current object-oriented database management systems (OODBMSs) and associated data models illustrates the 'variations on a theme' that currently exist ~°.

The focus of this paper is the Zenith system for generalized object management in distributed design environments; it is being developed as part of a collabor- ative research project in progress at the Universities of Kent and Lancaster, UK. The next section describes the context in which the Zenith system is designed to function, while the third section considers the underlying design philosophy that has shaped the Zenith object model and architecture. The fourth and fifth sections discuss the main features of the object model and architecture, respectively. In the sixth section, some implementation issues are mentioned and the current status of the system is described. The final section looks to the future.

It has now been universally accepted in the database community that the time has come to move on to the next generation. Current database technologies have proved to be excellent at providing the capabilities for efficient concurrent access to large volumes of persistent data, and at ensuring accuracy and consistency of data by providing a range of integrity constraints.

As database systems are being used in a wider range of applications than ever before, however, the weaknesses of conventional models have become obvious. Appli- cation domains with complex design requirements, such as geographical information systems (GISs), software engineering, office information systems (OISs) and computer-aided design (CAD), need all the features of current database management systems (DBMSs) and

Computing Laboratory, The University, Canterbury, Kent CT2 7NF, UK. *Department of Computing, University of Lancaster, Bailrigg, Lancas- ter LA1 4YR, UK

ZENITH ENVIRONMENT It is widely recognised that the OODBMSs of the future will need to support distributed systems and be capable of managing multimedia objects, as well as subsuming the functionality of current DBMSs n. They will also need to cater for a wider range of application domains than do current DBMSs and be much more integrated into the environments that they are intended to support. The rationale for Zenith is to provide a substrate for such OODBMSs, and the context of the Zenith environment is illustrated in Figure 1.

In Figure 1, the Zenith environment is shown in the dotted box; it embraces the Zenith system that provides the generalized object management, as well as part of the specialized environments that it is intended to support. The requirements that are common to all environments, or can easily be tailored, are directly provided by Zenith, while the support for more specialized requirements will be provided in terms of tools for the extension of Zenith. The intention is that the designer and builder of an

Vol 34 No 7 July 1992 0950-5849/92/070427-10 © 1992 Butterworth-Heinemann Ltd 427


I Users/applications interface (UAI) I

\ I / Object management system

. . . . . . . . . . Zenith system . . . . . . . . .

Base services

Zenith environment

Figure 1. Zenith environment IPSE: integrated project support environment; GIS: geographical information system; DB: database

application should be provided with a cohesive and comprehensive development environment, while at the same time being insulated from the demands of dealing with nonconventional media and distribution.

The Zenith system consists of two main software components:

• the object management system • the base services

The object management system (OMS) is responsible for the general management of Zenith objects, and provides, among other things, facilities for object creation, storage and retrieval, change management, and access control.

The base-services platform is responsible for managing and preserving, where appropriate, location, media, and other transparencies that relate to the stored primitive entities that reside on the distributed nodes and devices.

D E S I G N P H I L O S O P H Y

A detailed investigation of the data-management requirements of the environments illustrated in Figure 1 was carried out at the start of the project to identify the common requirements and those that need to be tailored to specific environments Z2. Consider, for example, the requirements of a comprehensive software engineering environment, a CAD system t3, or a GIS 14. These systems require a set of sophisticated tools for capturing the

semantics of, and manipulating, complex data objects that are required by the operational procedures inherent in these application domains. They will also be required to support data sharing and at the same time provide the mechanisms for data management and access that are provided by the DBMSs of today.

The requirements investigation suggested that systems designed to support the new application domains should:

• provide a repository for persistent information drawn from a variety of different environments

• cater for information that is highly structured • enable the evolution of data in the system to be

managed in various ways • support cooperation and sharing between develop-

ment personnel • cope with the demands of multimedia information in

distributed environments

The Zenith system has therefore been designed to support these features and to provide an interface between the needs of complex and varied application domains at one end and the diverse and distributed media on which data reside at the other end. The demanding nature of these requirements gave rise to the philosophy that underlies Zenith, which is that of an extensible, adaptable, and flexible design. This philosophy has resulted in:

. an object model with built-in flexibility • a 'seamless' architecture implemented

objects as Zenith

The object model is discussed in the next section, and the architecture is discussed in the section after that.

Z E N I T H O B J E C T M O D E L

Underlying concepts

This section contains a discussion of the object model concepts and design decisions that provide the rationale for the Zenith system and highlights its salient features. The generic model of object orientation, namely, encapsulated objects communicating with or invoking each other, lies at the heart of the Zenith view of the world. During the initial design stage, however, it became evi- dent that to encompass the range and diversity of the application domains that have to be supported, the fun- damental notion of 'object orientedness' had to be care- fully considered. Object-oriented systems can be charac- terized as those that support encapsulation, set-based abstraction, and polymorphism, and these principles can be achieved by a range of differing techniques and mechanisms. A comprehensive discussion of the essence of object orientedness and the varying methodologies that can be employed to achieve this are beyond the scope of this paper, but may be found elsewhere ~5-~7. Given the goals of the system, to support semantic complexity, distribution, and multimedia, it was clear that an object model based on a conventional class/inheritance

428 Information and Software Technology

z P KEMP ET AL.

hierarchy would be too limiting and rigid 18,~9. A much more flexible and dynamic notion of objects is required. In the Zenith context, a promising way forward was that based on the notion of abstract data types (ADTs) along with implicit derivation of a type hierarchy based on conformance 20.

ADTs have long been used as a mechanism for abstraction and information hiding, whereby the behaviour of an object is revealed by a well defined interface. In fact, ADTs, with their emphasis on a clear distinction between specification and implementation, have been conceptually subsumed by the object-oriented para- digm2k From the data-modelling perspective, however, the behavioural interface to an object is not sufficient to capture the required semantics of application domains. Therefore, the Zenith concept of an object extends the notion of an ADT to enable application-specific structural and behavioural properties to be specified as well.

The flexibility afforded by abstract typing and the separation of typing from implementation has also been recognised as a requirement in distributed systems 22. In a distributed environment, the OMS needs to be able to incorporate relevant information about the distribution transparency of objects, for example, to enable the system to determine whether an object has a fixed location or whether it can migrate and to determine appropriate action in case of partial failure.

Special capabilities are also needed to support multimedia objects, such as images, voice, and video, which require the system to respond to their real-time and storage requirements. The Zenith system provides abstractions over actual multimedia hardware by modelling them as objects, but, to do so, a dynamic notion of objects is required so that parameters such as quality of service can be associated with an object.

Zenith object characteristics

The previous section described the theoretical founda- tions of the Zenith object model; this section shows how they are realised by focusing on the characteristics of individual objects 23, 24

Object specification An object in the Zenith system is defined by its specification, which provides an abstract definition of its structure and behaviour. At the same time, the specification provides a clearly defined type for an object in terms of the interface supported by it. Figure 2 depicts the characteristics of a Zenith object from a specifier's perspective.

Conceptually, all Zenith objects are fully encapsulated. The internal state of an object is not directly observable, and any manipulation of it may only be carried out via methods named in the interfaces for that object. From the specifier's viewpoint, a method interface consists of a name, a parameter list, and a return value. The union of all the method interfaces defined in an object is the complete object interface; it may be used to identify objects with identical behaviour, but it does not provide unique object identification. The interfaces

Figure 2. Characteristics of Zenith object

can be used to provide different behavioural views for different users of an object. The structure of an object is reflected in its components and relationships, which are discussed in more detail below.

Object identification is provided by a unique system- wide identifier, which remains invariant during the life- time of the object. This is illustrated in Figure 2 in a dotted ellipse as it is system defined.

Object components and object component grammar Essentially, the Zenith model for complex objects is a compositional one in which objects may contain components that are themselves objects. The complexity of the internal structure of an object cannot be predetermined; it can be infinitely variable. For example, complex objects may be composed of a hierarchy of component objects, the components may have sequential (followed- by) relationships among themselves, components may also be grouped into sets, and so on. The Zenith object specification enables all variants of such complex objects to be defined.

The other important aspect of complex objects that the Zenith model deals with is the existence or otherwise of the components of complex objects. Recent object- oriented models have tended to view an object's characteristics as static. However, the Zenith object model has dynamic capabilities built into it by enabling the definition and management of objects with components that may optionally be present. The Zenith object specification provides this flexibility via the object component grammar.

Syntactical details of the object component grammar have been provided elsewhere 25. For the purposes of this paper, it should suffice to emphasize that the object component grammar also defines the relationships that can exist between these components, i.e., the ordering or

Vol 34 No 7 July 1992 429


8

b

Figure 3. Report object: (a) showing its components and relationships together with related objects (b) viewed in isolation

sequence of these components. The grammar defines the component-of relationships between an encapsulating object and its component parts and is therefore a complete definition of the internal structure of an object. In the case of simple objects, i.e., objects with no structural components, the grammar will be null. Thus those components that form part of the conceptual structure of a complex object are defined in its grammar and are visible in relation to all other components in the grammar. In addition to structural components, there may also be components that are of interest only to Zenith system objects, for example, those that refer to environment- specific aspects of the object, such as quality of service; these are not defined in the grammar.

Figure 3(a) contains an example of a structured object, Report, showing only its components and relationships. Its components Title, Date, Contents, and set of Sections would be specified in the object grammar (not illustrated in the diagram). The grammar would also be used to indicate that the Title and Date are mandatory. Contents is optional, and there may be one or more Sections in the report.

Object relationships One of the prime requirements of data modelling is the ability to specify application-determined associations between objects 26,27. As has been seen, relationships such as sequence relationships that define the ordering of components in a complex object are defined by the gram-

mar. Zenith also provides a flexible mechanism for des- cribing interobject relations.

Objects may be associated with any other object unless specifically prohibited from doing so by a relationship constraint. A named association known as an object relation defines the semantics of the association. Concep- tual relationships in Zenith provide the capability of capturing application-domain semantics in a flexible manner. Certain specific conceptual relationships that are particularly relevant in a multimedia environment, e.g., spatial and temporal ones, are provided by the system. Relationship constraints may be used to define the semantics of allowable associations between objects or explicitly to prohibit them. Like components, object relations may be defined as being static or dynamic, i.e., they may be mandatory or optional.

Figure 3(a) shows that the object Report participates in two external relationships. It is conceptually related to its author and the set of individuals who are the recip- ients of the report. The semantics of these associations are expressed as relationships constraints in the specification of the Report object.

From the implementation viewpoint, the relationships in which an object participates are made visible by connections. When an object participates in a relationship, it is visible from the object if a connection exists in the object; otherwise, the relationship is invisible. A connection can be viewed as a direct reference from one object to another and may be uni- or bi-directional.

Object state In a flexible system such as Zenith, the notion of 'object' encompasses many different concepts; its specification, its structure, its associations, temporary internal vari- ables, etc. The state of a Zenith object consists of its characteristics that persist and evolve over time. The state consists of an object's attributes, its internal components and external relationship connections. Compo- nents and relationships have been described above; an object's attributes are defined as named internal stores of an object. Each one represents a primitive entity, such as an integer, a string, or a bit map, and may be a union of primitive entities. Attributes are accessed and manipulated by methods. They are not part of the structure of an object and therefore do not appear in the grammar, and inter-relationships between attributes or between attributes and component objects may not be created.

Important features of object model

The preceding parts of this section have concentrated on an overview of the Zenith view of objects. The section is concluded by highlighting some pertinent features that distinguish it from other object-oriented database systems.

In class-based OODBMSs, the class encapsulates the behaviour and the interface, as well as the structure, of an object. Moreover, in systems such as Smalltalk 2s, the class is also the mechanism for generating instances of the object (typically, as in Smalltalk, by sending the


Z P KEMP ET AL.

message new to a class object). Thus the class performs several functions, including acting as a factory for creating new objects of a given type. This results in a one-to- one mapping between a type and its implementation. There may be circumstances, however, where more than one implementation of a type is required. Taking an example from a GISs domain, consider an object such as a river that provides an interface that enables its properties to be queried and the object itself to be displayed. The internal methods that enable the object to respond to messages will vary, depending on the representation of the river in the object base; the Computational procedures required to access a river object held in vector format are very different from those required if the internal representation is based on a data structure such as a quadtree. Note that the interface to the object would be identical in each case, but the implementation of the object would be very different. To cater for this flexibility, there is no explicit concept of class in Zenith. The object specification defines the structure of an object, but says nothing about its implementation. The implementation of an object is a separate issue and is dealt with by object factories, which are discussed later. In the authors' opinion, this is a particularly useful feature in an OMS where there is invariably a clear separation between the roles of specifier, implementor, and user/client of the database.

Another aspect worth noting is the capability of code sharing, i.e., software reuse, in class-based systems with inheritance hierarchies. In most of these systems, such as Smalltalk, a subclass inherits all the methods of its superclass, which may then be overridden by modification within the subclass. Inheritance therefore enables a subclass to share the specification of its superclass. As inheritance hierarchies can be nested to several levels, however, a subclass at the lowest level shares the specification of all its superclasses; in other words, its specification is dependent on all the superclasses that precede it in the class hierarchy. The advantages of this capability for software reuse have to be balanced against its disadvantages in a distributed system. Distributed systems have to provide location and migration transparency, i.e., objects should be able to migrate between nodes and be invoked by users irrespective of their current location. This capability is difficult to provide unless objects are totally encapsulated and dependencies between objects are avoided. For these reasons, Zenith, along with other object- oriented systems that support distribution, avoids class- based inheritance hierarchies. A Zenith object is complete in itself and totally encapsulated. Mechanisms for code sharing in Zenith are built into the tools for object specification and creation.

As mentioned earlier, the Zenith object model enables objects to present more than one interface to client objects. This is particularly important in a 'seamless' system (see the next section) where some objects may be server objects, i.e., objects of which there may be only one instance but which provide different services to client objects. Moreover, the ability to define multiple object

interfaces in Zenith is also useful in application domains that require an object to assume more than one role.

Most object models represent all data characteristics as simple attributes; hence the characteristics that represent other objects or relationships to other objects are of type: reference to object (or object id). The Zenith object model uses the concepts of components and relationships to add more semantics. Figure 3(a) depicts the Report object in the context of its related objects. Figure 3(b) shows the same object viewed in isolation, illustrating that the semantics of the external relationships are conceptually contained in the object together with the object's components.

A R C H I T E C T U R E O F Z E N I T H S Y S T E M

In this section, an overview of the Zenith architecture is first provided; the different elements in the architecture are then discussed in the context of the design philosophy and the major features, respectively.

Overview of architecture

Zenith not only provides an object model for users of the system, but the system itself is designed in terms of Zenith objects. Figure 4 shows the architecture for the initial prototype. The Zenith environment is composed of a collection of interacting objects (illustrated as circles/ellipses), together with supporting base services. The arrows indicate important invocation paths; most of the invocation paths shown are dependent on the prior establishment of invocation permission, which is handled by the access manager. For illustrative purposes, it is convenient to divide the objects into objects of special interest and other objects; the collection of circles labelled 'objects' represents the latter category. The primary concern of this section of the paper is the functionality and roles of the special-interest objects, which represent the major system entities.

The login interface and the user interface provide the mechanisms for logging in and out and generic access to objects in Zenith. The login server provides the back-up functions required to enable users to enter and leave the system, and also enables new users to be added to, and existing users to be deleted from, the system. The user master objects represent the valid users of the system. Each user is represented by a single-user master object, which is responsible for maintaining such information as login name, password, and so on. Each user master may contain a number of user-object components. User objects are responsible for handling individual login ses- sions; they are the means by which users can invoke other objects in the system from the user interface, and they are created and deleted by the user master as required.

The permit server provides a range of mechanisms to enforce access permissions on individual objects. The access manager provides the generic functionality to

Vol 34 No 7 July 1992 431


Logged-!n user User Logged-in

user I ( Iogin

User master object

Policy servers

manager

Location manager

Resource manager

.- s Factories "-. %

/ J

• i

Registration and service

and verification services

Base services

I Tre'?:a'r:n:Y I I Communications services

Storage services

Figure 4. Architecture of Zenith system

enable an object to invoke methods in another object. It coordinates with the permit server to grant or deny a given invocation request with reference to the access policies in force.

A policy-manager interface is provided for access to the policy manager to enable system policies to be viewed and set for tailoring purposes. Each policy server is responsible for the policies that relate to a particular system function.

The version managers enable different objects to be versioned according to different mechanisms/policies. Each version manager is responsible for a particular collection of related versions, controlling the creation of new versions, maintaining version history information, and providing flexible access to versions.

The set of objects actually encompasses all the special- interest objects, as these are Zenith objects. The representation of objects in the diagram is designed to illus- trate the important interobject communication paths, and it is not necessary to consider these objects further here.

The specification and verification services enable specification objects (which describe the interfaces of all

objects that exist) to be created, registered, and main- tained. These specification objects are essential for an efficient query service and can also be used by a browsing tool to enable objects with potential for reuse in a particular application to be located. The registration and query service provides two separate but related functions: it records the existence of all object instances and provides a flexible set of query-management facilities to enable registered objects to be located. Object creation is performed by means of factories. A factory is an object that creates an instance of an object which conforms to a given specification and has a particular implementation.

The location manager and the resource manager are used to keep track of any distribution and media information that needs to be visible. The supporting base services provide the low-level data storage and distribution facilities. They include various devices (such as cameras, printers, X-Window display points), mechanisms responsible for providing the required distribution and multimedia transparencies (replication manager, migration manager, etc.), and primitive storage and communications services capable of dealing with multimedia information.


Design of extensible, adaptable, and flexible system

This section considers the ways in which extensibility, adaptability, and flexibility have been built into the Zenith system.

Extens ib i l i ty The object-oriented design of the architecture makes Zenith inherently extensible. As illustrated in Figure 4, Zenith system functionality is encapsulated in a number of server objects, cooperating with and invoking each other. This enables Zenith to provide a seamless extensible object-management platform. The provision of additional system functionality, the building of new specialized environments, the development of applications - - these extensions can all be carried out by creating new Zenith objects that interact with those in the prototype as required. This is referred to as a 'seamless' approach to extensibility, as system objects and application objects are completely integrated and coexist together without any logical distinction between them.

Alternative approaches to extensibility include a 'layered' approach, a 'modular' approach, or a 'kernel' approach, but none of these provide the degree of flexibility inherent in a seamless approach. Examples of these other approaches are the ObServer object-management layer with the Encore database environment and the Garden project support environment built on top 29, the Zeitgeist open architecture providing modules that can be selected as required by different environments 30, and the Exodus kernel basic OMS, with specialized libraries and tools for system building 31. A persistent object- oriented programming language is another approach to extensibility; examples include 028, ObjectStore 32, and Ontos 33, all of which add persistence to C+ + objects. Such systems, however, lack the flexible object model that Zenith supports.

Adaptabi l i ty

The main mechanism for tailoring Zenith system functionality to a particular environment is the policy management service. The policy mechanism enables users to make and enforce decisions that affect the behaviour of system entities 34. Policies may refer to requirements for security, transactions (policies on concurrency, locking strategies, etc.), multimedia synchronization, type evolution, etc. By allowing systems designers to choose the level of support they require from Zenith, applications need only be concerned with object-management semantics that are appropriate to their particular problem domain. For example, certain applications might wish to enforce data security by encryption of all stored and transmitted data. This decision could be made by the system manager setting an appropriate policy. Another example of a policy concerns the versioning capabilities of Zenith; a particular integrated project support environment (IPSE) application may require version management of objects to be in force so that several

Z P KEMP E T A L .

versions of objects (software modules) may be main- tained and manipulated in the OMS.

The available policies are accessible through policy servers, which are passive objects that store information on policies currently in force. The policy servers represent the current state of the configurable aspects of the system, and thus comprise a configuration database. Policies are viewed, set, or modified under the control of the policy manager, which has sufficient intelligence to prevent the setting of contradictory and/or inappropriate policies, Access to the policy manager would generally be restricted to 'system administrators'. In the initial prototype, seven servers have been provided to handle, respectively:

• login policies • object access and permissions policies • object versioning policies • factory policies • specification policies • object registration and query policies • base services policies

The policy management service is extensible in that new (user-defined) policies can be added to existing servers.

Flexibi l i ty Flexibility has been built into all areas of the Zenith system where relevant, but this section concentrates on flexibility in object creation and access to objects.

Application designers need to create new objects, and it is the factory objects that provide flexible support for this task 35,36. Factories associate a particular implementation with a particular specification and enable objects to be created, which, while conforming to a particular specification, may have different implementations from other objects that also conform to the specification. All objects created by the same factory belong to the same class, while all objects that conform to the same specification belong to the same type. Thus Zenith directly supports the concept of type (i.e., an abstract definition of an object), which is equivalent to the object specification. As already indicated, the notion of class is not defined in the Zenith model as it is too restrictive. How- ever, all objects created by the same factory (i.e., those that have the same specification and implementation) implicitly belong to the same class. The Zenith model therefore supports both type and class as separate concepts without being constrained by them.

Granularity of access is important in a system designed to support a variety of application domains. To consider an object as having just one interface to all its methods is too restrictive. An object must be able to have a number of different interfaces to provide a range of behavioural views of the object. In the extreme, an interface to individual methods and all possible combinations of methods may be required, and Zenith provides this fine granularity of access by means of permit components in objects under the control of a permit server. A permit component associates each of its parent object's

Vol 34 No 7 July 1992 433


methods with users who are permitted access to the method. When an object requires access to another object, the permit server is invoked by the access manager with the identity of the user who is the owner of the requesting object. The permit server in turn invokes a method in the permit component of the requested object, which returns information that identifies the interface that the requesting object is permitted to use. The access manager then acts as an intermediary to ensure that this flexibility of access is securely controlled 37.

Support of major features

This section discusses aspects of the architecture that are oriented towards supporting the main features referred to earlier.

Evolution of data Issues concerning both type evolution and version management have been investigated. To date, only version management has been designed in detail and incorpor- ated into the initial prototype 38. The nature of object evolution in different environments varies; hence the version mechanism must be general. In some environments, only a linear version structure may be appropriate or permitted, while in others the version structure may form a complex tree structure. The requirements investigation at the start of the project also identified the need for support not only for versions but also for variants. A variant of an object generally has equivalent structure and behaviour to a particular version but has a different 'unit of measurement' (e.g., a variant of a piece of software written in C may be the equivalent software written in Pascal).

Object relationships (discussed earlier) have been used to implement version management. Each version manager maintains 'has version' relationships between itself and all versions/variants of an object and manages 'predecessor-successor' and 'variant-variant' relationships between the versions and variants themselves. Thus access is possible to the current default version, to a named version, to the object from which a particular version has been derived, to the versions that have been derived from a particular object, and so on. The relationships enable objects to evolve in any way that is appropriate to the application.

Cooperation and sharing The fine-granularity access mechanism already mentioned is well suited to an environment in which users cooperate closely in the design process, working together on different parts of the same object. In addition, as an object-oriented system, Zenith facilitates such cooperation as an object can automatically send messages to its co-designers when some part of it has been modified.

A particular issue which has been addressed is that of the nature of users in different environments. The ~requirements investigation identified not only individual users, but also groups (such as a design team) and roles (such as a project manager or a systems programmer).

The inclusion of these allows Zenith objects to be associated with particular application-dependent tasks.

Coping with multimedia information in distributed environments The separation of the Zenith system into the object- management layer and the base services provides a distribution and hardware transparent platform for the OMS. Above the base-services platform, all Zenith objects are manipulated in a consistent manner via the interface tools provided. Below that platform are the mechanisms to control the access and storage of conventional as well as multimedia objects, such as images and voice 39. The objects managed by the base services are built using a subset of Zenith object characteristics; i.e., they are entities containing state and encapsulated methods, but they do not possess components, relationships, etc., nor do they possess the functionality to support these characteristics. When they 'move up' above the base-services layer, they are 'parcelled up' to become fully fledged Zenith objects.

The base services also provide the mechanisms to handle the complexity inherent in the location and communication between entities in a distributed environment 4°. This aspect of the project is dependent on the ISO ODP (Open Distributed Processing) reference model and in particular ANSAware (Advanced Network Systems Architecture), which provides a substrate for the implementation of distributed computing systems+l.aL

I M P L E M E N T A T I O N I S S U E S A N D C U R R E N T S T A T U S

The design of the object model and the architecture for the prototype system have been completed, and the system is currently being developed as a set of prototype subsystems. Work is in progress on most of the objects in Figure 4, and the first versions of some of these are now complete. When the major objects in the architecture have been implemented, these will be integrated to form a single prototype. The integration will involve embed- ding the system objects in ANSA capsules, with related system objects being placed in the same ANSA capsule for efficiency reasons. For example, it is planned to put the login server and user master objects (plus associated user objects) in one capsule, the policy manager and policy servers in another, the general collection of objects and permit server in a third, and so on. Some work on integration aspects is already under way. All objects have been designed with ANSA IDL (Interface Definition Language) interfaces to enable Zenith system objects to be integrated with ANSAware.

An important implementation issue has been support for the dynamic linking of methods to objects. Static binding is unacceptable in design environments due to their dynamic nature; both the structure and behaviour of objects that are in the process of being designed are liable to change, and such changes need to be 'visible' to cooperating designers as soon as possible. Static binding is also inadequate in distributed systems in which the


replication and/or migration of objects is transparently supported. A mechanism has therefore been developed for dynamically linking object code into objects without halting the execution of the system. This has been built as an ANSA service that enables the facility to be used for distribution purposes as well as for object evolution. It is also a useful mechanism for enhancing the flexibility of the Zenith programming environment, enabling system bindings for different programming languages to be provided and the relevant bindings linked in dynamically as appropriate.

CONCLUSIONS

This paper has presented an overview of the Zenith project aimed at the design and development of a flexible and adaptable system for object management, facilitat- ing application development in a variety of domains. The Zenith object model consolidates and modifies a number of crucial concepts in object-oriented applications, which were reviewed in the light of a detailed analysis of requirements. During the process of development of the system, important technical issues are being addressed and tackled, including the impact of incorporating multimedia as well as conventional data through a common object model.

Once the basic infrastructure is in place, it is envisaged that application-level interfaces will be built to evaluate the Zenith environment. Further work will investigate sophisticated interactive interfaces, suitable for use by computer-naive users. The object model will provide a good basis for designing a graphical object representation that can be used for prototyping objects and for representing objects in their application context in a natural way.

ACKNOWLEDGEMENTS

This work has been carried out by the authors under the SERC-funded Zenith project (SERC grant numbers GR/ F/37610 and GR/F/37627), 'A Generalised Object Man- agement System for a Locally Distributed Multimedia Design Environment' .

REFERENCES ! Oxborrow, E 'What should go into an OODBMS product

(and why there is no simple answer!)' in Tagg, R and Mabon, J (eds) Object management Ashgate Publishing (1992)

2 Breti, R et al. 'The GemStone data management system' in Kim, W and Loehovsky, F (eds) Object-oriented concepts, databases and applications (1989)

3 Carey, M Je t al. 'The EXODUS extensible DBMS project: an overview' in Zdonik, S and Maier, D (eds) Readings in object-oriented database systems (1990)

4 Fishman, D H et aL "Overview of the IRIS DBMS' in Kim, W and Loehovsky, F (eds) Object-oriented concepts, databases and applications (1989)

5 Harper, D J and Norrie, M C 'Data management for object- oriented systems' in Jackson, M and Robinson, A E (eds)

Z P KEMP ETAL.

Aspects of Databases- Proc. Ninth British Nat. Conf. Data- bases (BNCOD-9) Butterworth-Heinemann (1991)

6 Joseph, J V e t aL 'Object-oriented databases: design and implementation' Proc. IEEE Vol 79 No 1 (January 1991)

7 Kim, Wet al. 'Architecture of the ORION next generation database' IEEE Trans. Knowl. Data Eng. Vol 2 No 1 (1990)

8 Deux, O et ai. 'The O2 system' Commun. ACMVo134 No l0 (October 1991)

9 Atkinson, M, Bancilhon, F, DeWitt, D, Dittrich, K, Maier, D and Zdonik, S 'The object-oriented database system manifesto' in Proc. First Int. Conf. Deductive and Object- Oriented Databases Kyoto, Japan (1989)

10 Thearle, R 'Survey of object-oriented databases' in Tagg, R and Mabon, J (eds) Object management Ashgate Publishing (1992)

11 Stonebraker, M e t al. 'Third-generation database system manifesto' in Proc. IFIP TC2 Working Conf. Object Oriented Databases (1990)

12 Theade, R, Davy, M, Kemp, Z, Davies, N and Snape, C 'An analysis of the data management requirements of specialized environments' Zenith internal report Kll (August 1990)

13 Maier, D 'Making database systems fast enough for CAD application' in Kim, W and Lochovsky, F (eds) Object- oriented concepts, databases and applications (1989)

14 Kemp, Z 'An object-oriented model for spatial data' in Proc. 4th Int. Symp. Spatial Data Handling (1990)

15 Beech, D 'Groundwork for an object database model' in Shriver, B and Wegner, P (eds) Research directions in object- oriented programming (1987)

16 Cardeili, L and Wegner, P 'On understanding types, data abstraction and polymorphism' ACM Comput. Surv. Vol 17 No 4 (December 1985)

17 Blair, G S, GaUagher, J J and Malik, J 'Genericity vs inheritance vs delegation vs conformance . . . ' J. Object- Oriented Prog. Vol 2 No 3 (September/October 1989)

18 Kahn, K M 'Objects - a fresh look' in Cook, S (ed) Proc. Third European Conf. Object- Oriented Programming (1989)

19 Kafora, D G and Lee, K H 'Inheritance in actor based concurrent object-oriented languages' in Cook, S (ed) Proc. Third European Conf. Object-Oriented Programming (1989)

20 Black, A, Hutchinson, N, Jul, E, Levy, H and Carter, L 'Object structure in the Emerald system' in Proc. First Conf. on Object-Oriented Programming Systems, Languages and Applications (1986)

21 Goguen, J A and Meseguer, J 'Unifying functional, object- oriented and relational programming with logical semantics' in Shriver, B and Wegner, P (eds) Research directions in object-oriented programming (1987)

22 Black, A Hutchinson, N, Jul, E, Levy, H and Carter, L 'Distribution and abstract types in Emerald' IEEE Trans. Soft. Eng. Vol 13 No 1 (January 1987)

23 Dark, P, Davies, N, Davy, M, Oxborrow, E, Snape, C and Thearle, R 'The Zenith object model, draft 5.0' Zenith internal report J13 (March 1991)

24 Oxborrow, E, Davy, M, Kemp, Z, Linington, P and Thearle, R 'Companion to the Zenith object model, draft 5.0' Zenith internal report K23 (March 1991)

25 Dark, P 'Syntax of the object component grammar' Zenith internal report LIO (October 1990)

26 Diaz, O and Gray, P M D 'Semantic-rich user-defined relationship as a main constructor in object oriented database' in Proc. IFIP DS-4 Conf. Object-Oriented Databases Win- dermere, UK (July 1990)

27 Barclay, P J and Kennedy, J B 'Regaining the conceptual level in object oriented data modelling' in Jackson, M and Robinson, A E (eds) Aspects of Databases - Proc. Ninth British Nat. Conf. Databases (BNCOD-9) Butterworth- Heinemann (1991)

28 Goldberg, A and Robson, D Smalltalk-80: the language and its implementation Addison-Wesley (1983)

29 Hornick, M F and Zdonik, S B 'A shared, segmented

Vol 34 No 7 July 1992 435


memory system for an object-oriented database' A C M Trans. Office Inf. Syst. Vol 5 No 1 (January 1987)

30 Thompson, C et al. 'Open architecture for object-oriented database systems' Technical report 89-12-01 Information Technologies Laboratory, Texas Instruments Inc., USA (1989)

31 Carey, M J et al. 'The architecture of the EXODUS extensible DBMS' in Proc. Int. Workshop Object-Oriented Data- base Systems (September 1986)

32 Lamb, C et al. 'The ObjectStore database system' Commun. A C M Vol 34 No 10 (October 1991)

33 Andrews, T, Harris, C and Sinkel, K The Ontos object database Ontologic Inc., USA

34 Thearle, R 'The Zenith policy management system' Zenith internal report K38 (December 1991)

35 Snape, C, Blair, G S, Dark, P and Mariani, J A 'A frame- work for object specification, creation and querying in the Zenith OMS' Zenith internal report LI1 (January 1991)

36 Dark, P 'Object specification and creation' Zenith internal report L14 (February 1991)

37 Davy, M J 'Objects access in Zenith' Zenith internal report K42 (March 1992)

38 Thearle, R 'Implementation of the Zenith version management system' Zenith internal report K41 (March 1992)

39 Davies, N and Blair, G 'A flexible approach to the management of multimedia objects in a distributed environment' Zenith internal report L18 (April 1991)

40 Blair, G S, Couison, G, Davies, N and Williams, N 'Incor- porating multimedia in distributed open systems' in Proc. EUUG Spring '91 Conf. Tromso, Norway (May 1991)

41 Architecture Projects Management Ltd ANSA - an engi- neer's introduction to the architecture Architecture Projects Management Ltd, Cambridge, UK (1989)

42 Architecture Projects Management Ltd ANSAware 3.0 implementation manual Architecture Projects Management Ltd, Cambridge, UK (1991)


Documents

Zenith system for object management in distributed multimedia design environments