Integrated Support for Complex Objects in a Distributed Multimedia Design Environment Gordon Blair, Patrick Dark, Nigel Davies, John Mariani and Carole Snape Distributed Multimedia Systems Group, Department of Computing, Lancaster University, Bailrigg, Lancaster, LA1 4YR, U.K. telephone: +44 (0)524 65201 e-mail:
[email protected] ABSTRACT Multimedia design environments are an emerging application area which present new challenges to database support systems. It is becoming clear that existing database technologies fail to meet these challenges. The Zenith project is addressing these shortcomings by investigating techniques to provide generic support for a range of design environments. The approach taken is to introduce database and multimedia functionality into an existing open distributed system architecture. This paper reports on the results of this work. In particular, attention is focussed on the problem of handling complex, mixed media objects in a distributed environment. It is argued that the integration of distributed systems, multimedia support and database functionality is required to meet the requirements of future design environments. 1. INTRODUCTION Multimedia design environments are an emerging application area which present new challenges to database support systems. Such environments are characterised by the presence of teams of designers cooperating to achieve a common goal through shared mixed media data. Examples include Office Information Systems, Geographic Information Systems and Integrated Project Support Environments.
Distributed Multimedia Systems Group Internal Report MPG-92-08, Department of Computing, Lancaster University, Bailrigg, Lancaster, LA1 4YR, U.K.
However, it is well recognised that existing technologies are largely inadequate for supporting such environments. A move is required from the traditional centralised, single media environment to a more flexible distributed multimedia environment. Such a move impacts on all underlying technologies: networks, operating systems and in particular database management systems. The Zenith project1 was established to consider the problem of providing support for design environments. More specifically, the aim of the Zenith project is to provide generic support for the full range of design environments. This paper reports on one important aspect of this research, namely the support for complex, mixed media objects in a distributed environment. Other aspects of the project can be found in [Kemp,91]. The paper is structured as follows. Section 2 discusses the requirements of design environments, highlighting the need for an object-oriented approach, and a system which is explicitly designed to support distribution and mixed media. An object-model featuring complex objects, designed specifically to address these and other requirements of design environments is introduced in section 3. The realisation of this model in a prototype Zenith system is described in section 4. Finally section 5 presents an evaluation of our approach and some concluding remarks. 2. REQUIREMENTS OF DESIGN ENVIRONMENTS The topic of database support for design environments has received considerable attention in the literature [Fisherman,87, Hornick,87, Moore,88]. However, the precise requirements of such environments are not well documented. Consequently, a detailed requirements study was carried out at an early stage of the Zenith project. This requirements study covered three environments in depth (Integrated Project Support Environments, Office Information Systems and Geographic Information Systems) as well as considering other areas such as support for engineering design and scientific experimentation [Thearle,90a]. The study also examined technological support for design environments [Davies,91]. This section summarises the results of this work. 2.1. The Nature of Design Environments In examining the various design environments, two factors became apparent:i) design environments do share a number of common characteristics and hence it is realistic to provide a generic support platform, and
1 Zenith is a DTI/SERC funded collaborative project involving Lancaster University, the University of
Kent and British Telecom Labs.
2
ii) there are a number of distinguishing features between the various design environments and hence it is important that a support platform is flexible and tailorable. The most important characteristic of all design environments is that they support teams of designers cooperating on a given task through access to shared data. This data is likely to be complex and highly structured and contain a variety of media types, including continuous media types such as voice and video2. Design environments are also likely to operate in a distributed environment with different members of a team accessing the shared data from personal workstations geographically dispersed around an organisation (perhaps spanning wide areas). In short, design environments must support cooperative access to complex mixed media structures within a distributed environment. This poses a number of extremely difficult technical challenges. The distinctions between different design environments can generally be traced to the management policies involved. For example, design environments differ in their approach to managing concurrent access to the database. Some environments will favour a traditional transaction scheme whereby users are mutually excluded from shared data whereas others will allow groups of users to have simultaneous views of the data. It is therefore important that management of information is policy driven, allowing the design environment to be tailored for particular needs. Policies are required for all areas of management including change management, access control and distribution management. In summary, the major challenge in the Zenith project is to develop a generic platform which caters for the needs of all design environments, whilst allowing sufficient flexibility (through policy selection) to handle specific features of a particular environment. 2.2. Object-Oriented Approach It is now widely recognised that the object-oriented approach is well-suited to design environments. Reasons for this include the encapsulation of data behind operational interfaces, hence allowing a range of granularities to be supported, and the support for extensibility and evolution offered by object-oriented approaches. The Zenith project therefore assumes an object-oriented approach, but highlights the following important requirements of the object model:i) object identity It is important for all objects to have a unique identifier, independent from any properties of the object, which denotes that object in the distributed environment. 2 The term continuous media is used to describe media types which include a temporal dimension.
3
ii) structure and content A distinction is required between attributes of an object which denote structure and management information and those which represent the content of an object. iii) attribute types Support is required for a full range of basic attribute types such as numerical information, text, graphics, voice, video and animation. iv) granularity The content of an object can vary from the extremely small to the extremely large. v) complex objects As already mentioned, support for complex objects is an intrinsic part of a design environment. vi) relationships It is important to support a general relationship model enabling a variety of complex object structures to be created. vii) efficient distributed querying There is a strong requirement to support efficient querying on complex mixed media structures in a distributed environment. 2.3. Support for Distribution and Multimedia The combination of distribution and multimedia introduces a number of difficult issues for design environments. In terms of distribution, the most important issue is heterogeneity. It is inevitable in a design environment that the infrastructure will be heterogeneous in terms of workstation types, operating systems and languages supported. This is particularly true in design environments spanning a number of organisational domains where different sections are likely to use different computing resources. It is therefore important that a design environment can operate in a heterogeneous environment. Consequently, open systems approaches are particularly appropriate for their construction. The introduction of multimedia also raises a number of issues. We identify the following as particularly important [Coulson,90]:i) it is necessary to integrate continuous media into a distributed environment, ii) the system should support the specification and subsequent fulfilment of a particular quality of service (QoS) for continuous media, iii) it should be possible to synchronise different continuous media types, for example to achieve lip synchronisation between audio and video sequences.
4
Finally, it is important that issues of distribution and multimedia should be largely transparent to the user of the design environment (unless the user requires explicit control over aspects of distribution or multimedia). 2.4. Summary This section has highlighted a number of important requirements for a platform to support design environments. The major requirements are summarised in figure 1. Support for cooperative work Geographically distributed Heterogeneous environment Complex object structures Mixed media data Policy driven management Object identification General relationship architecture Efficient distributed querying Continuous media support Quality of service specification Media synchronisation Figure 1: Summary of Requirements Satisfying these requirements is currently beyond the state of the art in database technology. We believe full support for design environments will require greater cross fertilisation between areas such as databases, distributed systems and multimedia. The Zenith project attempts to achieve a level of integration across these topics by introducing database and multimedia functionality within an existing distributed system architecture. The key to this integration lies in the uniform object model as presented below. A complete description of the model may be found in [Dark,91a]. 3. THE OBJECT MODEL 3.1. An Overview A Zenith object is an encapsulation of a number of characteristics as illustrated in figure 2. These may be classified as either static or dynamic. The former represent integral features of an object (for example, an identifier or methods) which exist for the lifetime of
5
the object whilst the latter are optional (for example, components or relationships) and may be short lived in nature. OBJECT Static Characteristics
Dynamic Characteristics
Id Components Methods
Object Component Grammar
Relationships
Relationship Constraints
Figure 2: Characteristics of a Zenith Object All objects are uniquely identified and may only be accessed through their methods ensuring complete encapsulation. Zenith supports the concept of structured 3 objects which may consist of one or more components. In addition, Zenith also supports the notion of a complex object, that is, an object which has one or more relationships with any other object; thus by definition a structured object is also a complex object. As discussed in section 2, complex objects are fundamental to design environments and represent logical units that can be utilised to great advantage in resolving many difficult problems, such as, semantic integrity, storage, versioning, permissions, sharing and concurrency [Kim,87] [Kim,89]. Components and relationships can be dynamically created according to the rules defined by an object component grammar and a set of relationship constraints. Thus, complex lattices of objects and relationships can be constructed. The object component grammar defines the permissible components of an object and the structural relationships that may exist between them whilst relationship constraints determine the scope and nature of other relationships, for example, conceptual, spatial or temporal relationships. Components may be defined in terms of either composite, complex or base objects. In our multimedia environment the latter may represent particular media types for example text, graphics, voice or video.
3 Structured is often interchangeable with compound or composite within the literature.
6
3.2. Relationship Support for Complex Objects The Zenith system supports a sophisticated relationship architecture [Dark,91b] [Snape,91a] designed to meet the various requirements of handling complex objects (as discussed above). This architecture has three tiers as illustrated in figure 3. Levels one and two provide a model for referencing and relating objects respectively, in addition to supporting appropriate query mechanisms. The primary function of the relationship service is to allow more general queries across "classes" of relationships. We briefly outline the purpose of each of the levels below in terms of functionality and querying. Relationship Service
Relationship Service
LEVEL 3
General Relationship Query Interface query_relationships (predicate)
Supports general relationship queries.
Relationship Object Tier Relationship Object Relationship Object Interface e.g. component_of create (parent,child,[exclusive,dependent]) delete (parent,child) components_of (object,[exclusive,dependent]) parents_of (object)
LEVEL 2 Each relationship Object represents a particular "class" of relationship. It ensures consistency and provides semantic based queries on the particular relation.
"Database" of current relationships e.g. component_of Parent Child Exclusive Dependent A B Yes No A C No Yes A D Yes Yes D F Yes No
Direct Reference Tier LEVEL 1
Zenith Object Object id Relationship id
Object id connect (object_id,[relationship_id]) disconnect (direct_ref) query_ref (predicate)
Object id
Supports creation, deletion and querying on the direct references and visible relationships of individual Zenith Objects. Provides a light weight mechanism for efficient object traversal.
Object id
Object id Relationship id
Figure 3: The Reference and Relationship Architecture
7
a) Direct References At the object level, any object may associate itself with any other object by directly referencing the other object, this is called a direct reference. A direct reference provides a lightweight mechanism for indicating that there is a connection or link between arbitrary objects. There is no system support for direct references thus their management is the responsibility of the application (support for creation, deletion and querying of a direct reference must be provided within the object itself). b) Relationship Objects At the relationship level, named relationship objects are provided as first class objects (these objects have the same characteristics as all other Zenith objects). Each different kind of association is represented by a unique named relationship object. A relationship object records information about objects which participate in the named relationship. It manages the creation and deletion of given associations in accordance with its semantic constraints. At this level, integrity is maintained by individual relationship objects. c) Relationship Service At the management level, a relationship service is provided, again as a first class object, which provides semantic information about the set of relationship objects which are maintained using the relationship service. In terms of querying, one can move in at any level and make appropriate queries. At level one, one can query on direct references and visible object relationships. At level two, one can query individual relationships in general or in terms of their specific semantics. At level three, one can make general relationship queries. The distinction between levels two and three is that the latter allows querying over all relationships but does not support querying on the specific semantics of individual relationships whilst the inverse is true of the former. We feel that this basic architecture will satisfy the general requirements for relating objects which may range from simple direct references to complex relationships with appropriate semantics. The ability to model these two extremes is important but difficult as they place conflicting requirements on the model. A direct reference implies a need for a lightweight mechanism, with few restraints, that permits rapid traversal through an object network as found in hypertext. However, at the other extreme, a need for defining and 8
realising complex relationships with appropriate integrity, consistency and query support, that will invariably be heavyweight, is essential. The above architecture with its lightweight direct reference tier, relationship object support and management service provides the basis for satisfying these diverse requirements without compromise. 4. REALISING THE ZENITH OBJECT MODEL Support for the Zenith object model is provided by a collection of support objects or services which together comprise the Zenith architecture. Figure 4 highlights the key services provided by the Zenith system. Interaction between these services, and between these services and user or application defined objects is by invocation of Zenith interfaces. Thus the programmer is provided with an integrated environment in which there is a uniform model of access for both user and system defined objects. Users Design Environments Design Environment Specific Objects Design Environment Specific Policies
Object Creation Factories
Devices cameras video windows microphones etc.
Extended Services Registration Service Specification Service Change Management
Base Services Invocation location managers resource managers access manager
Policy Management Distribution Management
Streams video stream audio stream object groups
Figure 4 : The Zenith System Architecture The base services (section 4.1) provide support for the invocation of objects in a distributed multimedia environment. The extended services (section 4.2) offer further functionality, in particular support for the creation and querying of complex objects. Using these services programmers may construct their own 'design environment specific' objects to provide the desired functionality. In the following sections we concentrate on those services (both base and extended) which comprise the core of the Zenith architecture, rather than those that are specific to one or more design environments. 4.1. The Base Services The role of the base services is to provide a suitable platform upon which the remainder
9
of the Zenith system may be built. In particular, they provide abstractions for manipulating objects in a heterogeneous distributed system. Key aspects of the base services are described in the following sections. 4.1.1. Object Invocation Central to an object-oriented system such as Zenith is the notion of object invocation. The base services make use of an existing distributed systems platform, namely ANSAware [ANSA,89], to provide basic facilities for object invocation. ANSAware was specifically chosen to overcome the problem of heterogeneity; the ANSA project has been influential in the ongoing development of Open Distributed Processing standards. 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. 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 interfaces. Specifically, prepc statements allow the programmer to obtain a unique identifier for objects, and then to invoke operations in the object's interfaces using this identifier. This form of object invocation encompasses a number of distribution transparencies. The programmer interacts with objects in a uniform manner, irrespective of, and often without knowledge of their physical location (access and location transparencies respectively). The ANSAware stubs ensure that data types are correctly mapped between different languages, operating systems and workstations in our heterogeneous environment. In Zenith we have augmented this invocation mechanism by providing two additional transparencies: persistence and migration. Objects can be in one of two states, i.e. active or passive. In our system, all objects appear active, i.e. ready to receive invocations. However, objects in this state consume system resources (e.g. memory). Hence, it is useful to be able to make objects passive by temporarily surrendering these resources. To control activation and passivation, all objects provide the following management interface:• Passivate - surrender system resources and save current state • Activate - restore a passivated object • Checkpoint - save a significant milestone in an object’s history as a checkpoint object • AssumeCheckpointState - return an object to a previously created checkpoint 10
• Move - migrate an object to another site The approach to management of persistence and migration relies on an ordered list of address hints held in the unique identifier for an object. This normally has the actual address of the object as the first entry of the list, followed by the addresses of two managers, a resource manager and a location manager. In searching for an object, it is assumed that the object is active and has not moved. If this is the case, the invocation will pick the first address from the list and proceed accordingly. This will be exactly equivalent to a normal invocation, with no management overhead. However, consider the case if the object has gone passive. Passive objects register their state with the resource manager on the local site and then surrender their resources. On invoking a passive object, an exception will be raised because the first address is invalid. On this exception, the resource manager will be contacted. This resource manger will then be responsible for activating the object and returning it to the state before passivation. At this point, the address hints are updated by the resource manager. This updated address hint table is then used in future invocations. A similar situation exists if an object is migrated. Migration is implemented by an object de-registering itself with its resource manager, registering itself with the resource manager on the destination site and finally going passive. This change of location is then notified to the location manager. This time, the first address will fail and the invocation mechanism will contact the resource manager. However, the resource manager will not have the necessary information on that object. Hence, it is necessary in this case to contact the location manager to find the new location of the object. Again, the address hint list must be updated at this stage. Once this is established, the resource manager on that site can be contacted to activate the object. With this approach, management overhead is incurred only when necessary. We refer to this feature as management by exception. More subtly, this overhead is proportional to the amount of passivation and migration activity. Thus the overheads can be established on a per object basis by policy guide-lines from application programs. This feature of management by exception allows us to build a platform with the flexibility required to support a range of design environments (see section 2). Only those objects which require management are subject to associated overheads, allowing us to freely mix within our system objects which need management and are prepared to pay for it, and objects which demand minimum overheads to ensure high performance. The principle of management by exception extends to other areas of management. For example, consider the approach to access control developed by our co-workers at the
11
Computing Laboratory, University of Kent [Davy,91]. Different design environments have very different security requirements. We relate the overheads involved in checking access rights to the policies in force at the time. 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. 4.1.2. Object Groups The base services platform provides extensive support for object groups. These allow arbitrary Zenith objects to be grouped and invoked as a single unit. Groups provide at least two distinct interfaces, a group management interface and a service interface. Using the group management interface, the membership of a group may be controlled and monitored. Objects may be dynamically added or removed to/ from the group. Application programmers can use stand-alone policy objects to constrain the membership changes of the group according to the prospective members type or identity, or with relation to the number or identity of the groups current members. Clients of the group can then invoke all of the group's members using the service interface. Such an invocation may result in either a single response (providing group transparency, e.g. for replication) or multiple responses (e.g. for querying multiple objects). Groups are important in Zenith for two reasons: •
most design environments are designed to support cooperative work between groups of users. Object groups provide a promising tool for efficiently implementing such environments.
•
groups provide us with a low-level structuring mechanism for management purposes. For example, objects subject to the same policy may be grouped
12
together in order that a manager may apply the policy without the need for repeated invocations. We are currently focussing on the latter aspect of groups. Initial experiences suggest that the ability to produce groups of objects is not enough. In particular, there is a strong requirement for hierarchical structuring similar to that provided by domains in the Domino project [Sloman,89]. To provide this support, we have recently extended Zenith object groups to include the notion of hierarchies of object groups. This allows object groups to join other groups as subgroups. Invocations addressed to a supergroup's service interface can be selectively sent to its subgroups if required. This allows managers to delegate responsibility for subgroups of objects to other management entities, while retaining the ability to invoke all of the objects they manage at any point in time. 4.1.3. Support for Continuous Media The introduction of continuous media types places novel demands on the underlying support systems [Coulson,90]. To meet these requirements the base services platform provides a number of services for manipulating continuous media data. Devices Devices are an abstraction of physical devices, pieces of stored continuous media, or software processes. Devices may be either sinks (e.g. a video window), sources (e.g. a camera) or transformers (e.g. a compression device) of continuous media data. Most devices present the following pair of interfaces:•
a generic control or Chain interface. A piece of continuous media may be visualised as a chain comprising a sequence of links, each of which represents an atomic unit particular to the media type in question (e.g. a frame of video)4.
•
a device dependent interface. The device dependent interface contains operations specific to the device. For example, a camera might have operations such as pan and tilt.
4 Chains are an extension of the voice ropes abstraction developed for the Etherphone project [Terry,88],
and may be editied using similar operations (e.g. concatonate chains, form a subchain etc.).
13
The Chain interface is common to all continuous media devices. It contains operations to selectively set up the device to produce or consume continuous media data, and to switch the information flow on and off. Sequences of stored media do not have a device dependent interface for control, only a Chain interface, and hence are often referred to simply as Chains. A virtual pointer moves through the Chain as it is played or recorded, and this pointer may be located and moved using additional operations available in the Chain interface. Using the Chain interface, clients of a device may create an endpoint interface on the device. This interface abstracts over all aspects of a device which are concerned with the transport of continuous media data. Streams Section 4.1.1 stressed the importance of object invocation in Zenith. However the request-reply semantics embodied in object invocation are not suited to modelling the transmission of continuous media data. In particular the repeated invocations which would be necessary to move video data between a camera and a video window do not offer any opportunity for the programmer to specify their overall temporal requirements. For this reason we introduce the notion of Stream services. These are used to connect together devices via their endpoint interfaces. They are abstractions of continuous media transmissions and map down on to an underlying transport protocol. The Stream interface contains operations which allow the client of a Stream service to connect and disconnect endpoint interfaces. Streams support M:N connections, i.e. they allow M sources to be connected to N sinks. This is modelled by allowing endpoint interfaces to be grouped (see section 4.1.2) together as shown in figure 5. Endpoint interfaces may be dynamically added to or removed from these groups. Sink group
Source group
data Stream Interface Chain interfaces
Chain interfaces Endpoint interface group
Endpoint interface group A device dependent interface
Figure 5: Using Streams to Connect Endpoint Interface Groups
14
4.2. Extended Services 4.2.1. Overview A variety of services have been developed to support object creation, specification and querying [Dark,91c]. These revolve round several key components and concepts, in particular factories, specification objects, instances and the Registration and Quantification Service, as illustrated in figure 6. These components are discussed in more detail below. Stream Factory
Factories Specification Factory
Chain Factory
Grammar Factory
Registration & Quantification Service
Registration Service
Specification Object Instances
Instance Queries
Specifications Register Instance
Instance Database
Specification Interface
Query Specifications & Instance Database
Specification Container Object Methods : get_component, create_component, view_component, remove_component Grammar : methods, grammar, relation, constraints, properties etc.
Specification Services
Components Utilise Specification Services
Methods Grammar
Verification Parsing Notational
Constraints
Diagram 6 : Extended Services Infrastructure. 4.2.2. Object Creation Object creation within Zenith is performed by factories [Cox,86]. In the general case, a factory is responsible for creating an instance of an object, given a particular specification, via a create_instance operation. Factories, specifications and instances provide the framework for describing, implementing and realising objects as outlined below:•
Specification: The specification provides a complete description of an object in terms of its behaviour, structure and semantics. Every instance will have an
15
associated specification. •
Factory: A factory is a service responsible for realising an object instance with a particular pattern of behaviour as described in its specification. For complex objects, a factory produces a general shell; it does not provide implementations of the individual component parts.
•
Instance: An instance is a an instantiation of a particular specification by a given factory.
It is important to realise that a particular specification can have several implementations. Therefore, in order to create an instance, it is necessary to find an appropriate factory for that specification that will produce the required implementation characteristics. The create_instance operation can be parameterised to select an appropriate template for implementation. A factory will always produce instances where the behaviour and implementation dependent properties are fixed but where the semantics and content may vary. Instances are associated with one factory and one specification. However the instance is not dependent on the factory, which may be destroyed at any time. 4.2.3. Object Specification A specification is a statement about the abstract behaviour of an object in terms of its functionality, structure, constraints and semantics. It does not describe how the specification will be realised. The specification represents an abstract behaviour whilst a factory represents a means of creating a physical object (an instance), i.e. a specific realisation of that behaviour. Employing specifications to abstract over implementations provides a consistent and powerful means of quantifying, comparing, grouping and analysing objects without being distracted by implementation differences and details. In effect, it provides us with a conceptual object model which is independent of the physical model. Specification is directly supported by a number of services, in particular, parsing, verification and notational services. Each of these services is briefly outlined below. •
The Parsing Service allows syntactic checking of the notation adopted for specification. The operation parse (parse_data : string, notation : string) parses the parse_data (a specification or part there of) according to the specified notation . It returns a string listing syntax errors.
•
The Verification Service is used to check the semantics of a specification, in
16
particular the component grammar, relations and constraint definitions. Verification is a more difficult task than parsing, and we do not intend to address it in its entirety. It includes a variety of tasks, for example, ascertaining whether or not the components of a structured object actually exist or determining whether the semantics of a relation are valid etc. •
Notational Services provide tools to simplify the description of specifications, for example, if a finite state machine notation is used, a graphical interface with appropriate operations (such as add_node, add_arc) may be provided to simplify the definition.
4.2.4. The Registration and Quantification Service. The Registration and Quantification service [Snape,91b,91c] registers and maintains a record of all instances and specifications within the system, i.e. it is an instance database. The Registration Service is used to register newly created objects with the Instance Database. All factories are responsible for registering the objects they create thus the Registration and Quantification service will have a complete record of currently existing instances (note that specifications are themselves object instances and hence will also be held in the database). It will organise, use and manipulate this database to provide generalised and specialised querying facilities over all or selected portions of the data. Support is also provided for the relationship query service discussed in section 3.2. Furthermore the Registration Service is responsible for maintaining a type graph including derived subtype relationships, together with a structure graph (to include the notion of compatible grammars) to provide structure and substructure information. The user may then query the registration service and ask for information about a particular service which meets certain criteria by either specifying a number of properties, for example, the specification name, the structure, any additional properties or any valid combination thereof. 4.2.5. Other Services A number of other services are included in the complete Zenith architecture. These include managers for version control and general change management. More significantly for this paper, a policy service is included which maintains a database of management policies for a particular design environment. This database is used to tailor the underlying support facilities for a particular set of requirements. The work on version control, change management and the policy server is being carried out at the University of Kent and is
17
reported in detail elsewhere [Thearle,90b]. 5. CONCLUDING REMARKS The design and implementation described above tackle a number of the major requirements identified in section 2. Most importantly, Zenith provides a generic platform which provides support for complex mixed media structures in a distributed environment. This support platform can also be specialised through user defined policies to meet the requirements of a particular design environment such as an Office Information System or an Integrated Project Support Environment. The approach taken is to provide support for database functionality and multimedia within an existing distributed system platform (ANSAware). ANSAware addresses the problem of heterogeneity in a distributed environment by providing a uniform view of objects. This is enhanced by a complex object model featuring a general relationship architecture. Support is also provided for the registration and querying of objects. The multimedia enhancements are provided by a base services platform which supports continuous media types including audio, video and animation, quality of service specification and media synchronisation. A lightweight management regime is also introduced at this level to optimise the behaviour of the system in a distributed environment. Some progress has therefore been made in providing generic support for design environments. However, a number of important issues remain. One of the most challenging is provided by the need to support cooperative working within the design process. This has a number of important repercussions for design environments, particularly in the management of objects. The area of Computer Support for Cooperative Work (CSCW) is currently receiving considerable attention in the research community. Ongoing research at Lancaster is investigating the repercussions of this work for underlying systems technologies [Rodden,91a,91b]. ACKNOWLEDGEMENTS The work described in this paper was carried out 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 at the University of Kent: Martin Davy, Zarine Kemp, Peter Linnington, Elizabeth Oxborrow and Roy Thearle. REFERENCES [ANSA,89] A.P.M. Ltd., "The ANSA Reference Manual Release 01.00", A.P.M Cambridge Limited, UK. March 1989. 18
[Coulson,90] Coulson, G., G.S. Blair, N. Davies, and N. Williams. "Extensions to ANSA for Multimedia Computing", Internal Report No. MPG-90-11, Computing Department, Lancaster University, Bailrigg, Lancaster, LA1 4YR, U.K. June 1991. [Cox,86] B.J. Cox, "Object Oriented Programming : An Evolutionary Approach", Addison-Wesley Publishing Company, ISBN 0-201-10393-1, 1986. [Dark,91a] P.J. Dark, C. Snape, R. Thearle, N. Davies and M. Davy, "The Zenith Object Model", Internal Report, ref.: MPG-91-02, Computing Department, Lancaster University, Bailrigg, Lancaster, LA1 4YR, U.K., Jan. 1991. [Dark,91b] P.J. Dark and C. Snape, "A Reference and Relationship Architecture for Zenith Objects", Internal Report, ref.: MPG-91-46, Computing Department, Lancaster University, Bailrigg, Lancaster, LA1 4YR, U.K., May 1991. [Dark,91c] P.J. Dark, "Thoughts on Object Specification and Creation", Internal Report, ref.: MPG-91-47, Computing Department, Lancaster University, Bailrigg, Lancaster, LA1 4YR, U.K., Feb. 1991. [Davies,91] Davies, N.A., and J.R. Nicol. "A Technological Perspective on Multimedia Computing."Computer Communications Vol: 14 No.: 5, June 1991, Pages: 260-272. [Davy,91] Davy, M.J. "Object Access in Zenith", Internal Report, Computing Laboratory, University of Kent, April 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. [Kim,87] W. Kim et al., "Composite Object Support in an Object-Oriented Database System", in Proc. 2nd Intl. Conf. on Object-Oriented Programming Systems, Languages, and Applications, Orlando, Florida, Oct. 1987. [Kim,89] W. Kim, E. Bertino and J. Garza, "Composite Objects Revisited", in Proc. ACM SIGMOD Intl. Conf. on Management of Data, Portland, Oregon, June 1989. [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,91a] 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: 4919
64. [Rodden,91b] Rodden, T., and J. Mariani. "The Imapct of CSCW on Database Systems" IFIP International Workshop on CSCW, Berlin, April 1991. [Sloman,89] Sloman, M., and J. Moffett. "Managing Distributed Systems", Domino Project Report , Imperial College, UK. September 1989. [Snape,91a] C. Snape, P.J. Dark, G.S. Blair and J.A. Mariani, "A Complex Object Model for Distributed Multimedia Design Environments", Internal Report, ref.: MPG-9140, Computing Department, Lancaster University, Bailrigg, Lancaster, LA1 4YR, U.K., August 1991. [Snape,91b] C. Snape,"The Registration Service”, Internal Report, Computing Department, Lancaster University, Bailrigg, Lancaster, LA1 4YR, U.K., Sept. 1991. [Snape,91c] C. Snape,"Query Management in a Distributed Multimedia Environment”, Zenith Report, Computing Department, Lancaster University, Bailrigg, Lancaster, LA1 4YR, U.K., Sept. 1991. [Thearle,90a] Thearle, R.W., M.J. Davy, Z. Kemp, N. Davies, and C. Snape. "An Analysis of the Data Management Requirements of Specialised Environments", Internal Reportt, Computing Laboratory, University of Kent. 1990. [Thearle,90b] Thearle, R.W. "Policy Servers in the Suggested Zenith Architecture", Draft Report University of Kent. April 1991.
20
