1

Distributed Object Management 1

Frank Manola, Sandra Heiler, Dimitrios Georgakopoulos,Mark Hornick, and Michael Brodie

GTE Laboratories IncorporatedWaltham, Massachusetts 02254

U.S.A.

Abstract

Future information processing environments will consist of a vast network ofheterogeneous, autonomous, and distributed computing resources, includingcomputers (from mainframe to personal), information-intensive applications,and data (files and databases). A key challenge in this environment isproviding capabilities for combining this varied collection of resources into anintegrated distributed system, allowing resources to be flexibly combined,and their activities coordinated, to address challenging new informationprocessing requirements.

In this paper, we describe the concept of distributed object management,and identify its role in the development of these open, interoperablesystems. We identify the key aspects of system architectures supportingdistributed object management, and describe specific elements of adistributed object management system being developed at GTELaboratories.

1. Introduction

Today, computer usage is expanding into all parts, and all functions, of largeorganizations. This can be seen in the widespread appearance of powerfulpersonal computers for desktop use, and powerful workstations for morespecialized uses. Such computers are becoming commonplace in routine businessfunctions of all kinds. As a result of the continuation of this trend, future informationprocessing environments will consist of a vast network of heterogeneous,autonomous, and distributed (HAD)2 computing resources, including computers(from mainframe to personal), information-intensive applications, and data (files anddatabases).

With the appearance of increasing numbers of such HAD computing resources,there is an increasing need for technology allowing such resources to be flexiblycombined, and their activities coordinated, to create network-wide integrateddistributed systems that address challenging new information processing

1 Appeared in International Journal of Intelligent and Cooperative Information Systems 1, 1 June1992.2 Since we are located near Boston, we pronounce "HAD" as "hahd", in the same way thatnative Bostonians pronounce "hard". This is appropriate given the potential complexity ofsystems having these characteristics.

2

requirements. In some cases, these systems may combine resources belonging todifferent individuals or organizations, in support of various social, governmental, orbusiness activities (e.g., connections between customer inventory systems andsupplier order-entry systems).

In this paper, we describe the concept of distributed object management, andidentify its role in the development of these open, interoperable systems. In therest of this paper, we first describe the motivation for developing distributed objectmanagement technology, the goals for systems based on it, and additionalrequirements imposed on object technology by these goals. We then identify thekey aspects of system architectures supporting distributed object management, anddescribe specific elements of a distributed object management system beingdeveloped at GTE Laboratories.

The requirements for creating HAD systems can be met in two phases. The firstphase is interconnectivity. Most current computer systems are disjoint, and unableto communicate with other systems. Two or more computing resources areinterconnected if they can exchange messages. However, interconnectivityguarantees only communication. It does not guarantee that the resources understandeach other sufficiently to meaningfully interact or cooperate.

The second phase is the more ambitious goal of interoperability. Two or moreresources are interoperable if they can interact to jointly execute tasks. Simple toolsfor achieving interoperability are increasingly being provided in the form ofprogramming capabilities such as remote procedure call facilities. More advancedforms of interoperability require mutual understanding not only at the level ofcomplete systems or programs, but also at the data type level. This is necessary inorder to support the integration of heterogeneous information in, for example,advanced multimedia applications (such as office automation), and to support thestorage of such information in integrated repositories.

A further level of interoperability, which we refer to as intelligent interoperability,requires interaction between information systems, some of which may be intelligentthemselves and capable of functioning as intelligent agents concerning theircomputing capabilities. Distributed query processing is a very simple example ofthis form of interoperability in the domain of database management in which a globalaccess plan is developed that attempts to optimize the use of individual databasesystems attached to a network. In this case, the intelligent interaction is achieved byan external global query optimizer (planner) component. Other capabilities that maybe involved in intelligent interoperability include advanced forms of synchronizationto coordinate access to shared resources, and the use by cooperating componentsof knowledge about each others' activities to optimize overall performance. Thisform of interoperability is considered in [PAPZ92].

It is well known that interoperable HAD systems introduce technical problems inaddition to those found in conventional systems, including [LAMP81]:

3

• Naming, protection, sharing, and translation issues resulting from componentheterogeneity.

• Accounting and resource management issues created by componentautonomy.

• Synchronization, consistency, error recovery, and other control problemsresulting from component distribution.

It is also well known that, due to the additional complexity of these systems,mechanisms for structuring them are an important consideration. The ISO OpenSystems Interconnection Reference Model [ISO79] identified the use of layerscontaining services with well-defined interfaces, with the services being furtherdivided into (possibly-distributed) modules, as key concepts in structuring complexinteroperable systems.

As a continuation of this emphasis on interfaces and modules, there is increasingagreement that modeling a distributed system as a distributed collection of interactingobjects (in the sense of object-oriented programming) provides the appropriateframework for use in integrating HAD resources, in both distributed computing andtelecommunications environments [WILL91]. This is illustrated by the increasingnumber of standards activities related to HAD systems, including communicationsand distribution standards, database and programming language standards, andrepository standards, that are moving toward adopting, or have already adopted, anobject-oriented approach [FONG91]. These activities include not only those ofofficial standards bodies, such as ISO and ANSI, but also those of industryconsortia, such as the Open Software Foundation and the Object ManagementGroup [OMG91a].

Objects form a natural model for a distributed system because distributedcomponents can only communicate with each other using messages addressed towell-defined interfaces, and components are assumed to have their own locally-defined procedures enabling them to respond to messages sent them. Object-oriented programming, distributed or not, simply carries this model down to the levelat which the "components" are individual application abstractions, or even individualdata items, rather than the systems or nodes in a distributed network.

This use of objects also naturally accomodates many of the heterogeneous andautonomous aspects of HAD systems: heterogeneous because messages sent todistributed components depend only on the component interfaces, not on theinternals of the components, and autonomous because components may changeindependently and transparently, provided their interfaces are maintained. The useof the object abstraction in integrating heterogeneous and autonomous componentsis also a characteristic of recent developments in personal computer applicationintegration software, such as Hewlett-Packard's NewWave, Object Linking andEmbedding (OLE) in Microsoft Windows, and interapplication communication(IAC) facilities in the latest Apple Macintosh operating system. In this case thecomponents are application programs and their associated data. The goal is to

4

integrate individual applications, such as word processing, spreadsheet, or graphicsprograms, by treating them as the definitions of operations on text, spreadsheet, orgraphics "objects" (represented by the usual files associated with each application).Compound "documents" can then be created by including instances of the variousavailable types of objects. Operations peculiar to each type of object, e.g.,updating a graphic figure, are automatically routed to the associated application forexecution. An object-oriented DBMS (OODBMS) provides an environment thatintegrates heterogeneous types of objects, e.g., text, graphics, sound, and images,in a similar way (but typically at a finer level of granularity). For each type of object,the OODBMS holds the data in its own particular format, together with the code that"knows how" to manipulate and interpret that data. The result is that an applicationprogram accessing the object database only needs to know how to sendappropriate messages to the various types of objects; the code associated withthe objects handles the details of dealing with the heterogeneous data formatsinvolved.

The basic idea behind distributed object management is to continue these trends inobject-oriented distributed system models, application integration environments,and OODBMSs, to the point at which the complete set of resources available on adistributed network, including computers, network facilities, data, programs, etc., canbe treated as a commonly-accessible collection of objects which can be combined inarbitrary ways to provide new information processing capabilities. Intelligentinteroperability in the context of such a distributed object system would allow the setof resources available on the network to be treated much like the objects in anadvanced object database system. A client would not only have access to theavailable objects in the system via interfaces defined in a common object model, butcould also submit a request expressed at a very high level, and potentially involvinglarge numbers of objects, to the system as a whole, and have it (or the objects,acting together) determine an optimum means of satisfying the request. We refer toa collection of objects created by this approach as an object space. Distributedobject management then describes the task of managing a distributed object spacein the same sense as distributed database management describes the task ofmanaging a distributed database. We refer to a system performing this distributedobject management task as a Distributed Object Management System (DOMS).

Ultimately, this concept of distributed object management is intended to supportcapabilities including:

• The ability to integrate existing, separately-developed collections ofobjects and data, as in a heterogeneous DBMS.

• The ability to integrate heterogeneous data types, including bothconventional formatted data and unconventional data types such as soundand image data, as in an object-oriented DBMS.

5

• The ability to provide DBMS-like functionality for the integrated collection ofobjects, including query processing, concurrency control, and recovery.

• The ability to use existing applications in defining object operations, as inthe application integration software described above.

• The ability to integrate resources at whatever level of granularity isappropriate, including objects that represent entire nodes or databasesystems, as well as objects that represent individual applicationabstractions such as points, rectangles, or employees.

• The ability to invoke and synchronize the execution of combinations of suchobjects anywhere in the network, and to move data or objects asnecessary, in response to a given request.

• The ability to support cooperation among intelligent components.

Not all object technology is equally adapted to supporting these requirements.Some object systems were designed as tightly-coupled individual programmingsystems, and incorporate design decisions that create difficulties when they areintegrated with others in HAD environments. Object technology in the HADenvironment must, for example, support persistence and concurrency (parallelism),and deal with both homogeneous (within components) and heterogeneous (amongcomponents) type systems, languages, and computing paradigms. Theseconcerns are similar to those raised by Peter Wegner in describingmegaprogramming, or "programming in the very large" [WEGN90]. The requiredtechnology, which we refer to as distributed object management technology3,involves generalizing and combining technology from such areas as object-orientedand distributed programming languages, operating systems, and object databasesystems, integration and transaction management technology from heterogeneousdatabase systems, and, particularly in the support of intelligent interoperability,distributed artificial intelligence.

Much of this technology is actively being developed in these various technicalcommunities, and our own project is not attempting to duplicate these activities. Ourown work has concentrated on the development of architectural and object modelconcepts, together with associated facilities for object interaction, query processing,and transaction management, with the intent of combining technology, such as objectand process migration, communication protocols, etc. from the many other areasinvolved, to create complete systems. Such combination of technology is also theapproach being taken by the industry consortia mentioned earlier. The next threesections describe our work in the selected areas mentioned, and indicate therelationship of this work to current industry and research developments in theseareas.

2. DOMS Architecture

3 A more thorough discussion of how various technologies contribute to distributed objectmanagement technology is given in [MANO88].

6

In this section, we describe the components of a DOMS architecture. In Section 2.1,we describe a generic DOMS architecture. This architecture is conceptually similar tothose found in various systems for managing objects in HAD environments and, inparticular, to that defined by the Object Management Group for its Object RequestBroker (ORB) [OMG91a]. In Section 2.2, we describe the specific specialization ofthe generic architecture being developed in our project.

2.1 A Generic DOMS Architecture

A DOMS consists of an arbitrary number of distributed (physical) nodes, eachrunning one or more application programs, database systems, objects (if thesystem is object-oriented), etc. that constitute its computing resources, and acollection of clients (which may also be application programs, software tools, objects,etc.) that make requests for operations to be performed by these resources. Oneor more Distributed Object Managers (DOMs) act as intermediaries between theseclients and resources. DOMs make the computing resources of the system appearto be objects (whether they are actually object-oriented or not), with the DOMsacting as object managers, permitting clients to make requests involving resourcesthat reside anywhere in the system without having knowledge of the location,implementation details, etc., of the resources involved. Clients and resources areconnected to the the DOMs through software interfaces that translate requests andresults passing through them to the forms required by the various components.

A DOMS architecture includes at least the following:

• a collection of object implementations (DOMS resources), i.e., entitieshaving both state (data) and a set of operations that they can perform.

• client interfaces allowing clients to request objects (or the DOMs) to performoperations, provide the arguments to the operations, and receive results.

• messaging facilities (provided by the DOMs) that forward client requests tothe objects to which they are directed.

• object interfaces allowing the DOMs to invoke the implementations ofobjects in support of client requests.

• a distributed collection of (physical) computer systems that provide theenvironments in which the above components run, and communicationfacilities connecting them.

Figure 2.1 illustrates this generic architecture. The architecture is similar to that of aheterogeneous distributed database system (HDDBMS) in that it provides DOMs,which correspond to distributed data managers, that route requests among

7

components, and use attached components to perform the actual requestedoperations. In addition, it provides a common DOMS object model to provide acommon set of abstractions understood and supported by all the DOMs. This issimilar to the motivation for a common global data model in a HDDBMS, except thatin a DOMS an object model is required, due to the need to model the diverseoperations implemented by the objects in the system. General acceptance (orstandardization) of the object model and interfaces of such an architecture wouldfacilitate independent development of objects and supporting software to function ina DOMS environment. This is in fact the goal of the OMG in specifying andpromoting such an architecture and model.

client object

clientinterface

objectinterface

system 1 system N

common object model

• • •

DOMS

request

one or more DOMs

Figure 2.1. Distributed Object Management.

The object implementations must be such that they support the object interfaceexpected by the DOMS. Such implementations can be created by developingarbitrary modules that conform to published specifications for this interface, throughadapters that tailor existing software to this interface, or automatically through DOMS-provided object construction facilities. Thus, object definition facilities need not befully provided by the DOMS itself. They may simply consist of some mechanismto link independently-implemented objects to the system.

Clients may be conventional programs, or objects (if the attached system is object-oriented). Client interfaces may be provided via a library of subroutine calls, orthrough the use of an interface description language, as found in various remoteprocedure call facilities, whose processor generates stubs that make the appropriatecalls (such a language could also be used in generating parts of object interfaces aswell). In order to deal with heterogeneous objects, both client and object interfacesmust support translation of operation requests, arguments, and results betweendifferent representations. Although this may be done in a pairwise fashion betweeneach client and object implementation, use of the common DOMS object modelreduces the number of type mappings among components. (Use of a common

8

intermediate representation would also reduce the number of representationmappings that must be implemented.)

The messaging facilities must allow clients to transparently invoke operations onremote objects. The DOMs may also provide object execution facilities, possiblyintegrated with the object interfaces, for helping objects carry out requests. Theseinclude dispatching facilities for locating the code that implements an operation ininheritance hierarchies, and facilities for locating object representations in persistentstores and loading them into environments where they can execute. The latter issometimes referred to as activation. These facilities may also support remotedispatching (when an object is remote from its operation code) or object migration,i.e., facilities for moving objects (including method objects) into and out of storageand between sites (translating them if necessary).

A "closed" object system, such as Smalltalk or an OODBMS, typically provides notonly messaging facilities, but also bundles these with the execution facilitiesproviding implementation support for the objects. On the other hand, a DOMSmust accommodate a variety of object implementations. For example, attachingobjects in an OODBMS to a DOM may require only an interface allowing messagesintended for the objects to be passed to the OODBMS, and the results returned tothe DOM; the OODBMS can use its own internal messaging and execution facilitiesto perform the operations without further DOM action. In contrast, supportinginterfaces to independently-developed objects in their own heterogeneousexecution environments requires various degrees of implementation support from aDOM. For example, DOMs should support interfaces to objects defined in terms ofexisting programs and their separate data structures. In response to an invocationrequest for such an object, the DOM should locate the object's representation, locatethe code necessary to carry out the operation, and activate and execute it.

DOMs may also provide other facilities. For example, the DOMs will almostcertainly support name services or repositories providing information about thevarious objects (and their interfaces) in the system. A DOM may also provide moreadvanced facilities, such as support for transactions and queries, or its own closedobject system, directly implementing the common object model, in addition to thefacilities for attaching independently-developed objects or object systems[OSHE91]. Native objects implemented in this closed system could be used toimplement many of the other DOMS facilities.

The architecture does not specify a particular implementation technique for DOMfunctionality, and a number of possibilities exist, including [OMG91a]:

• A DOM could be implemented in routines resident in the clients and(object) implementations, provided communications facilities are available.

9

• A DOM could be implemented as a separate program specializing inrouting requests from clients to implementations, running on a conventionaloperating system.

• A DOM could be implemented on a specialized server with which all clientsand resources could communicate.

• DOM functionality could be provided as services of enhanced operatingsystems.

Another intent of specifications such as [OMG91a] is to gain common acceptance ofspecific interfaces within a DOMS architecture so that different DOM implementationscan interoperate.

Initially, implementations of DOMS architectures will primarily involve existingcomponents not designed to function in this type of environment. As a result, theintegration may be somewhat difficult, and less than optimal in its performance.However, with the increasing use of object technology within the individualcomponents of distributed systems, including user interfaces, programminglanguages, network management software, database systems, and operatingsystems, the boundaries between these components will begin to disappear, andtighter integration will be possible through the development of standard (or at leastwidely accepted) object models, implementations supporting interfaces based onthose models, and object libraries. This will make the integration of componentseasier, and should also greatly improve performance.

2.2 An Example DOMS Architecture

The architecture we are developing is an instance of the generic architecturedescribed above. In it, DOMs serve as object managers both in the sense ofproviding messaging services (as in the ORB) and in the sense of implementingnative objects. These DOMs serve to support database-like functionality, includingboth object queries and transactions, and ultimately higher-level planning facilities. Inaddition, DOMs may manage other "object managers", e.g., OODBMSs, allowingthe effective creation of hierarchies of object managers, including those of attachedsystems as well as other DOMs. Each of the attached resources (which we refer togenerically as applications) has an interface to a DOM. There may be manyapplications interacting via a single DOM. These DOMs communicate with eachother in terms of a common object model, called FROOM (described in Section 3).Further details about this architecture are given in [MANO88].

We refer to the client and object interfaces between attached applications andDOMs generically as Local Application Interfaces (LAIs). An LAI provides aninterface between a DOM and an application that both allows the DOM to accesslocal data and invoke local operations of that application (server functionality), andallows the application itself to make requests to access objects in the distributed

10

object space and DOM services (client functionality). LAIs can also serve asadapters between applications and DOMs. The concept of an LAI is a general one,and specific LAIs can be constructed in many different ways, based on thepeculiarities of the applications, and the ways in which they will be used.

Figure 2.2 illustrates how the architecture is intended to operate in a simple case. Inthis example, there are two nodes, each running one system (an OODBMS and aword processing system), with each system having an LAI to a separate DOM.The DOMs are connected by a communications network. A database object insystem 1 acts as a client, requesting a document object (to which it is assumed tohave a reference) to perform one of its operations. The request goes through theLAI to the DOM at system 1, and is routed to the DOM (at system 2) having an LAIto the document object referenced in the request. The word processing applicationat system 2 is not object-oriented. However, its LAI allows the local DOM to treatthe application's text files as document objects whose operations are implementedby the word processing application (i.e., the application acts as the document classobject). In response to the request, the DOM at system 2 starts the application if itis not already executing, causes the text file corresponding to the document objectreferenced in the request to be loaded, and then invokes the requested operation.

textfile

textfile

system 2

DocumentClass Object

Word Processing Application

document objects

•••

OODBMS

• • •

database objects

system 1

requestnetworkconnection

LAILAI

DOMDOM

DOMS

Figure 2.2. Distributed Object Management: Example

11

This example illustrates how object implementations (resources) can come fromvarious sources, which determine to some extent how they must be coupled witheach other and with the DOMs. They may be:

• objects based on other object models, and having their own objectmanagers, that can be referenced via their LAIs, such as the OODBMSobjects in Figure 2.2

• conventional programs and data that can be referenced via their LAIs as ifthey were objects (or parts of objects), such as the document objects andassociated word processing application in Figure 2.2. This allows existingsystems, such as application programs and databases, to be incorporatedin the DOMS without modifying them to conform to the common objectmodel.

• native objects directly defined in languages based on the common objectmodel, and directly supported by the DOMs (an extension not shown inFigure 2.2).

The next three sections discuss specific aspects of this architecture. Section 3describes the FROOM object model. Section 4 describes the approach we aretaking to transaction management in the DOMS environment. Section 5 describes aprototype implementation of the architecture, and provides further details of both aprototype DOM component, and LAIs for specific attached applications.

3. A DOMS Object Model

An important focus of our work has been the development of an object model to fillthe role of the DOMS common object model described in Section 2. In order tosupport the DOMS requirements we have identified, the model must providefacilities found in advanced OODBMS object models, such as support for objectquery facilities. However, the model must also deal with the particular requirementsof HAD environments. This raises a number of issues that we address in thissection.

The approaches we are pursuing to deal with these issues are in many respects notunique, but rather are consistent with approaches identified in other work indistributed object systems cited in the text. In this section, we describe thecharacteristics of our object model, called FROOM (Functional/Relational Object-Oriented Model), and relate them to key issues in distributed object managementand some of this related work. We concentrate on issues, rather than simplyproviding a full description of FROOM, for a specific reason. In the development ofmodels to support truly open HAD environments, it is less important to define "yetanother object model" than to identify key features of such models which can begenerally accepted. Otherwise, the model will not be practically usable. The work ofsuch groups as the OMG's Object Model Task Force [OMG91b] and the standards

12

groups identified in [FONG91] provide vehicles for obtaining such generalagreement on object model principles.

The rest of this section is structured as follows. Section 3.1 gives an overview of thebasic concepts of FROOM. (A complete, though in some respects preliminary,description of FROOM is given in [MANO90].) Sections 3.2 through 3.6 identifysome (but by no means all) interesting issues that involve modifications orextensions to conventional object model concepts to support HAD environments,and describe how they are addressed in FROOM. Many of the model featuresdescribed in these subsections are not necessarily important only in distributedenvironments. The same features can be justified by the need for improvements inmodularity, reuse, and other considerations. However, HAD system requirementstend to lend added force to some of these considerations.

3.1 Basic Concepts of FROOM

FROOM is primarily a development of concepts in the PDM [MANO86], Iris[FISH89], FUGUE [HEIL88,90], and OODAPLEX [DAYA89] object models.FROOM also has a number of characteristics in common with TEDM [MAIE89] andMDM [RICH91], as well as the object models being developed within the ObjectManagement Group (OMG) [OMG91a,b]. FROOM is based on three primitiveconcepts: object, function, and type. Objects are used to denote applicationabstractions (such as persons or cars), values (such as strings or integers),components of the system (such as network nodes and databases), andcomponents of the model itself (such as functions and types).

Objects play the role of operands or results of operations, called functions inFROOM. A function is a mapping from input objects to output objects. An object isaccessible only through its behavior, i.e., the set of functions that can be applied to it.Functions merge the concepts of operations, attributes and relationships in a singlehigh-level abstraction. A function call (function application expression) correspondsto a message in other object models, and has the form

f(x 1, x 2, ..., x n)

where f is a function name, and each xi is a constant, variable, or other expressionthat denotes an object of f 's i-th input argument type. Function application may be"nested" using conventional functional notation to indicate function composition.

FROOM expressions evaluate to objects. Complex expressions in FROOM aredefined using more primitive expressions that denote or evaluate to objects. Thesimplest forms of expressions are literals, variables, and constants. These formsname their result objects directly. For example, 3 evaluates to the immutable integerobject 3, while the variable x evaluates to the object it refers to. More complexexpressions are built up using aggregate type constructors (such as sets and

13

tuples) and function applications (including predicates, which are functions that returnBooleans). The result of a compound expression of this sort is the object returnedby the outermost operation. FROOM provides a uniform way of dealing with bothobjects and values that allows it to deal with value semantics from attached systemsin a straightforward way.

Each object is characterized by one or more types that describe its behavior. Theobjects associated with a particular type are referred to as instances of the type. Atype determines the set of functions that must be available for application to any ofits instances. An instance of a type may also support functions in addition to thoserequired by its type(s). As is usual in object models, the model includes a numberof built-in types. These include primitive types such as integers, strings, andBooleans, and aggregate types such as tuples and sets. Simple examples ofFROOM type definitions are given below4.

type personfunction name(P: person): string,function children(P: person): {person},function age(P: person): integer,end person;

type shipfunction name(S: ship): string,function crew(S: ship): {person},function captain(S: ship): officer,function location(S: ship, D: date): [X: latitude, Y: longitude],function assign(S: ship, P:person): ship,end ship;

These definitions illustrate functions that model attributes, such as name, relationships,such as children and crew , and operations, such as assign (assign a person toa ship). The definitions also illustrate that functions can have side effects (assignupdates a ship object) and can return individual objects (name returns a string ,captain returns an officer ), tuples (location returns a tuple of latitude andlongitude objects representing a position), or sets (children and crew returnsets of person objects).

Functions have signatures (which specify the name of the function and the types ofits input and output argument objects), and implementations or bodies (whichimplement the semantics of the function). The evaluation of a function body mayinvolve simply returning stored information (as in the name function), or the executionof some procedure. Like its predecessor models, FROOM uses a functionalnotation. However, as currently defined, FROOM associates functions defined intype definitions, such as those above, with the type of the first argument fordispatching purposes. Separately defined functions, called independent functions,can also be defined. For these functions, dispatching can take place based onmultiple arguments (see Section 3.5).

FROOM also supports Event-Condition-Action (ECA) rules based on thosedescribed in [DAYA88,90]. The event part of an ECA rule specifies events related

4 Type names and examples are shown in Courier font to distinguish them from other text.

14

to operations in the system, temporal events, or signals from arbitrary processes.The condition part specifies a set of queries over the object space. The action partspecifies a function call (or set of calls). When the event occurs (is signalled), the ruleis fired: i.e., the condition is evaluated, and if the condition is satisfied (the queriesreturn non-empty answers), the action is executed. Rules can be defined to applyeither to all objects of one or more types, or to individual objects.

Rules, events, conditions, and actions are defined as object types. Various kinds ofevents are defined, including the beginning and ending of operations, temporalevents, and user-defined events, which are detected and signalled by users orexternal programs (e.g., the departure of an airline flight, or the connection of a nodeto the network). Events associated with transactions are used in our transactionmodel (see Section 4).

Supporting only functions at an object's interface unifies the concepts of state andbehavior, as well as the syntax used in accessing them. It also simplifies theinterface, as the same concept is used to represent everything. However, a numberof models include additional constructs such as attributes (modeling abstract state)and relationships (modeling mathematical relations among objects). This is usuallyjustified by the frequency with which they are found in systems to be integrated inHAD environments, and the convenience of having built-in concepts to which to mapthem. Some models also identify special kinds of relationships, e.g., containment,with the operational semantics that operations applied to a containing object shouldbe propagated to objects related to it by containment relationships [FONG91].

FROOM, like a number of other object models intended for database use, includesaggregate values or literals such as sets and tuples as basic types. Such literals areessentially objects that have an identity based on their component members, ratherthan on an object identifier generated by a creation event. Sets of tuples can beused in these models in defining object algebras (see Section 3.6), since theyprovide a perfect model for the results of relational-like queries . Objects havingsuch sets of tuples as state can serve to define n-ary relationships without the needfor explicitly introducing a new model construct [DAYA89, MANO90]. In order toexpress the operational semantics associated with the special kinds of relationshipsmentioned above, FROOM uses rules associated with the sets of tuplesrepresenting relationships. Since the rules can be tailored to the requirements of thespecific relationship involved (e.g., to trigger the propagation of operations tocontained objects), this approach is more general than building in various specializedsemantics such as containment. This approach is described in [DAYA87].

Inclusion of constructs such as attributes and relationships in object models will nothave a serious impact on interoperability, provided the semantics of such constructscan always be expressed behaviorally. For example, [OMG91b] describes amodel in which defining an attribute A is equivalent to defining the operations Get Aand Set A, and defining a relationship R is equivalent to defining the operations AddR, Remove R, and Traverse R. Such mappings can allow the various forms of

15

models to co-exist. Similarly, models based on functions, such as FROOM, mustcapture the sorts of semantic distinctions represented by constructs such asattributes and operations. For example, an updatable function representing abstractstate must be distinguished from a non-updatable function representing a pureoperation. Again, a behavioral specification provides a good way of doing this.There is general agreement that these distinctions need to be captured in interfacesemantics one way or the other. A common behavioral semantics would allow thedifference between the approaches taken in various models to be notational ratherthan fundamental.

3.2 Separation of Type and Implementation

In object models, a type or class plays some, if not all, of the following roles:

a. it defines a collection of objects having exactly the same external behavior,in terms of an interface specification that can be used for type-checking.

b. it defines a collection of objects that have exactly the same implementation,in terms of a specification of the internal data structures and code thatimplements the operations.

c. it defines an object existing at run-time that acts as a "factory" for creatingnew objects, and that holds the operation implementations shared by thecollection.

However, there is an increasing tendency for object models, particularly thoseintended for distributed systems, to not only cleanly separate the specification of theinterface to be provided by an object, role (a), and the implementation of objectsproviding that interface, roles (b) and (c), but also to generalize the way in whichobjects are classified into types. In FROOM and other such object models, objecttypes are defined entirely in terms of a set of function (or operation) signatures. Eachsignature consists of a function name, a set of input argument types, and a set ofoutput argument types. The FROOM person type defined in the last section is anexample of such a type definition.

Separate specifications can then be used to define the implementations of objectsof the specified types. For example, each object could provide its ownimplementation, as in Emerald [RAJ91]. Alternatively, one or more classes playingroles (b) and (c) could be defined as implementation templates for objects of thetype, as in POOL [AMER90]. Provided these object implementations support theinterface defined by the type, they can be considered as legitimate instances of thetype. This separation of type and implementation allows heterogeneousimplementations of objects providing the same capabilities to co-exist within thesystem, and allows objects, provided they maintain existing interfaces, to add newcapabilities, or alter existing implementation decisions, without affecting clients. This

16

is an important advantage in a HAD environment.

The distinction between types and implementation described above is reflected in acorresponding distinction between subtyping and inheritance. In models thatobserve this distinction, subtyping is strictly a relationship between types, andinheritance is strictly a way of composing object implementations (classes) to deriveobject implementations from those of existing objects.

Class-based inheritance can create difficulties in a distributed environment, since itmeans that an object's implementation is based to a certain extent on the classobject. If the object moves, this means that either the class object must move with it,or a remote message must be sent to execute object behavior. Also, if the classhierarchies of different systems have been created autonomously, moving a classinvolves the difficult task determining its position in the class hierarchy of the targetsystem [BENN90]. For these reasons, some systems specifically designed fordistributed applications, such as Emerald and ANSA [ARM89], emphasize objectautonomy, and do not support inheritance, requiring instead that objects define theirown behavior independently of others.

Delegation (which is essentially behavior sharing at the level of objects, rather thanclasses [WEGN90]) is sometimes suggested as a more appropriate mechanismthan inheritance in a distributed system [BENN90]. Objects may delegateresponsibility for executing non-local behavior to parent objects called prototypes,which themselves are objects that may delegate to one or more parents. Thecollection of all objects that share (delegate to) the same prototype is in somerespects like a class, but there is no language-level distinction between objects andclasses. Delegation eliminates the problem of trying to integrate a moved classobject into a new inheritance hierarchy. It does not necessarily eliminate the need tosend remote messages back to the prototype, unless the prototype is moved aswell. This may, however, be done more flexibly than for a class object.

FROOM supports object implementations based on both inheritance anddelegation, and implementations derived in even more general ways, provided thatthey satisfy the interface specifications. For example, the view mechanismsmentioned in Section 3.4 can be used to apply functions to objects at lower levelsof abstraction, such as class objects, to produce new implementations. Thisapproach is described in [HEIL90].

3.3 Conformance-Based Typing

In a conventional object model, the type that an object implementation is intended tosatisfy would be specified along with the implementation itself, creating a fixedrelationship between the object and a type (and, possibly, any supertypes of thattype in an explicit type hierarchy). However, a number of object models, includingEmerald, TEDM, MDM, ANSA, and FROOM, have adopted a more flexiblemechanism called conformance (or conformity) [RAJ91] that determines whether an

17

object is of a specified type by comparing the interface provided by the object withthe interface specified by the type. Intuitively, an object conforms to a type when itsinterface provides at least the functions specified in the type definition (i.e., has thebehavior required of the object by the behavior given in the type specification).

[CANN89] notes that a significant part of the flexibility of untyped object-orientedprogramming is the potential of using any object that can handle a given set ofmessages (satisfies an interface) in a context that sends just those messages(requires that interface), independently of how the messages are implementedinside the object. Conformance-based typing allows both the requirements ofclients and the capabilities of objects to be expressed abstractly, in terms(respectively) of the required and provided interfaces, without being bound tospecific combinations of functions that object implementers have chosen toimplement or that are defined in existing type specifications. Moreover,conformance permits these advantages to be obtained while retaining the ability toperform strong type-checking.

Since conformance is basically a relationship between interfaces, it can also be usedto compare types. An interface (or type) S conforms to a type T if S provides atleast the functions of T (S may have more functions), and the signatures ofcorresponding functions conform5. For example, the type below conforms to thetype person described earlier6:

type person-with-hobbiesfunction name(PH: person-with-hobbies): string,function children(PH: person-with-hobbies): {person},function age(PH: person-with-hobbies): integer,function hobbies(PH: person-with-hobbies): {string}end person-with-hobbies;

The conventional approach to defining subtype relationships among types is toexplicitly declare them, as in C++. However, the conformance relation createsimplicit subtype relationships among defined types (and, in fact, induces a lattice onthese types). With conformance, any type that supplies the interface required bytype T is implicitly a subtype of T, and may be used as such. Thus, conformanceallows the introduction of new supertypes into the type lattice without having tomodify the definitions of existing types (or the structure of the type lattice). Thiscapability is useful, for example, when a more general type is defined after severalmore specific types already exist, a situation which frequently occurs in integratingindependently-developed systems.

The flexibility in defining new types and objects provided by implicit conformancecan sometimes lead to "mistaken" type matches [MANO90, RAJ91]. For example,the object:

new home Hname(H) := "frank's home for wayward waifs"children(H) := {alex, michael, sandy, stan},

5 The details of the rules defining signature conformity are described, e.g., in [RAJ91].6 The first input argument type is ignored, since it denotes the object receiving the function call.

18

age(H) := 2end;

created as an instance of type home (defined with the intention of recordinginformation about children's homes):

type homefunction name(H: home): string,function children(H: home): {person},function age(H: home): integer,end home;

conforms to the type person defined earlier, and a conformance-based systemwould allow the unintended use of a home object as a person (or vice-versa). Theexplicit assignment of objects to particular types, and the explicit declaration ofrelationships among types, prevents such situations, at the cost of being unable tointroduce new types that are related to existing types without explicitly modifyingthe type lattice. In models based on implicit conformance, "mistaken" type matchescan be dealt with by including functions that are specific to the type defined [RAJ91].

This problem simply illustrates the more general issue of how to adequatelydescribe the semantics of objects without involving logic-based specificationlanguages and theorem-proving techniques. FROOM and TEDM allow objects tooptionally be explicitly assigned to specific types (objects support functions thatallow them to be queried for their types). Other models simply use enhancedsignatures. For example, the object model currently defined for the OMG's ObjectRequest Broker [OMG91a] includes exceptions raised by an operation, and anindication of whether the operation is expected to respond or not, as distinguishingcharacteristics in operation signatures. POOL [AMER90] enhances type definitionswith identifiers called properties, which can be compared to determine if two objectssupporting the same behavior should be considered as having the same type, andFUGUE includes the use of pre- and post-conditions in determining when objectfunctions can be considered equivalent.

These considerations suggest the usefulness of further work on type mechanisms inthe development of distributed object systems. They also illustrate the need forrepository-like components providing access to object metadata, such as the ANSAtrader [ARM89], which can be used to assist in matching client requirements withobject capabilities in HAD environments.

3.4 Multiple Object Interfaces and Views

The conventional concept of an object is that of an entity having a single interface orobject boundary separating the interior of the object from its clients. In class-basedmodels, this generally means that the entire set of instance variables defined in aclass is visible to each method defined in the class, and the set of operations definedby a class form a single interface that is visible to all other objects. However, it hasbecome increasingly clear that, in fact, objects often effectively have multiple

19

interfaces. As a result, FROOM, and other recent models, provide facilities to makesuch interfaces explicit, and to generalize the object interfaces that can be defined.

Multiple interfaces are useful because different parts of an object system often havedifferent requirements for their access to objects. For example, class variables inSmalltalk are accessible by instances of the class in the same way as local variables,but are actually shared by all instances of the class, and are stored in the class object.This creates two forms of object interaction in the model, one via message passing,and one via variable access up the class hierarchy. This can create complicationsboth in implementation, and enforcing mutual exclusion on accesses to the classvariables. Class inheritance can also be thought of as violating encapsulation bypermitting methods defined for new subclasses to access inherited instancevariables. C++ friend functions illustrate another specialized access requirementdiffering from that of an ordinary client. [TOML89] notes that such compromises ofencapsulation exist because conventional objects provide only a singleencapsulation boundary, defining a single abstract interface, and this is ofteninsufficient. An approach to dealing with this issue in a disciplined way is to explicitlyprovide objects with multiple interfaces tailored to the distinct requirements of theaccessing components, rather than providing various (often implicit) special cases.This allows the creation of more strongly encapsulated objects, which in turn allowsnew flexibility in how objects may be composed to provide new abstractions.

Additional requirements are imposed by the introduction of distribution andconcurrency into object models, as required in the support of HAD systems. Forexample, [WEGN90] distinguishes three distinct types of object interfaces that couldbe defined. An abstraction boundary specifies the interface between an object andits clients, and the form in which resources provided by an object to its clients maybe invoked. A distribution boundary is the boundary of locally accessible namesvisible from within an object (looking outward, as opposed to the abstractionboundary, which defines visibility looking inward), i.e., the boundary that determineswhen a reference is local or non-local. A synchronization boundary specifies the unitof concurrency, and defines the boundary at which threads entering an objectsynchronize with ongoing activities within the object.

A database-like view facility can support the definition of new objects (or, morespecifically, new interfaces) in terms of existing objects, in some cases through ahigh-level specification language such as a query language or object algebra (seeSection 3.6). FROOM, and other object models associated with database-orientedprojects such as FUGUE, explicitly support the construction of new objects andinterfaces in this way. Views can also be used to support inheritance [MANO90,WEGN90].

Other models also support objects with multiple interfaces. In the ANSA model,objects provide an encapsulation boundary which is effectively similar to thedistribution boundary described above. Each object can provide one or moreinterfaces (each with a distinct identity) consisting of sets of operations as in

20

conventional objects. In the MDM model, an object may have multiple aspects.Each aspect presents a different interface, and may encapsulate its own state andbehavior. The same operation may appear in the interface of more than one aspectof the same object without conflict. Aspects in MDM, like interfaces in the ANSAmodel, in many respects take over the abstraction role played by objects in othermodels. Another model using a view-like approach is described in [SCHI89].

3.5 Generalized Functions

In many object models, operations are associated with exactly one object type.There is no concept of an operation being defined independently of an object type,or of an operation being defined for two or more object types. Such models aresometimes referred to as classical or messaging object models, since the abstractionis of a message being sent to exactly one object for execution. In such a model,when an operation is invoked, a specific body of code is selected for execution.This selection, which is referred to as resolution or dispatching, is based on the typeof a single distinguished object supplied in the call (this is the object to which themessage is directed in a language such as Smalltalk, or the first argument object in asubroutine call notation).

FROOM supports independent functions, or functions defined for two or moreobject types, where dispatching may be based on the types of multiple arguments.Such a model is sometimes referred to as a generalized object or generalizedfunction model, other examples being CLOS [STEE90], PDM, OODAPLEX, Iris,FUGUE, and one of the models in [OMG91b]. For example, a finite elementanalysis program for an engineering application might be defined in FROOM as:

function feanalysis(M: model, LO: load, O: integer): model;

This function takes an input model M (e.g., of a structure such as a bridge), an objectLO representing the loads being applied to the input model, and an option O, andreturns the deformed model (e.g., the bridge as it would appear if the loads wereapplied) resulting from the analysis. In FROOM, this declaration creates a newobject of type function , whose name is feanalysis , and which existsindependently of other object types.

There has been considerable discussion of the merits of object models supportinggeneralized functions. Models lacking them must resort to explicit multipledispatching in cases where operations are polymorphic on more than one argument[INGA86]. This involves defining additional operations at the interfaces of objectsspecifically to support the additional levels of dispatching, which tends tocompromise the abstraction provided by the object in order to provide support forwhat in some sense is an implementation mechanism. It also breaks up whatordinarily might be thought of as single procedural abstractions into different piecesassociated with the different object types involved.

21

On the other side, arguments have been advanced that the generalized functionmodel compromises object encapsulation by requiring the generalized operations tohave access to the states of all argument objects. These arguments appear to havegreater force when applied to object models supporting only one interface perobject than to models, such as FROOM, supporting multiple interfaces per object.In such models, it is possible to define objects representing the generalizedfunctions, and argument objects having one interface for ordinary clients, and otherinterfaces containing any additional operations needed to support generalizedfunctions and multiple dispatching. In this case, the implementation of multipledispatching can be defined using messages, and yet concealed from ordinaryclients. This is an important consideration in a HAD system, in which messages arenot just synonyms for function calls, but may involve real communication betweendistributed objects.

The ability to define independent functions allows procedures of arbitrary complexityto be included in the model. This is important for HAD environments where some ofthe objects in attached systems will be programs or other components havinglargely procedural semantics. FROOM models such abstractions as objects havingan invoke (or apply) function defined at their interface.

3.6 Object Algebra

The definition of FROOM includes an object algebra that resembles an extendedrelational algebra. The concepts used are based largely on those in PDM algebra[MANO86], OOAlgebra [DAYA89] and EQUAL [SHAW89], but also includeconcepts from object logics, e.g. [MAIE86, KIFE89]. The algebra is not intended foruse by either programmers or end users, but as a notation for defining the basicfunctions to be built into implementations of the object model, and for defining thesemantics of expressions in high-level query languages. Such languages providethe means for specifying global queries involving objects in the distributed objectspace supported by a DOMS. If the objects involved are supported by attachedheterogeneous components (DBMSs or other repository managers), the DOMSmust map such queries through object algebra expressions into expressions in thelocal query languages of the attached systems.

The relational algebra defines a set of high-level operators that operate on relations(sets of tuples of values) and produce new relations. Similarly, object algebrasgenerally (and the FROOM algebra specifically) define a set of high-level operators(functions in the case of FROOM) for aggregates of objects, such as sets or sets oftuples of objects. Such algebras also allow functions or operations defined forindividual component objects in these aggregates to be applied, creating newaggregates as results. Like the operations of the relational algebra, the operations ofobject algebras can be composed to form more complex expressions. Theseexpressions are themselves composite functions that map objects or sets ofobjects of specified types to other objects. As in PDM and OOAlgebra, but unlikeEQUAL, the aggregates resulting from evaluating FROOM algebra functions are

22

immutable, so new object identifiers are generated only when this is explicitlyspecified. This is consistent with the use of these tuples primarily as transient sets ofbindings in the formation of query results.

Currently the FROOM algebra provides the following classes of functions:

• Functions corresponding to operations of the relational algebra--select(restriction), project , and join . As in the relational algebra, several typesof join are supported.

• The standard set operators union , intersect , difference , overarbitrary sets of objects (they need not be sets of tuples), and unique forduplicates removal. Identity comparison is used in determining when twoobjects are equal (and thus, different effects are obtained depending onwhether the objects are mutable or immutable).

• append(P,f) which, given a set of tuples P, applies the specified functionf defined for objects in one of the columns of P to arguments taken fromother columns of P. The result is a new set of tuples formed by appendingto P a new column containing the result of the function evaluation. This is akey operation of the algebra, since it allows the invocation of arbitraryobject-defined functions within expressions of the algebra, and theincorporation of the results of these functions into the results of theseexpressions.

• createobj(P,O) , which given a set of tuples P, returns a new set oftuples in which each tuple of P is concatenated with a new object identifier asa value of column O. Variants of this operation allow creation of type-specific object identifiers, or composite identifiers indicating an existencedependency between a derived object and the base objects from which itwas derived (these are used in creating views).

• Other miscellaneous functions for renaming columns, forming tuples ofobjects and values, and nesting and unnesting embedded substructures.

Future work on the FROOM algebra will address two difficult issues that are thesubject of much current research: first, providing general facilities for creating arbitrarynew objects and functions using algebra expressions; second, determining anoptimum set of algebra functions for use in query optimization. The first of theseinvolves using the algebra to create both function objects and their associatedbodies, and allowing function bodies defined in arbitrary languages, not just thealgebra itself, to be manipulated, and combined into new objects. This is a basicmechanism that can be used for providing extensibility in the object model withoutnecessarily requiring that the object algebra itself be computationally complete. Thesecond involves comparing the optimization characteristics of relational-leveloperations, such as those in FROOM, with operations of other object algebras, such

23

as EQUAL, that are individually more complex than those described above.

4 DOMS Transaction Management

Supporting database-like functionality in a DOMS requires support for transactionswhich access objects that may represent data and functionality in attached systems.To do this, the DOMS must deal with the autonomy and heterogeneity of theattached systems. The problem of transaction management in multidatabaseenvironments has been investigated extensively, and a number of solutions havebeen proposed in the literature. Various extended transaction models have alsobeen proposed to allow, among other things, compensation and nesting ofdistributed and multidatabase transactions. The approach we are taking (and which isstill under development) is to identify an extended transaction model that capturesthe capabilities of these (and other) extended transaction models, so as to providethe basis of a programmable transaction management facility that allows the definitionand construction of specific extended transaction models corresponding toapplication requirements.

Transactions in a DOMS issue operations on objects that belong in one of thefollowing categories:

• Attached objects that represent data and functionality in local systems thatthemselves support transactions. This category includes autonomous andheterogeneous database systems, which we refer to as Local DatabaseSystems (LDBSs). There are file systems and programming languagesystems that also provide built-in transaction support, e.g., Argus [LISK88].However, the transaction management facilities in these systems aregenerally similar and in the following discussion we do not distinguish themfrom LDBSs.

• Attached objects that represent data and functionality in local systems thatprovide only basic atomic operations. Objects and systems in thiscategory do not support transactions, i.e., do not provide primitives thatallow the composition of complex atomic operations from an arbitrarycollection of basic atomic operations. We use the term transactionlesssystems to refer to systems in this category.

• Native objects whose state and behavior are supported by the DOMSitself. Objects in this category either implement their own transactionmanagement mechanism, or use the facilities of a DOMS-provided globalscheduler for operation synchronization, as in a distributed DBMS. If anobject implements its own transaction management, the DOMS may haveno access to its local concurrency control information (e.g., local serializationorder, local lock table, and wait-for graph).

24

To be considered an LDBS, an attached system must provide BeginTransaction,PreparedToCommit, Commit (EndTransaction) and Abort (Rollback) operations inits interface. Many commercial DBMSs satisfy or are in the process of satisfying thisrequirement. These transaction management operations must also be available atthe interfaces of native objects, and of attached objects that represent functionality ofLDBSs.

Some of these objects may be active, in the sense that they can executeoperations concurrently, and can (from the point of view of other objects) initiateactions asynchronously, without having received a message. Due to the presenceof local transactions and local operations in a DOMS environment, autonomousLDBSs and associated attached objects can be viewed as active objects in thissense [WEGN90].

The DOMS must support two general classes of transactions. Multi-systemtransactions are extended transactions that have constituent (flat) transactions that areeither executed at different LDBSs, or perform a single atomic operation at anattached transactionless system. Multidatabase transactions are a special case ofmulti-system transactions in which flat transactions are submitted only to objectssupported by LDBSs, or to native objects. In addition to multi-system (global)transactions that are submitted to the DOMS, the architecture allows local transactionsto be submitted directly to a single LDBS, and local operations to be invokeddirectly at individual transactionless local systems. It is assumed that unless attachedsystems are specifically designed to provide access to local concurrency controlinformation, the DOMS has no information about the behavior or even the existenceof local transactions and local operations.

In Section 4.1 we describe extended transaction models, identifying the basiccomponents of extended transactions common to many transaction models, and thedependencies (interrelations) between components that vary from one model toanother. To allow application designers to specify many extended transactionmodels and build the required control structures, our transaction model supportsexplicit specification of these dependencies. Dependencies are specified asFROOM functions, called Dependency Descriptors. Each specification is associatedwith a corresponding (rule-based) implementation. Dependency descriptors areused to define complex transaction objects that represent extended multi-systemtransactions. These transactions allow compensation, and hence, produce correct butnon-serializable executions. In section 4.2, we show how to use the samemechanism to construct multidatabase transactions in cases where globalserializability must be assured.

4.1 Specification of Extended Transactions

[BUCH91] shows that extended transaction models [BEER89, ELMA90,GARC87, MOSS85, PU88] can be characterized by the transaction structure, theobject types, and the correctness criteria they support. Examples of transaction

25

structures are flat transactions [BERN87], closed nested transactions [MOSS85],open nested transactions such as Sagas [GARC87] and split transactions [PU88],and combinations of these types. For example, the transaction model described in[ELMA90] allows nested, compensatable, and alternative transactions inmultidatabase environments. From the point of view of transaction management,object types are characterized as either supporting or not supporting transactions,and as either simple or complex. Complex objects contain references to otherobjects, and hence operations on them can spawn (implicitly nested) transactions oncomponent objects. Finally, the correctness criterion determines the acceptablehistories that result from the the execution of concurrent transactions in the model.Serializability is widely used as a correctness criterion in database systems, andthere are a number of conflict serializability-based correctness criteria that differ mainlyin how they define a conflict [WEIH88, HERL90, BADR87]. However, serializabilityis too restrictive for many applications, and various alternative correctness criteria andassociated mechanisms have been proposed. For example, transaction classes[BERN80, GARC83], hierarchical levels of transaction compatibility [LYNC83],predicatewise serializability [KORT88], and quasi-serializability [DU89] can be usedin multidatabase and DOMS environments.

The DOM transaction model [BUCH91] allows the definition of complex transactionscorresponding to a wide range of these transaction concepts. The basic mechanismfor doing this involves the observation that transactions in any of these extendedtransaction models consist of a set of traditional (flat) transactions, together with a setof transaction dependencies among them. For example, consider an extendedtransaction T={TT, TD}, where TT={T1,T2,T3,T4} is the set of flat transactions of Tand TD is the set of dependencies between them. If we assume that T3 is acontingency transaction for T2, T4 is the compensating transaction of T1 and T1 isvital, TD contains the following dependencies:

1. T2 can commit only if T1 commits,

2. T3 must abort if T2 commits (or alternatively, T3 can commit only if T1commits and T2 aborts), and

3. T4 can begin only if T1 commits and both T2 and T3 abort.

The commit-commit dependencies between T1 and T2 and T1 and T3 representthe fact that T1 is vital. The commit-begin dependency between T1 and T4,represents that T4 is a compensating transaction for T1. The abort-commit andcommit-abort dependencies represent that T3 is a contingency transaction for T2.

Given an extended transaction model, we can effectively describe it by identifyingthe types of transaction dependencies it allows. Basic transaction dependencies,such as the commit-commit, commit-begin and abort-begin dependencies justdescribed, specify the execution structure of extended transactions. Dependenciesin this category are called transaction state dependencies and are conditions on the

26

state of transactions. Given two transactions Ti and Tj, such dependencies aredefined by conditions of the following type: Tj can begin/prepared-to-commit/abort/commit only if Ti has entered its begin/prepared-to-commit/abort/commit state. For every transaction state dependency there is also acorresponding strong transaction state dependency. Strong transaction statedependencies are conditions of the following type: Tj must begin/prepared-to-commit/abort/commit only if Ti has entered its begin/prepared-to-commit/abort/commit state.

Another category of basic transaction dependencies are serialization orderdependencies, which are conditions on the relative serialization order of transactions.To deal with the autonomy of attached objects and associated systems, and also theencapsulation of concurrency control and recovery mechanisms in native objects thatimplement their own transaction management, both local and global transactionserialization order dependencies must be defined. Consider two transactions Ti andTj that execute concurrently in multiple objects O1, O2, ... Ok (and associated localsystems). A locally-serialized-before (-after) dependency between Ti and Tj at Ol,1 ≥ l ≥ k, is defined as follows: if Ti and Tj conflict directly or indirectly in Ol then Ti canprecede (succeed) Tj in the local serialization order at Ol. On the other hand, Ti andTj have a globally-serialized-before (-after) dependency at O1, O2, ..., Ok, if Ti andTj have locally-serialized-before (-after) dependencies in all objects they executetogether. Strong serialization order dependencies can be defined as with transactionstate dependencies. A dependency in this category requires that transactions musthave the same serialization order in multiple concurrent/active objects O1, O2, ... Ok(and associated local systems). Two transactions Ti and Tj have a serialization-order-compatibility dependency if there are no objects Op and Oq among O1, O2, ..., Ok,such that, Ti is locally serialized before Tj in Op and Tj is locally serialized before Ti inOq.

Visibility dependencies specify when a transaction can observe the effects ofanother transaction. For example, visibility dependencies include basicdependencies that are based on the concepts of cascadelessness [BERN87],strictness [BERN87], and rigorousness [BREI91]. Other possible dependenciesinclude priority dependencies that determine the order in which two transactionsshould be processed, and temporal dependencies that specify the time at, before,after and/or between a transaction should enter a particular state. An example ofsuch a dependency is, start Ti at 3 pm .

While transaction state and temporal dependencies specify the execution structureof extended transactions, visibility and serialization dependencies specifycorrectness criteria. This collection of basic transaction dependencies is notnecessarily complete or optimal. A subset of these transaction state and visibilitydependencies has been identified in [CHRY91].

We model transactions as dynamically-created objects [WEGN90]. A simpletransaction object is a flat transaction that issues operations on native objects only,executes operations on attached objects that are associated with the same LDBS,or issues a single operation that can be executed atomically by a transactionless

27

local system. (Transactions that issue several operations on a transactionlesssystem are not considered simple objects. They are specified as extended multi-system transactions). Simple transaction objects support the basic transactionmanagement operations BeginTransaction, EndTransaction (Commit) ,PreparedToCommit and Rollback (Abort).

We model extended multi-system transactions as complex objects. To definecomplex transaction objects from simple transaction objects (and other complextransaction objects), we use the concept of Dependency Descriptors (DDs).Dependency descriptors are FROOM functions that describe the interrelationshipsbetween transaction objects in terms of transaction dependencies. Each DD isrepresented by a tuple (DS, DI), where DS is a the Dependency Specification andDI is a corresponding Dependency Implementation. DS is a symbolicrepresentation of the dependency (e.g., the signature of the function that defines it),while DI specifies how to invoke and control system provided primitives in order toassure DS (e.g., the body of the function). Although DIs can be programs written ina general purpose programming language, to allow more flexibility and modularitywe intend to use ECA rules to implement DSs. ECA rules defined in DIs aretriggered by events caused by transactions when they enter a particular state (e.g., atransaction commits), issue read or write operations on objects, priority, and time.The use of DDs is intended to allow application designers to define extendedtransaction models by using what is effectively a transaction specification language.In addition, specifications of popular extended transaction models could beprovided as predefined rule sets, and application designers can combinecomponents of different models and their corresponding control structures to formtheir own.

The specification of the extended transaction T above illustrates the use of DDs.The commit-commit (cc) dependency between T1 and T2 (cc(T1,T2)) can bespecified and implemented by the following DD:

DDccDScc: cc(T1,T2)DIcc: ON Commit(T1) & Prepared-to-Commit(T2) DO Commit(T2)

Similarly, the commit-abort (ca) dependency between T2 and T3 (ca(T2,T3)), andthe abort-begin (ab) dependency between T3 and T4 (ab(T3,T4)), can bespecified as:

DDca DDabDSca: ca(T2,T3) DSab: ab(T3,T4)DIca: ON Commit(T2) DO Abort(T3) DIab: ON Abort(T3) DO BeginTransaction(T4)

The DDs that define the the commit-begin dependency between T1 and T4, andthe abort-begin dependency between T2 and T4 are similar to DDab above. Toavoid defining multiple DDs for the same transaction dependency type, we specifytransaction IDs as DD parameters. For instance, we use DDcc(T1,T2) to denoteDDcc above, and DDca(T2,T3) to represent DDca.

28

There are two important advantages that result from the separation of specificationand implementation of transaction dependencies. First, DIs can be tuned as needed.For example, given a DS we can take advantage of the facilities that are providedby different attached systems by writing different rules (or, if necessary, programs)for each system. Second, the collection of all different types of DSs for an extendedmultidatabase transaction model can be augmented by conjunction (and possiblyother constructors such as disjunction, sequence and closure), to form a transactionspecification language. For example, the following conjunctions of DSs specify T:DScc(T1,T2), DSca(T2,T3), and DScb(T1,T2) & DSab(T2,T4) & DSab(T3,T4).The latter is a composite DS that can be implemented by the DI:

ON [Commit(T1) & Abort(T2) & Abort(T3)] DO BeginTransaction(T4).

In this composite DD, the conjunction of basic dependency specifications isimplemented by an ECA rule that is triggered by a composite event, i.e., theconjunction of the basic events that appear in the DIs of the basic DSs inDScb(T1,T2) & DSab(T2,T4) & DSab(T3,T4). Automatic generation of compositeDDs from basic DDs is trivial in most cases.

In addition to their use in specifying and constructing extended and multidatabasetransactions, DDs can be used for specifying various notions of consistencybetween related objects. In this role, DDs implement ECA rules that triggertransactions to carry out the appropriate consistency restoration procedures whenone of the related objects is updated.

4.2 Multidatabase Transactions

In this section we consider a particularly important special case of DOMStransactions, multidatabase transactions, and discuss the DDs required for theirspecification. A multidatabase transaction G is a multi-system transaction thatconsists of subtransactions T1, T2, ..., Tk, each of which is submitted as a flattransaction to a different LDBS. Here we assume that LDBSs assure localserializability, and that multidatabase transactions must be atomic (i.e., preserveglobal serializability and behave as flat transactions).

To describe this multidatabase transaction model we first identify the basictransaction dependencies that describe its transaction structure and correctnesscriterion. The following dependencies specify that a multidatabase transaction Gbehaves like a flat transaction: G has a strong abort-abort dependency with each ofits subtransactions (i.e., G must abort if any subtransaction aborts) and a compositestrong commit-commit dependency with all its subtransactions (i.e, all subtransactionsmust commit if G commits). To assure global serializability, the subtransactions of Ghave a composite serialization-order-compatibility dependency (i.e., allsubtransactions of G must be serialized the same way in all LDBSs they access).

29

The next step is the implementation of the DDs. The specification andimplementation of DDs for commit-commit and abort-abort dependencies wereillustrated earlier. To implement the composite serialization-order-compatibilitydependency, the DOMS must assure that the subtransactions of the multidatabasetransaction are serialized the same way in all LDBSs. However, the local serializationorders of the subtransactions are neither reported by the local database systemsand associated attached objects, nor can they be determined by controlling thesubmission of the subtransactions or observing their execution order. In particular,while the DOMS can control the execution of the operations of multidatabasetransactions, and detect direct conflicts involving multidatabase transactions, theDOMS has no information about local transactions and the indirect conflicts they maycause between multidatabase transactions. Thus, although all local schedules areserializable, the DOMS has no way of determining whether the global schedule isglobally serializable [GEOR90,91a]. It can be shown that this problem exists evenif the semantics of the operations involved are taken into account [WEIH88].

To assure global serializability in DOM multidatabase environment, we are pursuingthe following approaches. The first is useful only when active objects and associatedLDBSs use concurrency control mechanisms that allow only rigorous schedules[GEOR90]. Rigorous schedulers and schedules disallow conflicts betweenuncommitted transactions. It has been shown [BREI91, GEOR90] that thecommitment order of the transactions in a rigorous schedule determines their relativeserialization order. Thus, if all objects and associated LDBS use rigorous schedulers,the DOMS can enforce global serializability by assuring that the commitment orderof each multidatabase transaction is consistent in all objects and LDBSs. In such anenvironment, global serializability is assured as a side-effect of the 2-Phase Commitprotocol supported by the objects involved. The class of rigorous concurrencycontrol mechanisms includes many popular schedulers [BREI91].

To determine the local serialization order of multidatabase transactions in objects andLDBSs that use non-rigorous schedulers, we are pursuing another approach that isbased on the concept of a ticket [GEOR91a]. A ticket is a (logical) timestamp. Forobjects that represent data and functionality of autonomous LDBSs, the value of theticket is stored as a regular data value in each LDBS. In native objects implementingtheir own transaction management, the ticket value is part of the accessible objectstate. Each subtransaction of a multidatabase transaction is required to perform aTake-A-Ticket operation, which consists of reading the value of the ticket andincrementing it through regular data manipulation operations. Since the value of aticket and all operations on tickets issued at each object or system are subject to localconcurrency control, Take-A-Ticket operations force direct conflicts between thesubtransactions of a multidatabase transaction at each object and associated localsystem. Therefore, the ticket values obtained by multidatabase transactions at eachobject and LDBS determine their local serialization order [GEOR91a]. Only a singleticket value is needed per LDBS (i.e., all objects that represent data of the sameLDBS share the same ticket value), and only the subtransactions of multidatabasetransactions must take tickets; local transactions are not affected. Furthermore, ticketsdo not require modification of the local systems and thus do not violate local

30

autonomy. We are basing multidatabase concurrency control in our DOMS on thefamily of ticket-based methods described in [GEOR90]. One of these methods iscalled the Optimistic Ticket Method (OTM) [GEOR91a]. To assure globalserializability OTM requires all subtransactions of each multidatabase transaction totake tickets, compares their ticket values and permits the commitment ofmultidatabase transactions only when their relative serialization order is the same in allparticipating LDBSs. OTM requires the LDBSs to guarantee only localserializability.

Similar problems exist in assuring global consistency of multidatabase transactions inthe presence of transaction and site failures. The basic problems in multidatabaserecovery and corresponding solutions that address each of these problems arediscussed in [BREI90, WOLS90, GEOR91b]. Multidatabase recovery in ourDOMS is being developed using the approach described in [GEOR91b].

5. A Prototype Implementation

In order to gain experience with some of the issues involved in distributed objectmanagement, a prototype DOM component was implemented, together with atestbed consisting of several DOMs, and the LAIs and attached systems requiredto support a simple office automation service. Specifically, LAIs were developedfor the Apple Macintosh Hypercard application, the Sybase relational DBMS,and the ONTOS object DBMS, systems having distinctive characteristics thatprovided a basis for investigating various distributed object management issues. Inone scenario implemented using this testbed, formatted data about persons isstored in Sybase, and image and sound data (persons' photos and voices) inONTOS. This data is integrated with data maintained in Hypercard to support aHypercard person stack that acts as a user interface to the complete data. Figure5.1 shows an example component configuration for this service. Each attachedsystem remains autonomous, in that it is unmodified, and local users of the systemcan interact with it independently of any network interactions.

HyperCard 3HyperCard 2HyperCard 1 HyperCard 4

DOM 1

Sybase Ontos

Non-DOM, autonomousSybase Users

Non-DOM, autonomousOntos Users

DOM 2

DOM 3 DOM 4

LAI 2 LAI 3

LAI 1

Figure 5.1. Example Office Automation Network

31

The prototype DOM and Sybase LAI were developed on the SunSPARCstation2 running the UNIX operating system. The HyperCard LAI wasdeveloped on the Macintosh using the System 6 Macintosh operating system. Thisis being converted to System 7 in order to investigate using its interapplicationcommunication facilities. System management tools with graphics interfaces weredeveloped on the Macintosh using the Macintosh toolbox, and on the Sun platformusing X Windows with OSF/Motif. All software was written in the C and C++programming languages. Network communication is via Ethernet using TCP/IP,using the BSD socket libraries on the Sun platform, and MacTCP on the Macintosh.

This section describes various aspects of this prototype. The discussion here isnecessarily brief. Full details of the prototype are given in [HORN91].

5.1 The Prototype Distributed Object Manager

The core of the testbed architecture is the prototype DOM component. The DOMcomponent acts as a specialized server for managing distributed interactions amongattached systems, and provides an object-oriented distributed programmingenvironment for developing the required interfaces to, and mappings between,these systems. The DOM supports native objects, whose implementation isdefined by the DOM itself, as well as objects whose implementation is provided byattached systems. The DOM is multi-threaded, and can support multiple clients, i.e.other DOMs, LAIs, or attached systems.

The DOM implements an earlier (and simplified) version of the FROOM objectmodel. In this simplified model, objects are defined as instances of specific types,which define object properties (state) and operations (behavior). Definition of aproperty implicitly defines get and set operations for the property, which may beoverridden if desired. Subtype relationships are explicitly defined between types(rather than being derived by conformance, as described in Section 3). Subtypescan inherit and redefine properties and operations defined in supertypes. Multipleinheritance is supported. An individual object can also define object-specific stateand behavior in addition to that defined by its type.

The representation of a native object has a header and one or more chunks. Theheader contains the object's identifier (oid), the oid of its type, and pointers to itschunks. Each object contains a chunk for itself, for its type, and for each of itssupertypes in the type lattice. A type chunk contains a value for each propertydefined for that type. The object's own chunk contains any object-specific propertiesor operations defined for that object.

Due to the possibility of object-specific operations, the DOM uses late binding ofproperty and operation names. Message dispatching first checks the receivingobject itself to determine if the operation is implemented locally before checking thetype lattice as in a more conventional object system. To reduce the overhead

32

associated with this process, the DOM uses a method cache, which can hash fromthe receiving object's oid and the operation name directly to the method code if themethod has been executed previously.

Types are first class objects of type DomType, and may be created, modified(including changing positions in the type lattice), and deleted at runtime. The DOMprovides incremental compilation and linking of operation code so that operations canbe added to objects at runtime. DomType defines a property extent that holds theset of the type's instances if (optional) automatic extent maintenance is chosen forthe type. Each DOM supports persistence for its local object space by writing andreading its local object space to and from disk.

The DOM also supports an implementation of a subset of the FROOM objectalgebra. The operations of the algebra are defined as operations on typeDomSetOfTuple , whose instances are sets of objects of type DomTuple . A querydecomposer has also been implemented can that transform algebra expressionsexpressed using types defined as views to expressions using base types. This isused in transforming global queries to queries over types implemented by attachedsystems. An SQL-like DOM Query Language (DQL) based on this algebra isunder development.

The prototype DOMs support object identity in a distributed object space by usingoids consisting of a local object identifier - lattice identifier pair. A separate typelattice with a root type of DomObject exists for each DOM. Within a type lattice, theDOM assigns each object a unique local object identifier. Unique lattice identifiers areassigned by a global authority to each new lattice. The availability of the latticeidentifier in an oid allows a local DOM to transparently determine when a messagemust be forwarded to a remote DOM because the object is located there. Thecurrent DOM only supports migration of object state for general object types, since,in the current prototype, migration of behavior would involve migrating the typeobject, and determining its position in the local type lattice. This restriction will belifted later, when conformance-based types are implemented. Primitive types, suchas DomInteger , DomString , DomDate, etc., are defined on all DOMs. Theseeither use a special oid format encoding their values (DomInteger ), or have auniversal lattice identifier. This allows objects of these types to be moved freelybetween DOMs, since their behavior is guaranteed to exist on all DOMs. EachDOM also has copies of the types implementing the DOM object model itself (seebelow). This distributes common object functionality throughout the network.

The DOM provides a set of object manipulation routines called the DOM InterfaceLibrary (DIL). DOM methods and applications are C programs containing calls toDIL routines. The principal DIL routine is DOMinvoke , which instructs an object toperform one of its operations. An interpreted DOM Programming Language (DPL)has also been developed. Each DOM contains an interpreter (an object of typeDomEvaluator ) which executes DPL scripts by calling DIL routines. DOMs cansend messages containing these scripts to a remote DOM for processing. Typescan be defined in a DOM Type Definition Language, whose processor generatesthe required objects to implement the type. Alternatively, types can be created at

33

runtime by sending messages to type DomType.

The prototype DOM does not currently support concurrency control and recoveryfacilities for native objects. These are planned in later development stages, basedon the work described in Section 4. Facilities have been built into the prototype toact as the basis for the implementation of transaction and rules mechanisms. Forexample, objects can have notify requests associated with them. These requestsdefine messages that the object will send under specified circumstances.Operations can also have pre- and post-triggers associated with them. The testbedcurrently supports a limited form of "distributed commit" protocol for transactionsinvolving the multiple attached systems. This is implemented as part of thebehavior of the objects involved.

The DOM software itself consists of four layers of object types. Types in the BasicObject Model layer implement the minimal DOM object model for a stand-alone,single-threaded application. Types in the Distributed Object Capabilities layer usethese types to support inter-DOM communication. Types in the LAI layer use bothlower layers to define the DOM portion of application type mapping. Types in theDOM Applications layer use all three lower levels. These types are defined byusers when implementing applications using DOM as a development platform (asopposed to implementing an application as an external program and connecting it toDOM via an LAI). For example, several graphical tools for managing andmanipulating a DOM object space have been implemented as DOM applications.These tools provide facilities for browsing the network configuration, monitoring andarchiving network traffic, browsing, creating, or modifying types and objects in remotesystems, and sending messages to invoke or test component behavior.

5.2 Local Application Interfaces

An LAI must provide an interface between a DOM and an application that allows theDOM to access local data and invoke local operations of that application (serverfunctionality), and allows the application to access both objects in the distributedobject space and DOM services (client functionality). The basic approach forproviding server functionality is to define DOM object types to represent the variousaspects of the attached system that need to be accessible to the DOM. Theseobjects are then implemented partially using DOM facilities, and partially usingfacilities of the attached system. The basic approach for providing client functionalityis to provide calls or some other mechanism allowing the attached system to invokeoperations on any DOM objects.

Some of the many possible variations in LAI design were explored in developingthe LAIs for the systems comprising the office automation service illustrated in Figure5.1. To support this service, the DOM component DOM1 defines an object typeOAPerson that serves the same role as a global schema type in a heterogeneousDBMS. The HyperCard LAI, LAI1, can request person data through OAPersonwithout needing to know where it comes from. Type OAPerson is defined in terms

34

of types SybasePerson and OntosPerson , which respectively represent theSybase and ONTOS data as DOM types. These types are defined as part of theLAIs for their respective systems, and define how to obtain the appropriate datafrom their respective databases. The following sections describe some aspects ofthese LAIs. The details are described in [HORN91].

5.2.1 Sybase LAI Overview

Creating the LAI for the Sybase relational DBMS involved dealing with generalprinciples of mapping relational DBMSs into the DOM environment, as well asfeatures specific to Sybase. Due to the requirements of the office automationservice, only server functionality was implemented in the Sybase LAI (clientfunctionality could have been provided in a straightforward way, using the SybaseOpen Server facility). Specific server functions in the Sybase LAI included facilitiesto create or delete databases and relations, read, update, or delete tuples, begin,commit, or abort transactions, and translate DOM queries into Sybase SQL queries.Because Sybase provides an application program interface (API), operations ofSybase LAI types could be implemented by directly invoking Sybase libraryroutines.

A number of DOM types were defined as part of this LAI to represent Sybaseconcepts in the DOM object space. For example, the concepts of relation and tuplein Sybase were mapped to DOM concepts of type and object, respectively.Type SybRelation was defined as a subtype of DomType with behavior to createnew relations, and to select, insert, delete, and update tuples. This behavior wasimplemented using Sybase SQL. Instances of this metatype (a type, likeDomType, whose instances are types) correspond to relations within Sybasedatabases. For example, an instance of SybRelation called SybasePersonwas created to correspond to a PERSON relation in Sybase. SybasePerson is atype that has instances corresponding to tuples in the PERSON relation. DOM typeswere also defined for other required concepts, such as databases (typeSybDatabase ) and handles identifying connections with particular database servers.

SybasePerson specifies properties that correspond to the attributes of the relation.These properties maintain the materialized data values from the PERSON relation.Each SybasePerson property maintains special mapping information between theDOM property specification and the corresponding Sybase relation attribute. Forexample, the SybasePerson property with name lastName and typeDomString is mapped to the PERSON attribute surname with type varchar(20) .Tuples in relational databases such as Sybase are identified by (key) values, unlikeDOM objects, which are identified by oids. During application processing, instancesof type SybasePerson maintain correspondences between their oids and thecorresponding Sybase tuple.

35

5.2.2 HyperCard LAI Overview

HyperCard is a hypertext, multi-media authoring system [APPL89]. TheHyperCard user deals with data structures which resemble stacks of index cards,each of which can contain text or graphics, as well as links to other cards or stacks. Acard's state is represented in part by fields holding string data. A card can alsocontain references to image and sound resources. Behavior, in the form of scriptswritten in HyperTalk, HyperCard's programming language, can be associated withspecific stacks, cards, fields, or buttons located on cards. Cards that have identicalfields, buttons, and images can place those items in a common background.Creating cards from a background allows the new cards to have the characteristicsdefined by the background.

Creating the LAI for the HyperCard application involved dealing with generalprinciples of mapping applications into the DOM environment, as well as featuresspecific to HyperCard. It also involved dealing with a heterogeneous platform andoperating system environment. Because HyperCard serves both as a userinterface and an independent data repository in the office automation service, bothclient and server functionality were designed for the HyperCard LAI, althoughcurrently only client functionality has been implemented. Specific client functions inthe HyperCard LAI included facilities to convert DOM types to card backgroundsand convert DOM objects to cards with specific backgrounds, as well as generalfacilities to access DOM objects from scripts in HyperTalk, and transfer databetween DOM and HyperCard. Server functions included facilities to accessHyperCard objects (stacks, cards, buttons, fields, etc.), create and delete suchobjects, get and set attributes of objects, and convert card backgrounds to DOMtypes.

The basis of the client interface is a set of external commands (XCMDs) allowingHyperTalk scripts to send messages to the DOM (an XCMD is the HyperCardmechanism for calling programs written in other languages). For example, thesemessages are used in the office automation service to access DOM OAPersonobjects providing data for cards in the HyperCard person stack.

Because the HyperCard LAI involved creating an interface not only to a specificapplication (HyperCard), but also to a different platform and operating environment(the Macintosh), LAI facilities were separated into those specific to HyperCard, andthose of a generic Macintosh environment gateway providing facilities for interfacingbetween DOM objects and data structures and operations common to theMacintosh environment. This gateway can be used by any Macintosh application(not just Hypercard) to interact with DOM, and thus can serve as a common part ofany LAI in the Macintosh environment. A similar structure can be useful in creatingLAIs in other environments. The Macintosh gateway supports facilities forapplications to send messages asynchronously to DOM objects, and providestranslations between DOM types and standard formats in the Macintoshenvironment, such as the PICT format for images.

36

As in the case of the Sybase LAI, providing server functionality involved defining anumber of DOM types as part of the HyperCard LAI to represent HyperCardconcepts in the DOM object space. For example, type HcBackground wasdefined as a subtype of DomType with behavior to create and delete backgrounds.DOM types were also defined for other required concepts, such as fields (typeHcField ) and buttons (type HcButton ).

HyperCard was not designed to act as a server, as was Sybase. Thus, it does notprovide an API for use by external programs. As a result, HyperCard serverfunctionality was designed through the use of an XCMD adapted to respond to auser "release" of HyperCard, allowing it to wait for messages sent from DOM, andrespond by invoking the corresponding HyperCard script.

6. Conclusion and Future Work

In this paper, we have indicated that future information systems will increasingly bedriven by requirements for the integration of heterogeneous components, bothprograms and databases, and the easy reuse of such components, to address newrequirements. We believe that extensions to a number of object technologies,which we characterize under the general heading of Distributed Object Management(DOM) technology, will be the key enabling technologies allowing this to take place.We have briefly described the requirements for DOM technology, the aspects ofobject technologies requiring extension in this new environment, and some workbeing performed at GTE Laboratories to address some of the related technicalissues.

The next phase of research activity in our project will involve further work on both theobject and transaction models, and their closer integration. Work on the object modelwill involve improvements in certain parts of the type system, enhancements to theview mechanisms, better integration of rules into the type system, refinements to thequery algebra, and investigation of additional implementation aspects of the model.Work on the transaction model will involve further investigation of mechanisms formultidatabase transactions and recovery, and their extension to generalized activeobjects.

The next phase of prototype development activity will focus on implementing thetransaction model. This will require improving the persistent storage mechanism andobject management features of the current DOM prototype, as well as incorporatingrules and active objects. To improve the DOM development environment, we planto continue work on the DOM Programming Language (DPL), and implementing acompiler or translator for it.

A number of research groups are pursuing solutions to the many technical issuesraised by DOM technology. These activities, together with the efforts of industrygroups, will provide a primary means for the coalescing of various technical solutionsinto the means for constructing truly interoperable systems.

37

Acknowledgements

The authors would like to thank Alex Buchmann, Daniel Rios Zertuche, Tamer Özsu,and the past and current members of the DOM development team, Joe Morrison,Farshad Nayeri, Vivek Virmani, and Dinesh Desai, for their contributions to the workdescribed here. The authors would also like to thank the referees for their veryhelpful comments on an earlier draft of this paper.

7. References

[AMER90] P. America and F. van der Linden, "A Parallel Object-OrientedLanguage with Inheritance and Subtyping", in N. Meyrowitz, ed., OOPSLAECOOP '90 Proceedings, ACM, Oct., 1990, SIGPLAN Notices, 25(10), Oct.,1990.

[APPL89] Apple Computer, Inc., Getting Started with HyperCard, 1989.

[ARM89] The ANSA Reference Manual, Architecture Projects ManagementLimited, Poseidon House, Castle Park, Cambridge, U.K., 1989.

[BADR87] B.R. Badrinath and K.Ramamritham, "Semantics-Based ConcurrencyControl: Beyond Commutativity", In Proc. 3rd Int. Conf. on Data Engineering, LosAngeles, February 1988.

[BEER89] C. Beeri, P. A. Bernstein, and N. Goodman, "A Model for Concurrencyin Nested Transaction Systems", J. ACM (April 1989), 36(2).

[BENN90] J. K. Bennett, "Experience With Distributed Smalltalk", Software--Practice and Experience, 20(2), February 1990.

[BERN80] P. A. Bernstein, D. W. Shipman, and J. B. Rothnie, "ConcurrencyControl in a System for Distributed Databases (SDD-1)", ACM Trans. DatabaseSyst. (March 1980), 5(1).

[BERN87] P. A. Bernstein, V. Hadzilacos, and N. Goodman, Concurrency Controland Recovery in Database Systems, Reading, Mass.: Addison-Wesley, 1987.

[BREI90] Y. Breitbart, A. Silberschatz, and G. Thompson, "Reliable TransactionManagement in a Multidatabase System", Proc. .ACM SIGMOD Intl. Conf. onManagement of Data, May 1990.

[BREI91] Y. Breitbart, D. Georgakopoulos, M. Rusinkiewicz, and A. Silberschatz,"On Rigorous Transaction Scheduling", IEEE Trans. Software Engineering, 17(9),September 1991.

38

[BUCH91] A.P. Buchman, et.al., "A Transaction Model for Active Distributed ObjectSystems", in A. Elmagarmid (ed.), Advanced Transaction Models for NewApplications, Morgan-Kaufmann, 1992.

[CANN89] P. S. Canning, et. al., "Interfaces for Strongly-Typed Object-OrientedProgramming", in N. Meyrowitz, ed., OOPSLA '89 Conference Proceedings, ACM,Oct., 1989, SIGPLAN Notices, 24(10), Oct., 1989.

[CHRY91] P.K. Chrysanthis, "ACTA, A Framework for Modeling and Reasoningabout Extended Transactions", Ph.D. thesis, Department of Computer andInformation Science, University of Massachusetts, 1991.

[DAYA87] U. Dayal, et. al., "Simplifying Complex Objects: The PROBEApproach to Modelling and Querying Them", in [ZDON89].

[DAYA88] U. Dayal, A. P. Buchmann, and D. R. McCarthy, "Rules are ObjectsToo: A Knowledge Model For an Active, Object-Oriented Database System", in[DITT88].

[DAYA89] U. Dayal, "Queries and Views in an Object-Oriented Data Model", in[HULL89].

[DAYA90] U. Dayal, M. Hsu, and R. Ladin, “Organizing Long-Running Activitieswith Triggers and Transactions”, Proc. 1990 ACM SIGMOD Intl. Conf. onManagement of Data, Atlantic City, NJ, May 1990.

[DITT88] K. R. Dittrich, ed., Advances in Object-Oriented Database Systems,Lecture Notes in Computer Science #334, Springer-Verlag, 1988.

[DU89] W. Du and A. Elmagarmid, "Quasi-serializability: A Correctness Criterion forGlobal Concurrency Control in InterBase", Proc. 15th Int. Conf. on Very Large DataBases, Amsterdam, August 1989.

[ELMA90] A. Elmagarmid, Y. Leu, W. Litwin. and M. Rusinkiewicz, "AMultidatabase Transaction Model for Interbase", In Proc. 16h Int. Conf. on VeryLarge Data Bases, Brisbane, Australia, August 1990.

[FISH89] D. H. Fishman, et. al., "Overview of the Iris DBMS", in [KIM89].

[FONG91] E. Fong, et. al. (eds), "X3/SPARC/DBSSG/OODBTG Final Report",interim draft of 17 September 1991.

[GARC83] H. Garcia Molina, "Using Semantic Knowledge for TransactionProcessing ion A Distributed Database", ACM Trans. Database Systems (June1983), 8(2).

[GARC87] H. Garcia Molina and K. Salem, “Sagas,” Proc. SIGMOD 87, SanFrancisco, May 1987.

39

[GEOR90] D. Georgakopoulos. "Transaction Management in MultidatabaseSystems"; Ph.D. thesis, Houston, TX: Department of Computer Science, Universityof Houston, 1990.

[GEOR91a] D. Georgakopoulos, M. Rusinkiewicz and A. Sheth, "On Serializabilityof Multidatabase Transactions Through Forced Local Conflicts", Proc. 7th Intl. Conf.on Data Engineering, IEEE, 1991.

[GEOR91b] D. Georgakopoulos, "Multidatabase Recoverability and Recovery",Proc. First Intl. Workshop on Interoperability in Multidatabase Systems, IEEE, April1991.

[HEIL88] S. Heiler and S. Zdonik, "Views, Data Abstraction, and Inheritance in theFUGUE Data Model", in [DITT88].

[HEIL90] S. Heiler and S. Zdonik, "Object Views: Extending the Vision", Proc. 6thIntl. Conf. on Data Engineering, Los Angeles, Feb. 1990.

[HERL90] M. Herlihy, "Apologizing versus Asking Permission: OptimisticConcurrency Control for Abstract Data Types", ACM Trans.Database Syst. (March1990), 15(1).

[HORN91] M. F. Hornick, J. D. Morrison, and F. Nayeri, "IntegratingHeterogeneous, Autonomous, Distributed Applications using the DOM Prototype",TR-0174-12-91-165, GTE Laboratories Incorporated, December, 1991.

[HULL89] R. Hull, R. Morrison, and D. Stemple (eds.), Database ProgrammingLanguages, Proc. 2nd Intl. Workshop, Morgan Kaufmann, San Mateo, 1989.

[INGA86] D. H. H. Ingalls, "A Simple Technique for Handling MultiplePolymorphism", in [N. Meyrowitz, ed., OOPSLA '86 Conference Proceedings,ACM, Sept., 1986, SIGPLAN Notices, 21(11), Nov., 1986.

[ISO79] International Standards Organisation, "Reference Model of Open SystemsInterconnection", ISO/TC97/SC15 N227, August 1979.

[KIFE89] M. Kifer and G. Lausen, "F-Logic: A Higher-Order Language forReasoning about Object, Inheritance, and Scheme", Proc. ACM SIGMOD 89,1989.

[KIM89] W. Kim and F. H. Lochovsky (eds.), Object-Oriented Concepts,Databases, and Applications, ACM Press / Addison-Wesley, 1989.

[KORT88] H.F. Korth and G.D. Speegle, "Formal Model of Correctness WithoutSerializability", Proc. ACM SIGMOD Intl. Conf. on Management of Data, June1988.

40

[LAMP81] B. W. Lampson, M. Paul, and H. J. Siegert (eds.), Distributed Systems- Architecture and Implementation, Springer-Verlag, 1981.

[LISK88] B. Liskov, "Distributed Programming in Argus", Comm. ACM, 31(3),March 1988.

[LYNC83] N. Lynch, "Multilevel Atomicity: A New Correctness Criterion forDatabase Concurrency Control", ACM Trans. Database Syst. (December 1983),8(4).

[MAIE86] D. Maier, "A Logic for Objects", Workshop on Foundations of DeductiveDatabases and Logic Programming, Washington, D.C., August 1986.

[MAIE89] D. Maier, J. Zhu, and H. Ohkawa, "Features of the TEDM Object Model",in W. Kim, J.-M. Nicolas, and S. Nishio, eds., Proc. First Intl. Conf. on Deductive andObject-Oriented Databases, Elsevier Science Publishers, Amsterdam, 1989.

[MANO86] F. Manola and U. Dayal, "PDM: An Object-Oriented Data Model", in[ZDON89].

[MANO88] F. Manola, "Distributed Object Management Technology", TM-0014-06-88-165, GTE Laboratories Incorporated, June 30, 1988.

[MANO90] F. Manola and A. P. Buchmann, "A Functional/Relational Object-Oriented Model for Distributed Object Management: Preliminary Description", TM-0331-11-90-165, GTE Laboratories Incorporated, December 31, 1990.

[MOSS85] E. Moss, Nested Transactions, MIT Press, Cambridge, MA, 1985.

[OMG91a] Object Management Group, "The Common Object Request Broker:Architecture and Specification", OMG Document Number 91.12.1, Draft 10December 1991.

[OMG91b] Object Management Group Object Model Task Force, "The OMGObject Model", draft 0.9, OMG Document Number 91.9.1, September 3, 1991.

[OSHE91] H. Osher, "Distributed Object Management", Object Magazine, 1(3),Sept./Oct. 1991.

[PAPZ92] M. P. Papazoglou and T. K. Sellis, "An Organizational Framework forCooperating Intelligent Information Systems", in this issue.

[PU88] C. Pu, G. Kaiser, and N. Hutchinson, "Split-Transactions for Open-EndedActivities", Proc. 14th Int. Conf. on Very Large Data Bases, August 1988.

[RAJ91] R. K. Raj, et. al., "Emerald: A General-Purpose Programming Language",Software--Practice and Experience 21(1), January 1991.

41

[RICH91] J. Richardson and P. Schwartz, "Aspects: Extending Objects to SupportMultiple, Independent Roles", Proc. 1991 ACM SIGMOD Intl. Conf. onManagement of Data, ACM, New York, 1991..

[RUSI91] M. Rusinkiewicz, A. Sheth, and G. Karabatis, "Specifying InterdatabaseDependencies in a Multidatabase Environment", Computer, 24(12), December1991.

[SCHI89] J. J. Shilling and P. F. Sweeney, "Three Steps to Views: Extending theObject-Oriented Paradigm", in N. Meyrowitz, ed., OOPSLA '89 ConferenceProceedings, ACM, Oct., 1989, SIGPLAN Notices, 24(10), Oct., 1989.

[SHAW89] G. M. Shaw and S. B. Zdonik, "An Object-Oriented Query Algebra", in[HULL89].

[STEE90] G. L. Steele, Jr., Common LISP - The Language (2nd ed.), DigitalPress, 1990.

[TOML89] C. Tomlinson and M. Scheevel, "Concurrent Object-OrientedProgramming Languages", in [KIM89]

[WEGN90] P. Wegner, "Concepts and Paradigms of Object-OrientedProgramming", OOPS Messenger, 1(1), ACM, August 1990.

[WEIH88] W. Weihl, "Commutativity-Based Concurrency Control for AbstractData Types", IEEE Trans. Comp. (December 1988), 37(12).

[WILL91] G. I. Williamson and M. Azmoodeh, "The Application of InformationModelling in the Telecommunications Management Network (TMN)", Proc.Telecommunications Information Networking Architecture Workshop (TINA91),March 1991.

[WOLS90] A. Wollski and J. Veijalainen, "2PC Agent Method: AchievingSerializability in Presence of Failures in a Heteroneous Multidatabases", Proc.PARBASE-90, February 1990.

[ZDON89] S. Zdonik, and D. Maier (eds.), Readings in Object-Oriented DatabaseSystems, Morgan Kaufmann, 1989.