Abstract 1 INTRODUCTION - Semantic Scholar

The DOK Project: Towards the Integration of Heterogeneous and Distributed Multimedia Databases 1 RMIT

Zahir Tari 1 Kokou Yetongnon 2 Iztok Savnik 3 Wilson Cheng 1 George Fernandez 1

Dept. of Computer Science Bundoora Campus, Plenty Rd. VIC 3083 Australia fzahirt,[email protected]

2 University of Bourgogne

IEM Department BP 138, 21000 Dijon France [email protected]

Abstract

3 Jozef Stefan Institute

Computer Systems Department Jamova 39, Ljubljana Slovenia [email protected]

the superstructure of the database system - Database Management System (DBMS). Once advancement in the development of centralised database technology had been achieved, the next step was to extend it to handle the distribution of data and processes. Distributed database technology is the union of two approaches to data processing: database systems and computer network technologies. Database technology is based on the integration of the operational data of an enterprise, and provides centralised, controlled access to data. The technology of computer networks promotes a mode of work that goes against centralisation eorts. The integration of such paradigms has been very successful, and is regarded by many as a future information technology - distributed computing [8]. The diculties in distributed databases lie on the problem of integrated access to information resources located in several local, possibly heterogeneous databases. Firstly, helping users to get the right data to their desktops from anywhere in the enterprise is the most critical goal of network computing. Thus, the issue is to provide a communication mechanism among local databases and allow transparent access to local database information. Secondly, integrating and maintaining legacy systems is dicult. Dierent organisations have independently developed many application-speci c DBSs, typically implemented on dierent hardware and software platforms. Many business procedures must access and update several DBSs, thus the integration of information processing resources and services is increasingly required. Thirdly, global and cooperative information processing with total transparency to users requires support of new architectures and technologies. The need is to compute across organisational and geographical boundaries, and to combine existing and new computing resources. Users should not be forced to send multiple requests in dierent languages to multiple information sources. The solution for the problem of integrating infor-

This paper describes the Distributed Object Kernel (DOK) system, which provides extended database functionalities over heterogeneous and distributed multimedia databases. The DOK object model provides mechanisms for representing dierent forms of information, including structured (e.g. tables and objects) and non-structured (e.g. images and voice) information. In addition, the DOK object model allows a self , description of both structural and behavioral aspects of heterogeneous database applications. A set of metaobjects describe the information about objects, the messages they can process, and the way messages are to be executed in a distributed and heterogeneous environment. The DOK logical architecture has a clear separation of concerns, involving a coordination layer, a task layer and a database layer. Each of these layers contains a set of agents specialised in performing speci c functions related to the cooperative computation. When a user requests information about a DOK application, the coordination agents identify and delegate the sub-parts of the query to appropriate agents of the task-based layer. These specialised agents, in turn, use the agents of the database layer to access the required information to process the dierent subparts of the global request. Keywords: information sharing, re ection, distributed and multimedia databases.

1 INTRODUCTION The last three decades witnessed the development of computerised data storage and processing. Immense progress was achieved when E. Codd [4] introduced the relational model which laid a formal foundation for current database technology. Signi cant research eorts have been devoted to the study of the conceptual level of Database Systems (DBS) as well as to 852

part of an object, i.e., is responsible for all the mechanisms required to nd the object implementation for the request, to prepare the object implementation to receive the request, and to communicate the data making up the request. The interface that a client sees is completely independent of where the object is located, what programming language has been used for implementation, or any other aspect not re ected in the object's interface. Middleware technology as such is limited to support cooperative computation amongst database applications. One of the major limitations is that transaction queries involving information in multiple databases cannot be performed. This implies that a global sophisticated software layer has to be built to ensure database functionalities such as query optimisation and transaction management for cooperation between the dierent databases.

mation resources is to provide a database technology that allows integrated global access to autonomous, heterogeneous local databases. There are various approaches for realizing this type of database technology: distributed databases, federated databases, multidatabases, and interoperable databases [6, 10]. All of them are designed as a distributed system comprising a global layer that facilitates access to shared information, and a local layer with multiple components, called local databases. In general terms, the dierences between the approaches are in the structure of the global layer, and how it interacts with the local components. In particular, they dier in how tightly the global layer integrates with the local layer. The rest of this paper is organised as follows. The next section describes current approaches to deal with the problem of informationsharing and puts the DOK project in context. Section 3 provides a description of the DOM+, which allows the representation of different types of information in a cooperative environment. Section 4 describes the object normalisation of a DOK schema and shows how integrity constraints are implemented as procedures. The logical architecture of the DOK system is described in Section 5, and nally in Section 6 we conclude with our future work.

2

2.2 Multidatabase Systems Multidatabase database systems are an extension of distributed database systems to include a global layer responsible for supporting operations on multiple databases at a time. This global layer involves global processing functions, such as enforcing global concurrency control and global serializability of transactions. The local layer is a set of database systems that has their own local processing and they could be dierent to each other. There are thre dierent types of local autonomy in multidatabases [1]: design autonomy (local databases are not modi ed by joining a multidatabase), execution autonomy (local databases are free to proceed with execution of local functions), and communication autonomy (local databases are not obliged to provide to external 'media' any information about processing details, and treat the global system as another ordinary local user). There are many good reasons for preserving local autonomy: economic reasons and the reluctance of database system vendors to allow for embedding additional, unveri ed procedures into their products. The local autonomy requirement places a large burden on the global transaction manager. Global requirements and global query/transaction processing methods are likely to con ict with local ones. The global manager must therefore work around these con icts during the initial design and later maintenance of the global system. Also some global resources must be dedicated to compensate for any missing function or information. Multidatabase systems can be also classi ed, according to the degree of autonomy of their components, as strongly coupled and loosely coupled. Strongly coupled multidatabase systems are the nonfederated type of system (e.g UNIBASE [2]). Distributed database systems are the extreme in this class, in which there is no autonomy and operations

APPROACHES FOR INFORMATION SHARING

This section describes the current technologies to achieve computation across dierent software and/or hardware platforms: middleware, multidatabases and cooperative databases. The rst category is not itself dedicated to database environments. However this can be extended to deal with database functionality in the context of a heterogeneous environment.

2.1 Middleware Middleware is a distributed computing environment that allows computation across dierent platforms. Advances in middleware technology, e.g. OMG's CORBA1, implement the client/server paradigm with object oriented technology to provide connectivity and integration. CORBA uses an underlying object model, to wrap local applications as objects that can communicate using the Object Request Broker (ORB). A client can use or de ne objects using the Interface De nition Language (IDL), which allows what is generally called in database community the \logical independence". Indeed, only the interface of objects is transparently available to the user and the implementation is hidden. The ORB is responsible for the binding of the interface part to the implementation 1

Common Object Request Broker Architecture

853

are performed uniformly by the global layer. Loosely coupled systems are called federated database systems (e.g. MRDSM [6], Mermaid [14]) where the global layer has no control over the local databases. One of the problems related to multidabases is the lack of clear understanding of some database interoperability issues (e.g. autonomy) which aect the design of an interoperable system. The next generation of multidatabase systems are called cooperative database systems which allow a exible mechanisms of cooperation between local application by providing customised-type of autonomy.

pli ed \version" of an object-oriented model where most of some concepts are not supported. These concepts are important in the context of databases where the data model used at the global level should support rich abstractions allowing local information to be accurately represented. Thirdly, as a consequence of a simple global model, the proposed SQL query language provides only the expression of simple queries on the cooperative environment. Complex queries cannot be supported. Finally, one of the most important issues, TSIMMIS does not provide a customised-type of autonomy where dierent systems are allowed to have dierent levels of autonomy within the same organisation.

2.3 Cooperative Database Systems

2.4 The DOK Approach

The disadvantages of the two extremes, centralised distributed and federated databases, have been studied thoroughly. We believe that future database systems should not be moving along the spectrum line of autonomy, rather they should provide dierent levels of autonomy. In other words, the implementation of parameterised database systems that allow the database administrator to choose dierent level of autonomy according to the enterprise requirements. We are concerned with providing a exible mechanism for enterprises requiring dierent levels autonomy. For example, a company can make some of its information public and others in private and other are public but in control. A database system should be able to dynamically and transparently change its behaviour in terms of global information access, task negotiation, and global transaction processing, according to the dierent autonomy requirements of the enterprise. Also, the database system should be able to consider dierent autonomy requirements of different local databases. Should con icts arise among the local databases due to the dierent autonomy requirements, the system should act as an arbitrator to resolve them. A few projects have been initiated with the aim of building a cooperative database system, such as the TSIMMIS project [3] at Stanford University. The TSIMMIS project aims to provide tools for accessing multiple databases using mediators [15], i.e. providing browsing facilities to allow users learn about the semantics of objects and their components. A mediator is a program that collects information from dierent sources, processes and combines it, and exports the resulting information. The TSIMMIS's approach for cooperation is useful, although limited in the context of database applications. These limitations can be summarised as follows. Firstly, TSIMMIS lacks of a \good" architecture allowing to have a clear understanding of the role of the dierent elements of the cooperative cooperative system. Secondly, the intermediate model used for information sharing at the global level is a sim-

The aim of the DOK project is to develop a speci c technology allowing better communication and computation across dierent software platforms. The aim is to overcome the current problems related to negotiation and communication, translation and re ection, which can substantially aect the performance and the quality of interoperability among the component databases. The design of the DOK system focuses on the development of (i) a Re ective-Distributed Object Model (DOM+) and (ii) a logical architecture. Other issues are detailed in [12].

 Re ective Distributed Object Model: Us-

ing this model, a user can build virtual objects 2 involving dierent types of information (e.g. graphic, bit-maps, text, voice). A virtual object is de ned as set of "references" to already de ned objects (i.e. physical objects) located in databases. The dierence between virtual objects and (physical) objects is that the former have no physical representation, but they are virtual representations de ned as aggregations of already existing composite objects. To allow a exible mechanism of cooperation, the distributed object model has been extended to provide components of the DOK system with a clear understanding of explicit and implicit information embedded in local applications. This type of informationis made available through the re ection process, where not only the data structures recorded in local databases (e.g. tables or physical objects) are abstracted, but also information about the location of physical objects, and the information about methods execution. A set of metaobjects are proposed to abstract all these types of information and made them available to DOK's components.  Clean logical architecture: The DOK logical architecture re ects the logical partioning of 2 i.e. an object that is built from heterogeneous information that are located in dierent sites.

854

 Type: A type can be either a primitive type

DOK's components according to the cooperative functions. The DOK logical architecture makes a clear distinction between the role or functions of its elements. Three types of functions are de ned: coordination functions (e.g. delegating a function), task-based functions (e.g. enforcing global security or translating) and databasebased functions (e.g. retrieve information about a speci c user).

(such as name: string, salary:int, etc.) or a prede ned type (such as the type P erson which is de ned in one of the databases), tuple type de ned using tuple constructor (such as [name:string,salary:int]), or a set type de ned using the set constructor (such as f[name:string,salary:int]g). Tuple and set types are important in the de nition of the query algebra because the result of an operation can be a virtual object, a set of objects or a tuple of information [9].

3 THE DOM+ MODEL

Assume a virtual class representing students has a label Student as de ned in Figure 1. The corresponding type consists of three pieces of information: Personal , information, Looks , like, and Results. The attribute Personal , information records the name, address and age of a student, have been imported from a (relational) database, say personal,db, as a (relation) class3 . The attribute Looks , like refers to the picture of a student that is stored in an image database (say bitmap , db). The attribute Results stores all results of the student, and is de ned as the result of a query on a database (say university , db). Thus, the de nition of the virtual class Student is as follows: , where Q1 is an SQL-like query in the form of: select item, submitted, mark from university , db where name = getName() and age = getAge() and address = getAddress().

DOM+ is the model that underpins the DOK components. It is used as a unifying object model for information processing. DOM+ is based on the assumption that (physical) objects are de ned already within local applications, and these objects can be used to build more complex objects, called virtual objects. By virtual we mean that a user is able to use or re-use existing (physically stored) information to build new (not automatically stored) information. This mechanism is very important in the context of cooperative databases because the user does not automatically want to create and/or store new information, but combine and restructure existing information [7] in order (i) to have a global perception and understanding of the cooperative environment (de ned as a virtual schema), and (ii) to query information located in dierent database applications using the virtual schema [9]. Virtual objects are built from virtual classes which are like templates. The concepts of virtual class and virtual object are not sucient to provide the information required by the DOK components for global processing. Additional information is required to understand the structure and behaviour of objects, as well as to know of their location. This additional information is used by some of the DOK components to bind a user request for a speci c object within a cooperative environment. This meta-information are de ned in DOM+ as a set of metaobjects (e.g. state, can and loc metaobjects).

3.2 Re ection As mentioned above, the object model is extended to deal with re ective information. This information allows the understanding of the semantics embedded on the local applications that is used during the negotiation between dierent components of the DOK system. We proposed in [5] a set of four metaobjects objects that are specialised on describing and monitoring every virtual object in a local and global system: state, can, loc and act metaobjects. A state metaobject is a kind of object which knows the structure of any associated virtual object whether that object be a domain or a metalevel object. A can metaobject is a kind of object which knows about the behaviour of any associated object - it knows what an object can do. A loc metaobject is a kind of object which knows how to locate attributes and execute the methods of an object. Finally, an act metaobject is a kind of object which knows about the activity in which some group of objects is involved. The Jim virtual object illustrated in Figure 1 is

3.1 Basic Concepts Basically, DOM+ model supports the concept of type. There are three dierent types of types: primitive types, prede ned types and user-de ned types. Primitives types refers to string, integer, etc., whereas prede ned types refers to existing types that are already de ned in local databases. A user can de ne more complex types by using set or tuple constructors on existing types. The basic concept of DOM+ is the notion of a virtual class has the following structure: < label; type >, where

3 In fact, from the user point of view, all the information appear as classes and relationships between classes, including the relation Person which is the type of the attribute Personal , information.

 Label: it describes what the class represents. 855

can(Jim) metaobject Context:

Student

CanDo:

loc(jim) metaobject Context: Student LookUp: Name

NameOfMethod

Sepcification

submitt()

....

award()

requires:

[]

pre-

item in {r:Results*r.item} Results(items).matk is null

post:

Results: = results except Results(item).mark = mark

Object

looks-like name address age results

surLooks surName surAddress surAge surResults

amend()

[item:integer, mark:integer]

reply

....

Do: Name

Procedure

submit()

....

award()

[item: integer, mark:integer] begin if item not in {r:Results*r.Item} then Results(item).Mark :- mark else error "Mark already awarded !" end

Student Looks-like Personal-information name: Jim Stanley address: 2#/30 heildberg St, Brisbane age: 25

.... Amend() Results

InProcess: name

statement

amend() award()

status

12.2 8.6

active pending

act(Jim) metaobject

from Program-A Program-A Program-B

submitted

marks

8 September 1995

80

2

21 October 1995

90

3

1 November 1995

?

state(Jim) metaobject

Context: Student In:

item 1

Context: Student for Karl Mary Jim

action Award() Award() Amend()

with [item is 2, mark is 75] [item is 2, mark is 80] [item is 2, mark is 55]

from

for

action

Program-B Program-D

Jim Tom

[item is 2, mark is 65] [item is 2, mark is 45]

place 1 2 3

State: Attribute

Type

looks name age

image string integer

address string result [item:integer] -> [item:integer, submitted:string, mark:integer]

Pending:

Figure 1: Wrapping of the Virtual Object \Jim" constructed from dierent data sources. The re ective DOM, called DOM+, using the dierent metaobjects, provides mechanisms to de ne four metaobjects for Jim virtual object that allow the complete understanding of all information about Jim (see Figure 1).

ample, submit(), award(), and amend().

 loc(Jim) is a metaobject that knows how to syn-

thesise the attribute and how to locate the methods. An attribute is materialised by sending an appropriate message to some predetermined surrogate object waiting for a response. A loc metaobject knows where to go in the cooperative environment to locate attribute and/or methods. It contains two attributes. Lookup() is a function that maps from a name to an object, one may possibly reside at some remote site. In Figure 1, each student attribute is paired with an object that will handle requests to retrieve or update the associated attribute. The Do attribute maps from a name to a procedure -one that should correctly implement the corresponding method speci cation in the can(Jim) object.

 state(Jim). This is an object that knows about

the structure and the state of the object Jim. Figure 1 shows the state metaobject for Jim. The Results attribute is a function mapping from an assessment item to a record of when that item was submitted and any mark awarded. According to Figure 1, the state mataobject is an object with two attributes: (1) State which is a record type or scheme, and (2) Context which allows a name to be given to the record type.  can(Jim) is a metaobject that knows about Jim's possible behaviour, that is, what messages it might be sent and the structure or pattern associated with each. From Figure 1, we see that the can mataobject has two attributes. It has one attribute CanDo which pairs method names with their speci cations. The attribute Context allows a name to be given to this particular set of pairings. There are three methods in this ex-

 act(Jim) is a metaobject that knows Jim's cur-

rent activity, that is, messages it is still processing, as well as messages it has sent or for which it is waiting for a response. This metaobject is goal and task- oriented. Its job is to supervise the activity of one or more objects within the heterogeneous environment.

856

In summary, the four metaobjects provide not only a static self-description of a virtual object, but also information on how to locate the virtual object in a cooperative environment.

pretation is expressed by the Staff's object model. Our approach diers from the conventional design approaches since our focus is not on the implementation issues (such as storage and performance problems). Our approach deals with the depiction of good virtual objects that re ect the access paths of the users. As it is pointed out in the previous section, virtual objects are implemented as a set of physical objects in the local databases. In this way, the implementation issues in the DOK context are irrelevant. To produce normalised virtual objects, two algorithms are proposed [11]. The rst algorithm, based on a top-down approach, transforms an existing schema into a normalised schema using object normalisation rules. These normalisation rules are based on the restructuring of paths not induced by the user's path dependencies. For instance, if a path Person|Laboratory|Project is not induced by the user's constraints (because the de ned projects are not related to a laboratory), then this is restructured into two sub-paths Person|Laboratory and Person|Project to re ect the user's interpretation. The second algorithm, sharing some commonalities with conventional approaches (i.e. the design approaches based on universal relation), builds a normalised schema from \scratch" using the user's dependency constraints. Therefore a schema will be correct from the user's perspective if this is similar to the one build by the algorithm.

3.3 Object Normalisation When a (virtual) schema is de ned using the DOM+ model, the next step consists on providing a correct representation of virtual objects to ensure the that they are consistent and re ect the user's understanding of the universe of discourse. The aim of this step is to produce a schema that is conceptually correct [11], i.e. express all global users's access paths. The normalisation theory we developed for objectoriented models takes into account their common features to support object identity and complex objects. Because of the complex relationships between virtual objects, conventional dependency constraints (e.g. functional and multivalued dependencies) are extended to deal with the various paths between virtual objects (e.g. paths involving only components of a virtual object - called vertical paths -, path involving dierent virtual objects - called horizontal paths). These dependencies are called path dependency, local dependency and global dependency constraints [11] and express various object relationships. At the schema level, dependency constraints are multi-typed (i.e. path dependencies) and express the inter-object relationships. At the object level, dependency constraints express intra-object relationships, i.e. relationships between an object and its components (i.e. local and global dependencies). Using the dierent dependency constraints, the concept of normal form for a virtual object is de ned, based on two main notions: the user's interpretation and schema interpretation. An interpretation is a set of dependency constraints that can provide a given \understanding" of the semantics of the underlying schema. In this way, the user's interpretation involves the set of a user's speci ed dependency constraints, whereas an object interpretation' is a set of dependency constraints that are re ected by the complex structures of virtual objects. In object-oriented models, and DOM+ particularly, a (virtual) object has many object interpretations because of the multiple interpretations of its paths. For example, if a virtual object Staff has Staff|Laboratory|Project as one of its paths, then this path has two possible interpretations: (1) a sta works on projects of a laboratory, or (2) a sta works in a laboratory and each laboratory has a set of projects. Every path of the object Staff has dierent interpretations (which we call object interpretation), and all interpretations of all paths of the Staff form the semantic of the object (called object model). Thus, the object Staff will be in a normal form (or semantic normal form) only if the user inter-

4 DOK ARCHITECTURE This section focuses on the logical architecture of the DOK system, which involves three layers: the coordination layer, the task layer, and the database layer. Each of these layers contains specialised agents (or active objects). Some agents are specialised in coordinating the tasks required for cooperative processing without enforcing them, called coordination agents. Other agents enforce speci c tasks, such as reengineering or query optimisation. These agents are called task agents. Finally, the last category of agents is those that perform typical database-like functions (e.g. access some informationabout local components in order to enforce global security policy). These agents are called database agents. The information about the dierent agents and their relationships are provided in Figure 2. This section describes these agents with regard to the enforcement of the local autonomy (i.e. security enforcement). This security enforcement task is initially started by the coordinating agents and later enforced by some task agents (e.g. global security processor of Figure 2), which in turn requests some database services to the database agents, such as the access to user information. This process of security enforcement is proposed in [13] and brie y described below. 857

Global Metada Manager

Global Transaction Manager

DOK coordinator

name maintain_federation_info() ensure_completness_of_trans() enforce_global_security()

Query Processor accept_query() optimise_query() Query Modifier modify_query() Security Pocessor

Wrapper coordinator

enforce_global_constrains() sanitise_query_results()

wrapper_id translate() connect() disconnect() authenticate_users()

Database Version Manager

Constraint Manager Response Processor

retrieve_result() verify_results() present_to_user()

check_prev_release_data() update_data_released()

search_constraints() retrieve_constraints() update_constraints() Version Agent User Agent user_id user_label

Constraint Agent

Component Database Agent database_id location database_label

read

write

Legend:

Data Agent data_label attribute_name

class association aggregation

Figure 2: Relationships between DOK Agents

4.1 Coordination Agents

Discretionary Access Controls (DAC) or Mandatory Access Controls (MAC). Since DAC involves the use of access control lists and MAC involves the use of classi cation labels, both kinds of information need to be made available.

The DOK upper layer consists of two coordination agents: DOK manager and wrapper. The former runs a speci c federation4 and can communicate with other federations. Most of the functions of DOK manager are prformed by delegating to other agents. For instance, if a DOK manager wishes to maintain information about members in the federation, it will seek the services of the global metadata manager and the global metadatabase agent. Additionally to ensure the completeness and correctness of global transactions, the DOK manager needs to solicit the methods of the global transaction manager as well as the global query processor. More importantly, in the context of customised autonomy enforcement, the DOK manager would solicit the methods of the global security processor to enforce global security. This is done by delegating sub-functions to specialised agents in lower layers. The wrapper has many roles. In terms of security enforcement, it needs to authenticate local users before presenting the query to the global level. A wrapper requests to other agents (i.e. agents that are in the database layer) information about users. The wrapper knows from the database agent which users are granted what access to which databases. This allows for the checking of the type of access control the user is subjected to, such as whether it involves

4.2 Task Agents The DOK middle layer is the task layer, involving agents specialised on speci c functions required for cooperative processing. For the security enforcement task, the agents of this layer ensure that all the security aspects of processing are carried out properly so that global security can always be maintained. These agents are: global security processor, query modi er, release database manager, release database agent and the response processor. The global security processor has a main role in assisting a DOK manager in enforcing global security. It does this through some speci c services, such as enforce global constraints() and sanitise query results(). The method enforce global constraints() preprocesses the security aspects of global query before they are sent out to the aected sites for interrogation. The sanitise query results() method postprocesses the results of the query to prevent any security breaches. The query modi er has a role to take a query that violates any global constraints and modify it so that it no longer violates the constraints. It uses the service modify query() to achieve this. The release database manager and release database agent keeps

4 A federation is a set of databases that are willing to share their information. Each federation is managed by one DOK manager.

858

References

track of previously released data from query responses to protect data from being released to unauthorised users. It employs the services update data released() and check prev release data(). Finally, the response processor has a role to collate the results of the global query and present them to the user. However, before it does so, it needs to verify the results that it received. This agent allows the execution of services such as retrieve results(), verify results() and present to user(). For example, the service retrieve results() communicates with the wrapper agents residing at the local level to collect the responses from the component databases that were interrogated, and collates the results by making joins or unions of the individual results.

[1] Y Breitbart, A Silberschats: Multidatabase Update Issues. Proc of ACM SIGMOD on Management of Data, 1988, pp. 135:142. [2] Z Brzezinski, J Getta, J Rybnik, W Stepniewski: UNIBASE-An Integrated Access Databases. Proc. of Very Large Databases, Singapore, pp. 388-395, 1984. [3] S Chawathe, H Garcia-Molina, J Hammer, K Ireland, Y Papakonstantinou, J Ullman, and J Widom: The TSIMMIS Project: Integration of Heterogeneous Information Resources. Stanford Technical Report, 1995. [4] E Codd: A Relational Model for Large Shared Data Banks. Int Jnl on Communication of the ACM, 13(6), June 1970. [5] D Edmond, M Papazoglou and Z Tari: An Overview of Re ection and its uses in Cooperation. Int Jnl of Intelligent and Cooperative Information Systems (ICIS), 4(1), 1995. [6] W Litwin: An Overview of the Multidatabase System MDSM. Proc. of the ACM National Conference, Denver, pp. 495-504, 1985. [7] C Nicolle, K Yetongnon, D Benslimane: MultiData Models Translations in Interoperable Information Systems. Proc. of the CAISE Int. Conference Greece, Springer Verlag, 1996. [8] M T Ozsu and P Valduriez: Principles of Distributed Database Systems. Prentice-Hall, 1991. [9] I Savnik, Z Tari and T Mohoric: Using Schema Information for Querying Databases. Proc. of the Int. Workshop on Reasonning about Structured Objects: Knowledge Representation Meets Databases, Bielefeld, 1995. [10] Z Tari: Interoperability Between Data Models. In: Semantic of Interoperable Systems, D. Hsiao, E. Neuhold and R. Davis (eds.), North Holland 1993. [11] Z Tari and J Stokes: Dependency Constraints and Object Normal Forms for Object-Oriented Schema. (Under revision) Int. Jnl of Transaction on Database Systems (TODS), 1996. [12] Z Tari, W Cheng and K Yetongnon: The DOK Cooperative Database Systems: Concepts & Architecture. Technical Report, Department of Computer Science, Royal Melbourne Institute of Technology, Melbourne, 1995. [13] Z Tari and G Fernandez: The Security Enforcement in the DOK Federated Database System. (To appear) Proc. of 10th Annual IFIP Working Conference on Database Security, Como (Italy), 1996. [14] M Templeton et al. : Mermaid - A Front End to Distributed Heterogeneous Databases. Proc of IEEE, May 1987, 75(5), 695-708. [15] G Witherhold: Mediators in the Future Information Systems. IEEE Computer, 25, 1992, 38-49.

4.3 Database Agents The DOK lower layer is the database layer which consists of a set of agents that provide typical databasebased information (such as, the list of users who can access a given information). These agents are: the component database agent, the user agent, the data agent, and the constraint agent. In Figure 2, we only include the agents that model the security aspects of the federation. The information recorded in these abstractions is necessary to dierentiate the kind of access control rights a user has in global query. For instance, to check whether a user is subjected to DAC or MAC, we have the use of associations and labels. In representing DAC, a user can be associated with each component database or data in the databases according to the user's ability to interrogate the databases. This is re ected in the model using the association relationship between classes. A user can have zero relationship with a component database in which there is no way a user can interrogate the component database or the user can have a one to one relationship with a component database in which the user is allowed to query that database.

5 CONCLUSION In this paper, we presented some of the aspects of the DOK cooperative database system to perform processing across dierent platforms: the DOM+ model, some functions of wrappers and the DOK logical architecture. The DOM+ re ective distributed model allows not only the modelling and the representation of dierent types of information, but also re ective information useful in the dierent stages of the cooperative processing. The DOM+ virtual object and metaobjects provide a powerful mechanism for cooperative applications. Due to space limitations several issues, such as reliability, negociation that have not been addressed in this paper. For more details, the reader can refer to [12] 859