systems. We identify the key aspects of system architectures supporting distributed ... distributed object management system being developed at GTE ...... system. Therefore, the ticket values obtained by multidatabase transactions at each.
1 Distributed Object Management1 Frank Manola, Sandra Heiler, Dimitrios Georgakopoulos, Mark Hornick, and Michael Brodie GTE Laboratories Incorporated Waltham, Massachusetts 02254 U.S.A. Abstract Future information processing environments will consist of a vast network of heterogeneous, autonomous, and distributed computing resources, including computers (from mainframe to personal), information-intensive applications, and data (files and databases). A key challenge in this environment is providing capabilities for combining this varied collection of resources into an integrated distributed system, allowing resources to be flexibly combined, and their activities coordinated, to address challenging new information processing requirements. In this paper, we describe the concept of distributed object management, and identify its role in the development of these open, interoperable systems. We identify the key aspects of system architectures supporting distributed object management, and describe specific elements of a distributed object management system being developed at GTE Laboratories. 1. Introduction Today, computer usage is expanding into all parts, and all functions, of large organizations. This can be seen in the widespread appearance of powerful personal computers for desktop use, and powerful workstations for more specialized uses. Such computers are becoming commonplace in routine business functions of all kinds. As a result of the continuation of this trend, future information processing 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 and databases). With the appearance of increasing numbers of such HAD computing resources, there is an increasing need for technology allowing such resources to be flexibly combined, and their activities coordinated, to create network-wide integrated distributed systems that address challenging new information processing
1 Appeared in International Journal of Intelligent and Cooperative Information Systems 1, 1 June
1992. 2 Since we are located near Boston, we pronounce "HAD" as "hahd", in the same way that native Bostonians pronounce "hard". This is appropriate given the potential complexity of systems having these characteristics.
2 requirements. In some cases, these systems may combine resources belonging to different individuals or organizations, in support of various social, governmental, or business activities (e.g., connections between customer inventory systems and supplier order-entry systems). In this paper, we describe the concept of distributed object management, and identify its role in the development of these open, interoperable systems. In the rest of this paper, we first describe the motivation for developing distributed object management technology, the goals for systems based on it, and additional requirements imposed on object technology by these goals. We then identify the key aspects of system architectures supporting distributed object management, and describe specific elements of a distributed object management system being developed at GTE Laboratories. The requirements for creating HAD systems can be met in two phases. The first phase is interconnectivity. Most current computer systems are disjoint, and unable to communicate with other systems. Two or more computing resources are interconnected if they can exchange messages. However, interconnectivity guarantees only communication. It does not guarantee that the resources understand each other sufficiently to meaningfully interact or cooperate. The second phase is the more ambitious goal of interoperability. Two or more resources are interoperable if they can interact to jointly execute tasks. Simple tools for achieving interoperability are increasingly being provided in the form of programming capabilities such as remote procedure call facilities. More advanced forms of interoperability require mutual understanding not only at the level of complete systems or programs, but also at the data type level. This is necessary in order to support the integration of heterogeneous information in, for example, advanced multimedia applications (such as office automation), and to support the storage 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 intelligent themselves and capable of functioning as intelligent agents concerning their computing capabilities. Distributed query processing is a very simple example of this form of interoperability in the domain of database management in which a global access plan is developed that attempts to optimize the use of individual database systems attached to a network. In this case, the intelligent interaction is achieved by an external global query optimizer (planner) component. Other capabilities that may be involved in intelligent interoperability include advanced forms of synchronization to coordinate access to shared resources, and the use by cooperating components of knowledge about each others' activities to optimize overall performance. This form of interoperability is considered in [PAPZ92]. It is well known that interoperable HAD systems introduce technical problems in addition to those found in conventional systems, including [LAMP81]:
3 •
Naming, protection, sharing, and translation issues resulting from component heterogeneity.
•
Accounting and resource management issues created by component autonomy.
•
Synchronization, consistency, error recovery, and other control problems resulting 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 Open Systems Interconnection Reference Model [ISO79] identified the use of layers containing services with well-defined interfaces, with the services being further divided into (possibly-distributed) modules, as key concepts in structuring complex interoperable systems. As a continuation of this emphasis on interfaces and modules, there is increasing agreement that modeling a distributed system as a distributed collection of interacting objects (in the sense of object-oriented programming) provides the appropriate framework for use in integrating HAD resources, in both distributed computing and telecommunications environments [WILL91]. This is illustrated by the increasing number of standards activities related to HAD systems, including communications and distribution standards, database and programming language standards, and repository standards, that are moving toward adopting, or have already adopted, an object-oriented approach [FONG91]. These activities include not only those of official standards bodies, such as ISO and ANSI, but also those of industry consortia, such as the Open Software Foundation and the Object Management Group [OMG91a]. Objects form a natural model for a distributed system because distributed components can only communicate with each other using messages addressed to well-defined interfaces, and components are assumed to have their own locallydefined procedures enabling them to respond to messages sent them. Objectoriented programming, distributed or not, simply carries this model down to the level at which the "components" are individual application abstractions, or even individual data items, rather than the systems or nodes in a distributed network. This use of objects also naturally accomodates many of the heterogeneous and autonomous aspects of HAD systems: heterogeneous because messages sent to distributed components depend only on the component interfaces, not on the internals of the components, and autonomous because components may change independently and transparently, provided their interfaces are maintained. The use of the object abstraction in integrating heterogeneous and autonomous components is also a characteristic of recent developments in personal computer application integration software, such as Hewlett-Packard's NewWave, Object Linking and Embedding (OLE) in Microsoft Windows, and interapplication communication (IAC) facilities in the latest Apple Macintosh operating system. In this case the components are application programs and their associated data. The goal is to
4 integrate individual applications, such as word processing, spreadsheet, or graphics programs, by treating them as the definitions of operations on text, spreadsheet, or graphics "objects" (represented by the usual files associated with each application). Compound "documents" can then be created by including instances of the various available types of objects. Operations peculiar to each type of object, e.g., updating a graphic figure, are automatically routed to the associated application for execution. An object-oriented DBMS (OODBMS) provides an environment that integrates 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 application program accessing the object database only needs to know how to send appropriate messages to the various types of objects; the code associated with the objects handles the details of dealing with the heterogeneous data formats involved. The basic idea behind distributed object management is to continue these trends in object-oriented distributed system models, application integration environments, and OODBMSs, to the point at which the complete set of resources available on a distributed network, including computers, network facilities, data, programs, etc., can be treated as a commonly-accessible collection of objects which can be combined in arbitrary ways to provide new information processing capabilities. Intelligent interoperability in the context of such a distributed object system would allow the set of resources available on the network to be treated much like the objects in an advanced object database system. A client would not only have access to the available objects in the system via interfaces defined in a common object model, but could also submit a request expressed at a very high level, and potentially involving large 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 to a collection of objects created by this approach as an object space. Distributed object management then describes the task of managing a distributed object space in the same sense as distributed database management describes the task of managing a distributed database. We refer to a system performing this distributed object management task as a Distributed Object Management System (DOMS). Ultimately, this concept of distributed object management is intended to support capabilities including: •
The ability to integrate existing, separately-developed collections of objects and data, as in a heterogeneous DBMS.
•
The ability to integrate heterogeneous data types, including both conventional formatted data and unconventional data types such as sound and image data, as in an object-oriented DBMS.
5 •
The ability to provide DBMS-like functionality for the integrated collection of objects, including query processing, concurrency control, and recovery.
•
The ability to use existing applications in defining object operations, as in the application integration software described above.
•
The ability to integrate resources at whatever level of granularity is appropriate, including objects that represent entire nodes or database systems, as well as objects that represent individual application abstractions such as points, rectangles, or employees.
•
The ability to invoke and synchronize the execution of combinations of such objects anywhere in the network, and to move data or objects as necessary, 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 programming systems, and incorporate design decisions that create difficulties when they are integrated with others in HAD environments. Object technology in the HAD environment must, for example, support persistence and concurrency (parallelism), and deal with both homogeneous (within components) and heterogeneous (among components) type systems, languages, and computing paradigms. These concerns are similar to those raised by Peter Wegner in describing megaprogramming, or "programming in the very large" [WEGN90]. The required technology, which we refer to as distributed object management technology3, involves generalizing and combining technology from such areas as object-oriented and distributed programming languages, operating systems, and object database systems, integration and transaction management technology from heterogeneous database systems, and, particularly in the support of intelligent interoperability, distributed artificial intelligence. Much of this technology is actively being developed in these various technical communities, and our own project is not attempting to duplicate these activities. Our own work has concentrated on the development of architectural and object model concepts, together with associated facilities for object interaction, query processing, and transaction management, with the intent of combining technology, such as object and process migration, communication protocols, etc. from the many other areas involved, to create complete systems. Such combination of technology is also the approach being taken by the industry consortia mentioned earlier. The next three sections describe our work in the selected areas mentioned, and indicate the relationship of this work to current industry and research developments in these areas. 2. DOMS Architecture
3
A more thorough discussion of how various technologies contribute to distributed object management 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 to those found in various systems for managing objects in HAD environments and, in particular, to that defined by the Object Management Group for its Object Request Broker (ORB) [OMG91a]. In Section 2.2, we describe the specific specialization of the generic architecture being developed in our project. 2.1 A Generic DOMS Architecture A DOMS consists of an arbitrary number of distributed (physical) nodes, each running one or more application programs, database systems, objects (if the system is object-oriented), etc. that constitute its computing resources, and a collection of clients (which may also be application programs, software tools, objects, etc.) that make requests for operations to be performed by these resources. One or more Distributed Object Managers (DOMs) act as intermediaries between these clients and resources. DOMs make the computing resources of the system appear to be objects (whether they are actually object-oriented or not), with the DOMs acting as object managers, permitting clients to make requests involving resources that reside anywhere in the system without having knowledge of the location, implementation details, etc., of the resources involved. Clients and resources are connected to the the DOMs through software interfaces that translate requests and results 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., entities having both state (data) and a set of operations that they can perform.
•
client interfaces allowing clients to request objects (or the DOMs) to perform operations, provide the arguments to the operations, and receive results.
•
messaging facilities (provided by the DOMs) that forward client requests to the objects to which they are directed.
•
object interfaces allowing the DOMs to invoke the implementations of objects in support of client requests.
•
a distributed collection of (physical) computer systems that provide the environments in which the above components run, and communication facilities connecting them.
Figure 2.1 illustrates this generic architecture. The architecture is similar to that of a heterogeneous 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 requested operations. In addition, it provides a common DOMS object model to provide a common set of abstractions understood and supported by all the DOMs. This is similar to the motivation for a common global data model in a HDDBMS, except that in a DOMS an object model is required, due to the need to model the diverse operations implemented by the objects in the system. General acceptance (or standardization) of the object model and interfaces of such an architecture would facilitate independent development of objects and supporting software to function in a DOMS environment. This is in fact the goal of the OMG in specifying and promoting such an architecture and model. DOMS system 1 client
system N
•••
client interface
object
object interface request
one or more DOMs
common object model
Figure 2.1. Distributed Object Management. The object implementations must be such that they support the object interface expected by the DOMS. Such implementations can be created by developing arbitrary modules that conform to published specifications for this interface, through adapters that tailor existing software to this interface, or automatically through DOMSprovided object construction facilities. Thus, object definition facilities need not be fully provided by the DOMS itself. They may simply consist of some mechanism to link independently-implemented objects to the system. Clients may be conventional programs, or objects (if the attached system is objectoriented). Client interfaces may be provided via a library of subroutine calls, or through the use of an interface description language, as found in various remote procedure call facilities, whose processor generates stubs that make the appropriate calls (such a language could also be used in generating parts of object interfaces as well). In order to deal with heterogeneous objects, both client and object interfaces must support translation of operation requests, arguments, and results between different representations. Although this may be done in a pairwise fashion between each client and object implementation, use of the common DOMS object model reduces the number of type mappings among components. (Use of a common
8 intermediate representation would also reduce the number of representation mappings that must be implemented.) The messaging facilities must allow clients to transparently invoke operations on remote objects. The DOMs may also provide object execution facilities, possibly integrated with the object interfaces, for helping objects carry out requests. These include dispatching facilities for locating the code that implements an operation in inheritance hierarchies, and facilities for locating object representations in persistent stores and loading them into environments where they can execute. The latter is sometimes referred to as activation. These facilities may also support remote dispatching (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 storage and between sites (translating them if necessary). A "closed" object system, such as Smalltalk or an OODBMS, typically provides not only messaging facilities, but also bundles these with the execution facilities providing implementation support for the objects. On the other hand, a DOMS must accommodate a variety of object implementations. For example, attaching objects in an OODBMS to a DOM may require only an interface allowing messages intended for the objects to be passed to the OODBMS, and the results returned to the DOM; the OODBMS can use its own internal messaging and execution facilities to perform the operations without further DOM action. In contrast, supporting interfaces to independently-developed objects in their own heterogeneous execution environments requires various degrees of implementation support from a DOM. For example, DOMs should support interfaces to objects defined in terms of existing programs and their separate data structures. In response to an invocation request for such an object, the DOM should locate the object's representation, locate the code necessary to carry out the operation, and activate and execute it. DOMs may also provide other facilities. For example, the DOMs will almost certainly support name services or repositories providing information about the various objects (and their interfaces) in the system. A DOM may also provide more advanced facilities, such as support for transactions and queries, or its own closed object system, directly implementing the common object model, in addition to the facilities for attaching independently-developed objects or object systems [OSHE91]. Native objects implemented in this closed system could be used to implement many of the other DOMS facilities. The architecture does not specify a particular implementation technique for DOM functionality, 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 in routing requests from clients to implementations, running on a conventional operating system.
•
A DOM could be implemented on a specialized server with which all clients and resources could communicate.
•
DOM functionality could be provided as services of enhanced operating systems.
Another intent of specifications such as [OMG91a] is to gain common acceptance of specific interfaces within a DOMS architecture so that different DOM implementations can interoperate. Initially, implementations of DOMS architectures will primarily involve existing components not designed to function in this type of environment. As a result, the integration may be somewhat difficult, and less than optimal in its performance. However, with the increasing use of object technology within the individual components of distributed systems, including user interfaces, programming languages, network management software, database systems, and operating systems, the boundaries between these components will begin to disappear, and tighter integration will be possible through the development of standard (or at least widely accepted) object models, implementations supporting interfaces based on those models, and object libraries. This will make the integration of components easier, and should also greatly improve performance. 2.2 An Example DOMS Architecture The architecture we are developing is an instance of the generic architecture described above. In it, DOMs serve as object managers both in the sense of providing messaging services (as in the ORB) and in the sense of implementing native objects. These DOMs serve to support database-like functionality, including both object queries and transactions, and ultimately higher-level planning facilities. In addition, DOMs may manage other "object managers", e.g., OODBMSs, allowing the effective creation of hierarchies of object managers, including those of attached systems as well as other DOMs. Each of the attached resources (which we refer to generically as applications) has an interface to a DOM. There may be many applications interacting via a single DOM. These DOMs communicate with each other 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 and DOMs generically as Local Application Interfaces (LAIs). An LAI provides an interface between a DOM and an application that both allows the DOM to access local data and invoke local operations of that application (server functionality), and allows the application itself to make requests to access objects in the distributed
10 object space and DOM services (client functionality). LAIs can also serve as adapters 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 the peculiarities 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. In this example, there are two nodes, each running one system (an OODBMS and a word processing system), with each system having an LAI to a separate DOM. The DOMs are connected by a communications network. A database object in system 1 acts as a client, requesting a document object (to which it is assumed to have a reference) to perform one of its operations. The request goes through the LAI to the DOM at system 1, and is routed to the DOM (at system 2) having an LAI to the document object referenced in the request. The word processing application at system 2 is not object-oriented. However, its LAI allows the local DOM to treat the application's text files as document objects whose operations are implemented by the word processing application (i.e., the application acts as the document class object). In response to the request, the DOM at system 2 starts the application if it is not already executing, causes the text file corresponding to the document object referenced in the request to be loaded, and then invokes the requested operation.
DOMS
system 2 Document Class Object system 1
Word Processing Application
OODBMS •••
document objects text file
database objects
•••
LAI
LAI
DOM
DOM request
text file
network connection
Figure 2.2. Distributed Object Management: Example
11 This example illustrates how object implementations (resources) can come from various sources, which determine to some extent how they must be coupled with each other and with the DOMs. They may be: •
objects based on other object models, and having their own object managers, that can be referenced via their LAIs, such as the OODBMS objects in Figure 2.2
•
conventional programs and data that can be referenced via their LAIs as if they were objects (or parts of objects), such as the document objects and associated word processing application in Figure 2.2. This allows existing systems, such as application programs and databases, to be incorporated in the DOMS without modifying them to conform to the common object model.
•
native objects directly defined in languages based on the common object model, and directly supported by the DOMs (an extension not shown in Figure 2.2).
The next three sections discuss specific aspects of this architecture. Section 3 describes the FROOM object model. Section 4 describes the approach we are taking to transaction management in the DOMS environment. Section 5 describes a prototype implementation of the architecture, and provides further details of both a prototype 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 fill the role of the DOMS common object model described in Section 2. In order to support the DOMS requirements we have identified, the model must provide facilities found in advanced OODBMS object models, such as support for object query facilities. However, the model must also deal with the particular requirements of HAD environments. This raises a number of issues that we address in this section. The approaches we are pursuing to deal with these issues are in many respects not unique, but rather are consistent with approaches identified in other work in distributed object systems cited in the text. In this section, we describe the characteristics of our object model, called FROOM (Functional/Relational ObjectOriented Model), and relate them to key issues in distributed object management and some of this related work. We concentrate on issues, rather than simply providing a full description of FROOM, for a specific reason. In the development of models to support truly open HAD environments, it is less important to define "yet another object model" than to identify key features of such models which can be generally accepted. Otherwise, the model will not be practically usable. The work of such groups as the OMG's Object Model Task Force [OMG91b] and the standards
12 groups identified in [FONG91] provide vehicles for obtaining such general agreement on object model principles. The rest of this section is structured as follows. Section 3.1 gives an overview of the basic concepts of FROOM. (A complete, though in some respects preliminary, description of FROOM is given in [MANO90].) Sections 3.2 through 3.6 identify some (but by no means all) interesting issues that involve modifications or extensions to conventional object model concepts to support HAD environments, and describe how they are addressed in FROOM. Many of the model features described in these subsections are not necessarily important only in distributed environments. The same features can be justified by the need for improvements in modularity, reuse, and other considerations. However, HAD system requirements tend 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] and MDM [RICH91], as well as the object models being developed within the Object Management Group (OMG) [OMG91a,b]. FROOM is based on three primitive concepts: object, function, and type. Objects are used to denote application abstractions (such as persons or cars), values (such as strings or integers), components of the system (such as network nodes and databases), and components of the model itself (such as functions and types). Objects play the role of operands or results of operations, called functions in FROOM. A function is a mapping from input objects to output objects. An object is accessible 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 single high-level abstraction. A function call (function application expression) corresponds to a message in other object models, and has the form f(x1, x2, ..., xn)
where f is a function name, and each xi is a constant, variable, or other expression that 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 are defined using more primitive expressions that denote or evaluate to objects. The simplest forms of expressions are literals, variables, and constants. These forms name their result objects directly. For example, 3 evaluates to the immutable integer object 3, while the variable x evaluates to the object it refers to. More complex expressions are built up using aggregate type constructors (such as sets and
13 tuples) and function applications (including predicates, which are functions that return Booleans). The result of a compound expression of this sort is the object returned by the outermost operation. FROOM provides a uniform way of dealing with both objects and values that allows it to deal with value semantics from attached systems in a straightforward way. Each object is characterized by one or more types that describe its behavior. The objects associated with a particular type are referred to as instances of the type. A type determines the set of functions that must be available for application to any of its instances. An instance of a type may also support functions in addition to those required by its type(s). As is usual in object models, the model includes a number of built-in types. These include primitive types such as integers, strings, and Booleans, and aggregate types such as tuples and sets. Simple examples of FROOM type definitions are given below4. type person function name(P: person): string, function children(P: person): {person}, function age(P: person): integer, end person; type ship function 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 to a ship). The definitions also illustrate that functions can have side effects (assign updates a ship object) and can return individual objects (name returns a string, captain returns an officer), tuples (location returns a tuple of latitude and longitude objects representing a position), or sets (children and crew return sets of person objects). Functions have signatures (which specify the name of the function and the types of its input and output argument objects), and implementations or bodies (which implement the semantics of the function). The evaluation of a function body may involve simply returning stored information (as in the name function), or the execution of some procedure. Like its predecessor models, FROOM uses a functional notation. However, as currently defined, FROOM associates functions defined in type definitions, such as those above, with the type of the first argument for dispatching purposes. Separately defined functions, called independent functions, can also be defined. For these functions, dispatching can take place based on multiple arguments (see Section 3.5). FROOM also supports Event-Condition-Action (ECA) rules based on those described 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 part specifies a function call (or set of calls). When the event occurs (is signalled), the rule is fired: i.e., the condition is evaluated, and if the condition is satisfied (the queries return non-empty answers), the action is executed. Rules can be defined to apply either to all objects of one or more types, or to individual objects. Rules, events, conditions, and actions are defined as object types. Various kinds of events are defined, including the beginning and ending of operations, temporal events, and user-defined events, which are detected and signalled by users or external programs (e.g., the departure of an airline flight, or the connection of a node to the network). Events associated with transactions are used in our transaction model (see Section 4). Supporting only functions at an object's interface unifies the concepts of state and behavior, as well as the syntax used in accessing them. It also simplifies the interface, as the same concept is used to represent everything. However, a number of models include additional constructs such as attributes (modeling abstract state) and relationships (modeling mathematical relations among objects). This is usually justified by the frequency with which they are found in systems to be integrated in HAD environments, and the convenience of having built-in concepts to which to map them. Some models also identify special kinds of relationships, e.g., containment, with the operational semantics that operations applied to a containing object should be propagated to objects related to it by containment relationships [FONG91]. FROOM, like a number of other object models intended for database use, includes aggregate values or literals such as sets and tuples as basic types. Such literals are essentially objects that have an identity based on their component members, rather than on an object identifier generated by a creation event. Sets of tuples can be used in these models in defining object algebras (see Section 3.6), since they provide a perfect model for the results of relational-like queries . Objects having such sets of tuples as state can serve to define n-ary relationships without the need for explicitly introducing a new model construct [DAYA89, MANO90]. In order to express the operational semantics associated with the special kinds of relationships mentioned above, FROOM uses rules associated with the sets of tuples representing relationships. Since the rules can be tailored to the requirements of the specific relationship involved (e.g., to trigger the propagation of operations to contained objects), this approach is more general than building in various specialized semantics such as containment. This approach is described in [DAYA87]. Inclusion of constructs such as attributes and relationships in object models will not have a serious impact on interoperability, provided the semantics of such constructs can always be expressed behaviorally. For example, [OMG91b] describes a model in which defining an attribute A is equivalent to defining the operations Get A and Set A, and defining a relationship R is equivalent to defining the operations Add R, 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, must capture the sorts of semantic distinctions represented by constructs such as attributes and operations. For example, an updatable function representing abstract state must be distinguished from a non-updatable function representing a pure operation. Again, a behavioral specification provides a good way of doing this. There is general agreement that these distinctions need to be captured in interface semantics one way or the other. A common behavioral semantics would allow the difference between the approaches taken in various models to be notational rather than 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 that implements the operations. c. it defines an object existing at run-time that acts as a "factory" for creating new objects, and that holds the operation implementations shared by the collection. However, there is an increasing tendency for object models, particularly those intended for distributed systems, to not only cleanly separate the specification of the interface to be provided by an object, role (a), and the implementation of objects providing that interface, roles (b) and (c), but also to generalize the way in which objects are classified into types. In FROOM and other such object models, object types are defined entirely in terms of a set of function (or operation) signatures. Each signature consists of a function name, a set of input argument types, and a set of output argument types. The FROOM person type defined in the last section is an example of such a type definition. Separate specifications can then be used to define the implementations of objects of the specified types. For example, each object could provide its own implementation, as in Emerald [RAJ91]. Alternatively, one or more classes playing roles (b) and (c) could be defined as implementation templates for objects of the type, as in POOL [AMER90]. Provided these object implementations support the interface defined by the type, they can be considered as legitimate instances of the type. This separation of type and implementation allows heterogeneous implementations of objects providing the same capabilities to co-exist within the system, and allows objects, provided they maintain existing interfaces, to add new capabilities, 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 a corresponding distinction between subtyping and inheritance. In models that observe this distinction, subtyping is strictly a relationship between types, and inheritance is strictly a way of composing object implementations (classes) to derive object implementations from those of existing objects. Class-based inheritance can create difficulties in a distributed environment, since it means that an object's implementation is based to a certain extent on the class object. 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 class hierarchies of different systems have been created autonomously, moving a class involves the difficult task determining its position in the class hierarchy of the target system [BENN90]. For these reasons, some systems specifically designed for distributed applications, such as Emerald and ANSA [ARM89], emphasize object autonomy, and do not support inheritance, requiring instead that objects define their own behavior independently of others. Delegation (which is essentially behavior sharing at the level of objects, rather than classes [WEGN90]) is sometimes suggested as a more appropriate mechanism than inheritance in a distributed system [BENN90]. Objects may delegate responsibility for executing non-local behavior to parent objects called prototypes, which themselves are objects that may delegate to one or more parents. The collection of all objects that share (delegate to) the same prototype is in some respects like a class, but there is no language-level distinction between objects and classes. Delegation eliminates the problem of trying to integrate a moved class object into a new inheritance hierarchy. It does not necessarily eliminate the need to send remote messages back to the prototype, unless the prototype is moved as well. This may, however, be done more flexibly than for a class object. FROOM supports object implementations based on both inheritance and delegation, and implementations derived in even more general ways, provided that they satisfy the interface specifications. For example, the view mechanisms mentioned in Section 3.4 can be used to apply functions to objects at lower levels of abstraction, such as class objects, to produce new implementations. This approach is described in [HEIL90]. 3.3 Conformance-Based Typing In a conventional object model, the type that an object implementation is intended to satisfy would be specified along with the implementation itself, creating a fixed relationship between the object and a type (and, possibly, any supertypes of that type in an explicit type hierarchy). However, a number of object models, including Emerald, TEDM, MDM, ANSA, and FROOM, have adopted a more flexible mechanism called conformance (or conformity) [RAJ91] that determines whether an
17 object is of a specified type by comparing the interface provided by the object with the interface specified by the type. Intuitively, an object conforms to a type when its interface provides at least the functions specified in the type definition (i.e., has the behavior required of the object by the behavior given in the type specification). [CANN89] notes that a significant part of the flexibility of untyped object-oriented programming is the potential of using any object that can handle a given set of messages (satisfies an interface) in a context that sends just those messages (requires that interface), independently of how the messages are implemented inside the object. Conformance-based typing allows both the requirements of clients and the capabilities of objects to be expressed abstractly, in terms (respectively) of the required and provided interfaces, without being bound to specific combinations of functions that object implementers have chosen to implement or that are defined in existing type specifications. Moreover, conformance permits these advantages to be obtained while retaining the ability to perform strong type-checking. Since conformance is basically a relationship between interfaces, it can also be used to compare types. An interface (or type) S conforms to a type T if S provides at least the functions of T (S may have more functions), and the signatures of corresponding functions conform5. For example, the type below conforms to the type person described earlier6: type person-with-hobbies function 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 to explicitly declare them, as in C++. However, the conformance relation creates implicit subtype relationships among defined types (and, in fact, induces a lattice on these types). With conformance, any type that supplies the interface required by type T is implicitly a subtype of T, and may be used as such. Thus, conformance allows the introduction of new supertypes into the type lattice without having to modify the definitions of existing types (or the structure of the type lattice). This capability is useful, for example, when a more general type is defined after several more specific types already exist, a situation which frequently occurs in integrating independently-developed systems. The flexibility in defining new types and objects provided by implicit conformance can sometimes lead to "mistaken" type matches [MANO90, RAJ91]. For example, the object: new home H name(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) := 2 end;
created as an instance of type home (defined with the intention of recording information about children's homes): type home function 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 system would allow the unintended use of a home object as a person (or vice-versa). The explicit assignment of objects to particular types, and the explicit declaration of relationships among types, prevents such situations, at the cost of being unable to introduce new types that are related to existing types without explicitly modifying the type lattice. In models based on implicit conformance, "mistaken" type matches can 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 adequately describe the semantics of objects without involving logic-based specification languages and theorem-proving techniques. FROOM and TEDM allow objects to optionally be explicitly assigned to specific types (objects support functions that allow them to be queried for their types). Other models simply use enhanced signatures. For example, the object model currently defined for the OMG's Object Request Broker [OMG91a] includes exceptions raised by an operation, and an indication of whether the operation is expected to respond or not, as distinguishing characteristics in operation signatures. POOL [AMER90] enhances type definitions with identifiers called properties, which can be compared to determine if two objects supporting the same behavior should be considered as having the same type, and FUGUE includes the use of pre- and post-conditions in determining when object functions can be considered equivalent. These considerations suggest the usefulness of further work on type mechanisms in the development of distributed object systems. They also illustrate the need for repository-like components providing access to object metadata, such as the ANSA trader [ARM89], which can be used to assist in matching client requirements with object 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 or object boundary separating the interior of the object from its clients. In class-based models, this generally means that the entire set of instance variables defined in a class is visible to each method defined in the class, and the set of operations defined by a class form a single interface that is visible to all other objects. However, it has become increasingly clear that, in fact, objects often effectively have multiple
19 interfaces. As a result, FROOM, and other recent models, provide facilities to make such interfaces explicit, and to generalize the object interfaces that can be defined. Multiple interfaces are useful because different parts of an object system often have different requirements for their access to objects. For example, class variables in Smalltalk 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 complications both in implementation, and enforcing mutual exclusion on accesses to the class variables. Class inheritance can also be thought of as violating encapsulation by permitting methods defined for new subclasses to access inherited instance variables. C++ friend functions illustrate another specialized access requirement differing from that of an ordinary client. [TOML89] notes that such compromises of encapsulation exist because conventional objects provide only a single encapsulation boundary, defining a single abstract interface, and this is often insufficient. An approach to dealing with this issue in a disciplined way is to explicitly provide objects with multiple interfaces tailored to the distinct requirements of the accessing components, rather than providing various (often implicit) special cases. This allows the creation of more strongly encapsulated objects, which in turn allows new flexibility in how objects may be composed to provide new abstractions. Additional requirements are imposed by the introduction of distribution and concurrency into object models, as required in the support of HAD systems. For example, [WEGN90] distinguishes three distinct types of object interfaces that could be defined. An abstraction boundary specifies the interface between an object and its clients, and the form in which resources provided by an object to its clients may be invoked. A distribution boundary is the boundary of locally accessible names visible from within an object (looking outward, as opposed to the abstraction boundary, which defines visibility looking inward), i.e., the boundary that determines when a reference is local or non-local. A synchronization boundary specifies the unit of concurrency, and defines the boundary at which threads entering an object synchronize with ongoing activities within the object. A database-like view facility can support the definition of new objects (or, more specifically, new interfaces) in terms of existing objects, in some cases through a high-level specification language such as a query language or object algebra (see Section 3.6). FROOM, and other object models associated with database-oriented projects such as FUGUE, explicitly support the construction of new objects and interfaces 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 the distribution boundary described above. Each object can provide one or more interfaces (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 and behavior. The same operation may appear in the interface of more than one aspect of the same object without conflict. Aspects in MDM, like interfaces in the ANSA model, in many respects take over the abstraction role played by objects in other models. 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 are sometimes referred to as classical or messaging object models, since the abstraction is 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 type of a single distinguished object supplied in the call (this is the object to which the message is directed in a language such as Smalltalk, or the first argument object in a subroutine call notation). FROOM supports independent functions, or functions defined for two or more object types, where dispatching may be based on the types of multiple arguments. Such a model is sometimes referred to as a generalized object or generalized function model, other examples being CLOS [STEE90], PDM, OODAPLEX, Iris, FUGUE, and one of the models in [OMG91b]. For example, a finite element analysis 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 object LO representing the loads being applied to the input model, and an option O, and returns the deformed model (e.g., the bridge as it would appear if the loads were applied) resulting from the analysis. In FROOM, this declaration creates a new object of type function , whose name is feanalysis , and which exists independently of other object types. There has been considerable discussion of the merits of object models supporting generalized functions. Models lacking them must resort to explicit multiple dispatching in cases where operations are polymorphic on more than one argument [INGA86]. This involves defining additional operations at the interfaces of objects specifically to support the additional levels of dispatching, which tends to compromise the abstraction provided by the object in order to provide support for what in some sense is an implementation mechanism. It also breaks up what ordinarily might be thought of as single procedural abstractions into different pieces associated with the different object types involved.
21 On the other side, arguments have been advanced that the generalized function model compromises object encapsulation by requiring the generalized operations to have access to the states of all argument objects. These arguments appear to have greater force when applied to object models supporting only one interface per object than to models, such as FROOM, supporting multiple interfaces per object. In such models, it is possible to define objects representing the generalized functions, and argument objects having one interface for ordinary clients, and other interfaces containing any additional operations needed to support generalized functions and multiple dispatching. In this case, the implementation of multiple dispatching can be defined using messages, and yet concealed from ordinary clients. This is an important consideration in a HAD system, in which messages are not just synonyms for function calls, but may involve real communication between distributed objects. The ability to define independent functions allows procedures of arbitrary complexity to be included in the model. This is important for HAD environments where some of the objects in attached systems will be programs or other components having largely procedural semantics. FROOM models such abstractions as objects having an invoke (or apply) function defined at their interface. 3.6 Object Algebra The definition of FROOM includes an object algebra that resembles an extended relational algebra. The concepts used are based largely on those in PDM algebra [MANO86], OOAlgebra [DAYA89] and EQUAL [SHAW89], but also include concepts from object logics, e.g. [MAIE86, KIFE89]. The algebra is not intended for use by either programmers or end users, but as a notation for defining the basic functions to be built into implementations of the object model, and for defining the semantics of expressions in high-level query languages. Such languages provide the means for specifying global queries involving objects in the distributed object space supported by a DOMS. If the objects involved are supported by attached heterogeneous components (DBMSs or other repository managers), the DOMS must map such queries through object algebra expressions into expressions in the local 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 algebras generally (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 of tuples of objects. Such algebras also allow functions or operations defined for individual component objects in these aggregates to be applied, creating new aggregates as results. Like the operations of the relational algebra, the operations of object algebras can be composed to form more complex expressions. These expressions are themselves composite functions that map objects or sets of objects of specified types to other objects. As in PDM and OOAlgebra, but unlike EQUAL, the aggregates resulting from evaluating FROOM algebra functions are
22 immutable, so new object identifiers are generated only when this is explicitly specified. This is consistent with the use of these tuples primarily as transient sets of bindings 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 types of join are supported.
•
The standard set operators union , intersect , difference , over arbitrary sets of objects (they need not be sets of tuples), and unique for duplicates removal. Identity comparison is used in determining when two objects are equal (and thus, different effects are obtained depending on whether the objects are mutable or immutable).
•
append(P,f) which, given a set of tuples P, applies the specified function f defined for objects in one of the columns of P to arguments taken from other columns of P. The result is a new set of tuples formed by appending to P a new column containing the result of the function evaluation. This is a key operation of the algebra, since it allows the invocation of arbitrary object-defined functions within expressions of the algebra, and the incorporation of the results of these functions into the results of these expressions.
•
createobj(P,O) , which given a set of tuples P , returns a new set of tuples in which each tuple of P is concatenated with a new object identifier as a value of column O. Variants of this operation allow creation of typespecific object identifiers, or composite identifiers indicating an existence dependency between a derived object and the base objects from which it was derived (these are used in creating views).
•
Other miscellaneous functions for renaming columns, forming tuples of objects and values, and nesting and unnesting embedded substructures.
Future work on the FROOM algebra will address two difficult issues that are the subject of much current research: first, providing general facilities for creating arbitrary new objects and functions using algebra expressions; second, determining an optimum set of algebra functions for use in query optimization. The first of these involves using the algebra to create both function objects and their associated bodies, and allowing function bodies defined in arbitrary languages, not just the algebra itself, to be manipulated, and combined into new objects. This is a basic mechanism that can be used for providing extensibility in the object model without necessarily requiring that the object algebra itself be computationally complete. The second involves comparing the optimization characteristics of relational-level operations, 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 transactions which access objects that may represent data and functionality in attached systems. To do this, the DOMS must deal with the autonomy and heterogeneity of the attached systems. The problem of transaction management in multidatabase environments has been investigated extensively, and a number of solutions have been proposed in the literature. Various extended transaction models have also been proposed to allow, among other things, compensation and nesting of distributed and multidatabase transactions. The approach we are taking (and which is still under development) is to identify an extended transaction model that captures the capabilities of these (and other) extended transaction models, so as to provide the basis of a programmable transaction management facility that allows the definition and construction of specific extended transaction models corresponding to application requirements. Transactions in a DOMS issue operations on objects that belong in one of the following categories: •
Attached objects that represent data and functionality in local systems that themselves support transactions. This category includes autonomous and heterogeneous database systems, which we refer to as Local Database Systems (LDBSs). There are file systems and programming language systems that also provide built-in transaction support, e.g., Argus [LISK88]. However, the transaction management facilities in these systems are generally similar and in the following discussion we do not distinguish them from LDBSs.
•
Attached objects that represent data and functionality in local systems that provide only basic atomic operations. Objects and systems in this category do not support transactions, i.e., do not provide primitives that allow the composition of complex atomic operations from an arbitrary collection of basic atomic operations. We use the term transactionless systems to refer to systems in this category.
•
Native objects whose state and behavior are supported by the DOMS itself. Objects in this category either implement their own transaction management mechanism, or use the facilities of a DOMS-provided global scheduler for operation synchronization, as in a distributed DBMS. If an object implements its own transaction management, the DOMS may have no access to its local concurrency control information (e.g., local serialization order, 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 in its interface. Many commercial DBMSs satisfy or are in the process of satisfying this requirement. These transaction management operations must also be available at the interfaces of native objects, and of attached objects that represent functionality of LDBSs. Some of these objects may be active, in the sense that they can execute operations concurrently, and can (from the point of view of other objects) initiate actions asynchronously, without having received a message. Due to the presence of local transactions and local operations in a DOMS environment, autonomous LDBSs and associated attached objects can be viewed as active objects in this sense [WEGN90]. The DOMS must support two general classes of transactions. Multi-system transactions are extended transactions that have constituent (flat) transactions that are either executed at different LDBSs, or perform a single atomic operation at an attached transactionless system. Multidatabase transactions are a special case of multi-system transactions in which flat transactions are submitted only to objects supported by LDBSs, or to native objects. In addition to multi-system (global) transactions that are submitted to the DOMS, the architecture allows local transactions to be submitted directly to a single LDBS, and local operations to be invoked directly at individual transactionless local systems. It is assumed that unless attached systems are specifically designed to provide access to local concurrency control information, the DOMS has no information about the behavior or even the existence of local transactions and local operations. In Section 4.1 we describe extended transaction models, identifying the basic components of extended transactions common to many transaction models, and the dependencies (interrelations) between components that vary from one model to another. To allow application designers to specify many extended transaction models and build the required control structures, our transaction model supports explicit specification of these dependencies. Dependencies are specified as FROOM functions, called Dependency Descriptors. Each specification is associated with a corresponding (rule-based) implementation. Dependency descriptors are used to define complex transaction objects that represent extended multi-system transactions. These transactions allow compensation, and hence, produce correct but non-serializable executions. In section 4.2, we show how to use the same mechanism to construct multidatabase transactions in cases where global serializability 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, the object 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 in multidatabase 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 other objects, and hence operations on them can spawn (implicitly nested) transactions on component objects. Finally, the correctness criterion determines the acceptable histories that result from the the execution of concurrent transactions in the model. Serializability is widely used as a correctness criterion in database systems, and there are a number of conflict serializability-based correctness criteria that differ mainly in how they define a conflict [WEIH88, HERL90, BADR87]. However, serializability is too restrictive for many applications, and various alternative correctness criteria and associated 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 used in multidatabase and DOMS environments. The DOM transaction model [BUCH91] allows the definition of complex transactions corresponding to a wide range of these transaction concepts. The basic mechanism for doing this involves the observation that transactions in any of these extended transaction models consist of a set of traditional (flat) transactions, together with a set of transaction dependencies among them. For example, consider an extended transaction T={TT, TD}, where TT={T1,T2,T3,T4} is the set of flat transactions of T and TD is the set of dependencies between them. If we assume that T3 is a contingency transaction for T2, T4 is the compensating transaction of T1 and T1 is vital, 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 T1 commits 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 represent the 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 and commit-abort dependencies represent that T3 is a contingency transaction for T2. Given an extended transaction model, we can effectively describe it by identifying the types of transaction dependencies it allows. Basic transaction dependencies, such as the commit-commit, commit-begin and abort-begin dependencies just described, specify the execution structure of extended transactions. Dependencies in this category are called transaction state dependencies and are conditions on the
26 state of transactions. Given two transactions Ti and Tj, such dependencies are defined by conditions of the following type: Tj c a n begin/prepared-tocommit/abort/commit only if Ti has entered its begin/prepared-tocommit/abort/commit state. For every transaction state dependency there is also a corresponding strong transaction state dependency. Strong transaction state dependencies are conditions of the following type: Tj must begin/prepared-tocommit/abort/commit only if Ti has entered its begin/prepared-tocommit/abort/commit state. Another category of basic transaction dependencies are serialization order dependencies, which are conditions on the relative serialization order of transactions. To deal with the autonomy of attached objects and associated systems, and also the encapsulation of concurrency control and recovery mechanisms in native objects that implement their own transaction management, both local and global transaction serialization order dependencies must be defined. Consider two transactions Ti and Tj that execute concurrently in multiple objects O1, O2, ... Ok (and associated local systems). 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 can precede (succeed) Tj in the local serialization order at Ol. On the other hand, Ti and Tj have a globally-serialized-before (-after) dependency at O1, O2, ..., Ok, if Ti and Tj have locally-serialized-before (-after) dependencies in all objects they execute together. Strong serialization order dependencies can be defined as with transaction state dependencies. A dependency in this category requires that transactions must have the same serialization order in multiple concurrent/active objects O1, O2, ... Ok (and associated local systems). Two transactions Ti and Tj have a serialization-ordercompatibility 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 in Oq. Visibility dependencies specify when a transaction can observe the effects of another transaction. For example, visibility dependencies include basic dependencies that are based on the concepts of cascadelessness [BERN87], strictness [BERN87], and rigorousness [BREI91]. Other possible dependencies include priority dependencies that determine the order in which two transactions should be processed, and temporal dependencies that specify the time at, before, after and/or between a transaction should enter a particular state. An example of such a dependency is, start Ti at 3 pm. While transaction state and temporal dependencies specify the execution structure of extended transactions, visibility and serialization dependencies specify correctness criteria. This collection of basic transaction dependencies is not necessarily complete or optimal. A subset of these transaction state and visibility dependencies has been identified in [CHRY91]. We model transactions as dynamically-created objects [WEGN90]. A simple transaction 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 transactionless system are not considered simple objects. They are specified as extended multisystem transactions). Simple transaction objects support the basic transaction management operations BeginTransaction, EndTransaction (Commit), PreparedToCommit and Rollback (Abort). We model extended multi-system transactions as complex objects. To define complex transaction objects from simple transaction objects (and other complex transaction objects), we use the concept of Dependency Descriptors (DDs). Dependency descriptors are FROOM functions that describe the interrelationships between transaction objects in terms of transaction dependencies. Each DD is represented by a tuple (DS, DI), where DS is a the Dependency Specification and DI is a corresponding Dependency Implementation. DS is a symbolic representation 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 to assure DS (e.g., the body of the function). Although DIs can be programs written in a general purpose programming language, to allow more flexibility and modularity we intend to use ECA rules to implement DSs. ECA rules defined in DIs are triggered by events caused by transactions when they enter a particular state (e.g., a transaction commits), issue read or write operations on objects, priority, and time. The use of DDs is intended to allow application designers to define extended transaction models by using what is effectively a transaction specification language. In addition, specifications of popular extended transaction models could be provided as predefined rule sets, and application designers can combine components of different models and their corresponding control structures to form their 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 be specified and implemented by the following DD: DDcc DScc: DIcc:
cc(T1,T2) ON Commit(T1) & Prepared-to-Commit(T2) DO Commit(T2)
Similarly, the commit-abort (ca) dependency between T2 and T3 (ca(T2,T3)), and the abort-begin (ab) dependency between T3 and T4 (ab(T3,T4)), can be specified as: DDca DDab DSca: ca(T2,T3) DS ab: 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, and the abort-begin dependency between T2 and T4 are similar to DDab above. To avoid defining multiple DDs for the same transaction dependency type, we specify transaction IDs as DD parameters. For instance, we use DDcc(T1,T2) to denote DDcc above, and DDca(T2,T3) to represent DDca.
28
There are two important advantages that result from the separation of specification and 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 provided by 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 extended multidatabase transaction model can be augmented by conjunction (and possibly other constructors such as disjunction, sequence and closure), to form a transaction specification language. For example, the following conjunctions of DSs specify T: DS cc(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 is implemented by an ECA rule that is triggered by a composite event, i.e., the conjunction of the basic events that appear in the DIs of the basic DSs in DScb(T1,T2) & DSab(T2,T4) & DSab(T3,T4). Automatic generation of composite DDs from basic DDs is trivial in most cases. In addition to their use in specifying and constructing extended and multidatabase transactions, DDs can be used for specifying various notions of consistency between related objects. In this role, DDs implement ECA rules that trigger transactions to carry out the appropriate consistency restoration procedures when one of the related objects is updated. 4.2 Multidatabase Transactions In this section we consider a particularly important special case of DOMS transactions, multidatabase transactions, and discuss the DDs required for their specification. A multidatabase transaction G is a multi-system transaction that consists of subtransactions T1, T2, ..., Tk, each of which is submitted as a flat transaction to a different LDBS. Here we assume that LDBSs assure local serializability, and that multidatabase transactions must be atomic (i.e., preserve global serializability and behave as flat transactions). To describe this multidatabase transaction model we first identify the basic transaction dependencies that describe its transaction structure and correctness criterion. The following dependencies specify that a multidatabase transaction G behaves like a flat transaction: G has a strong abort-abort dependency with each of its subtransactions (i.e., G must abort if any subtransaction aborts) and a composite strong commit-commit dependency with all its subtransactions (i.e, all subtransactions must commit if G commits). To assure global serializability, the subtransactions of G have a composite serialization-order-compatibility dependency (i.e., all subtransactions 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 and implementation of DDs for commit-commit and abort-abort dependencies were illustrated earlier. To implement the composite serialization-order-compatibility dependency, the DOMS must assure that the subtransactions of the multidatabase transaction are serialized the same way in all LDBSs. However, the local serialization orders of the subtransactions are neither reported by the local database systems and associated attached objects, nor can they be determined by controlling the submission of the subtransactions or observing their execution order. In particular, while the DOMS can control the execution of the operations of multidatabase transactions, and detect direct conflicts involving multidatabase transactions, the DOMS has no information about local transactions and the indirect conflicts they may cause between multidatabase transactions. Thus, although all local schedules are serializable, the DOMS has no way of determining whether the global schedule is globally serializable [GEOR90,91a]. It can be shown that this problem exists even if the semantics of the operations involved are taken into account [WEIH88]. To assure global serializability in DOM multidatabase environment, we are pursuing the following approaches. The first is useful only when active objects and associated LDBSs use concurrency control mechanisms that allow only rigorous schedules [GEOR90]. Rigorous schedulers and schedules disallow conflicts between uncommitted transactions. It has been shown [BREI91, GEOR90] that the commitment order of the transactions in a rigorous schedule determines their relative serialization order. Thus, if all objects and associated LDBS use rigorous schedulers, the DOMS can enforce global serializability by assuring that the commitment order of each multidatabase transaction is consistent in all objects and LDBSs. In such an environment, global serializability is assured as a side-effect of the 2-Phase Commit protocol supported by the objects involved. The class of rigorous concurrency control mechanisms includes many popular schedulers [BREI91]. To determine the local serialization order of multidatabase transactions in objects and LDBSs that use non-rigorous schedulers, we are pursuing another approach that is based on the concept of a ticket [GEOR91a]. A ticket is a (logical) timestamp. For objects that represent data and functionality of autonomous LDBSs, the value of the ticket is stored as a regular data value in each LDBS. In native objects implementing their own transaction management, the ticket value is part of the accessible object state. Each subtransaction of a multidatabase transaction is required to perform a Take-A-Ticket operation, which consists of reading the value of the ticket and incrementing it through regular data manipulation operations. Since the value of a ticket and all operations on tickets issued at each object or system are subject to local concurrency control, Take-A-Ticket operations force direct conflicts between the subtransactions of a multidatabase transaction at each object and associated local system. Therefore, the ticket values obtained by multidatabase transactions at each object and LDBS determine their local serialization order [GEOR91a]. Only a single ticket value is needed per LDBS (i.e., all objects that represent data of the same LDBS share the same ticket value), and only the subtransactions of multidatabase transactions must take tickets; local transactions are not affected. Furthermore, tickets do 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 the family of ticket-based methods described in [GEOR90]. One of these methods is called the Optimistic Ticket Method (OTM) [GEOR91a]. To assure global serializability OTM requires all subtransactions of each multidatabase transaction to take tickets, compares their ticket values and permits the commitment of multidatabase transactions only when their relative serialization order is the same in all participating LDBSs. OTM requires the LDBSs to guarantee only local serializability. Similar problems exist in assuring global consistency of multidatabase transactions in the presence of transaction and site failures. The basic problems in multidatabase recovery and corresponding solutions that address each of these problems are discussed in [BREI90, WOLS90, GEOR91b]. Multidatabase recovery in our DOMS 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 object management, a prototype DOM component was implemented, together with a testbed consisting of several DOMs, and the LAIs and attached systems required to support a simple office automation service. Specifically, LAIs were developed for the Apple Macintosh Hypercard application, the Sybase relational DBMS, and the ONTOS object DBMS, systems having distinctive characteristics that provided a basis for investigating various distributed object management issues. In one scenario implemented using this testbed, formatted data about persons is stored in Sybase, and image and sound data (persons' photos and voices) in ONTOS. This data is integrated with data maintained in Hypercard to support a Hypercard person stack that acts as a user interface to the complete data. Figure 5.1 shows an example component configuration for this service. Each attached system remains autonomous, in that it is unmodified, and local users of the system can interact with it independently of any network interactions. HyperCard 1
HyperCard 2
HyperCard 3
HyperCard 4
LAI 1 DOM 2
DOM 1
Sybase
Non-DOM, autonomous Sybase Users
DOM 3
DOM 4
LAI 2
LAI 3
Ontos
Non-DOM, autonomous Ontos Users
Figure 5.1. Example Office Automation Network
31
The prototype DOM and Sybase LAI were developed on the Sun SPARCstation2 running the UNIX operating system. The HyperCard LAI was developed on the Macintosh using the System 6 Macintosh operating system. This is being converted to System 7 in order to investigate using its interapplication communication facilities. System management tools with graphics interfaces were developed on the Macintosh using the Macintosh toolbox, and on the Sun platform using 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 is necessarily 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 DOM component acts as a specialized server for managing distributed interactions among attached systems, and provides an object-oriented distributed programming environment for developing the required interfaces to, and mappings between, these systems. The DOM supports native objects, whose implementation is defined by the DOM itself, as well as objects whose implementation is provided by attached 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 object model. In this simplified model, objects are defined as instances of specific types, which define object properties (state) and operations (behavior). Definition of a property implicitly defines get and set operations for the property, which may be overridden if desired. Subtype relationships are explicitly defined between types (rather than being derived by conformance, as described in Section 3). Subtypes can inherit and redefine properties and operations defined in supertypes. Multiple inheritance is supported. An individual object can also define object-specific state and behavior in addition to that defined by its type. The representation of a native object has a header and one or more chunks. The header contains the object's identifier (oid), the oid of its type, and pointers to its chunks. Each object contains a chunk for itself, for its type, and for each of its supertypes in the type lattice. A type chunk contains a value for each property defined for that type. The object's own chunk contains any object-specific properties or operations defined for that object. Due to the possibility of object-specific operations, the DOM uses late binding of property and operation names. Message dispatching first checks the receiving object itself to determine if the operation is implemented locally before checking the type 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 from the receiving object's oid and the operation name directly to the method code if the method 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 DOM provides incremental compilation and linking of operation code so that operations can be added to objects at runtime. DomType defines a property extent that holds the set of the type's instances if (optional) automatic extent maintenance is chosen for the type. Each DOM supports persistence for its local object space by writing and reading its local object space to and from disk. The DOM also supports an implementation of a subset of the FROOM object algebra. The operations of the algebra are defined as operations on type DomSetOfTuple, whose instances are sets of objects of type DomTuple. A query decomposer has also been implemented can that transform algebra expressions expressed using types defined as views to expressions using base types. This is used in transforming global queries to queries over types implemented by attached systems. An SQL-like DOM Query Language (DQL) based on this algebra is under development. The prototype DOMs support object identity in a distributed object space by using oids consisting of a local object identifier - lattice identifier pair. A separate type lattice with a root type of DomObject exists for each DOM. Within a type lattice, the DOM assigns each object a unique local object identifier. Unique lattice identifiers are assigned by a global authority to each new lattice. The availability of the lattice identifier in an oid allows a local DOM to transparently determine when a message must be forwarded to a remote DOM because the object is located there. The current DOM only supports migration of object state for general object types, since, in the current prototype, migration of behavior would involve migrating the type object, and determining its position in the local type lattice. This restriction will be lifted later, when conformance-based types are implemented. Primitive types, such as DomInteger, DomString, DomDate, etc., are defined on all DOMs. These either use a special oid format encoding their values (DomInteger), or have a universal lattice identifier. This allows objects of these types to be moved freely between DOMs, since their behavior is guaranteed to exist on all DOMs. Each DOM also has copies of the types implementing the DOM object model itself (see below). This distributes common object functionality throughout the network. The DOM provides a set of object manipulation routines called the DOM Interface Library (DIL). DOM methods and applications are C programs containing calls to DIL routines. The principal DIL routine is DOMinvoke, which instructs an object to perform one of its operations. An interpreted DOM Programming Language (DPL) has also been developed. Each DOM contains an interpreter (an object of type DomEvaluator) which executes DPL scripts by calling DIL routines. DOMs can send messages containing these scripts to a remote DOM for processing. Types can be defined in a DOM Type Definition Language, whose processor generates the 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 recovery facilities for native objects. These are planned in later development stages, based on the work described in Section 4. Facilities have been built into the prototype to act as the basis for the implementation of transaction and rules mechanisms. For example, objects can have notify requests associated with them. These requests define messages that the object will send under specified circumstances. Operations can also have pre- and post-triggers associated with them. The testbed currently supports a limited form of "distributed commit" protocol for transactions involving the multiple attached systems. This is implemented as part of the behavior of the objects involved. The DOM software itself consists of four layers of object types. Types in the Basic Object Model layer implement the minimal DOM object model for a stand-alone, single-threaded application. Types in the Distributed Object Capabilities layer use these types to support inter-DOM communication. Types in the LAI layer use both lower layers to define the DOM portion of application type mapping. Types in the DOM Applications layer use all three lower levels. These types are defined by users when implementing applications using DOM as a development platform (as opposed to implementing an application as an external program and connecting it to DOM via an LAI). For example, several graphical tools for managing and manipulating a DOM object space have been implemented as DOM applications. These tools provide facilities for browsing the network configuration, monitoring and archiving network traffic, browsing, creating, or modifying types and objects in remote systems, 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 the DOM to access local data and invoke local operations of that application (server functionality), and allows the application to access both objects in the distributed object space and DOM services (client functionality). The basic approach for providing server functionality is to define DOM object types to represent the various aspects of the attached system that need to be accessible to the DOM. These objects are then implemented partially using DOM facilities, and partially using facilities of the attached system. The basic approach for providing client functionality is to provide calls or some other mechanism allowing the attached system to invoke operations on any DOM objects. Some of the many possible variations in LAI design were explored in developing the LAIs for the systems comprising the office automation service illustrated in Figure 5.1. To support this service, the DOM component DOM1 defines an object type OAPerson that serves the same role as a global schema type in a heterogeneous DBMS. The HyperCard LAI, LAI1, can request person data through OAPerson without needing to know where it comes from. Type OAPerson is defined in terms
34 of types SybasePerson and OntosPerson, which respectively represent the Sybase and ONTOS data as DOM types. These types are defined as part of the LAIs for their respective systems, and define how to obtain the appropriate data from their respective databases. The following sections describe some aspects of these LAIs. The details are described in [HORN91]. 5.2.1
Sybase LAI Overview
Creating the LAI for the Sybase relational DBMS involved dealing with general principles of mapping relational DBMSs into the DOM environment, as well as features specific to Sybase. Due to the requirements of the office automation service, only server functionality was implemented in the Sybase LAI (client functionality could have been provided in a straightforward way, using the Sybase Open Server facility). Specific server functions in the Sybase LAI included facilities to 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 of Sybase LAI types could be implemented by directly invoking Sybase library routines. A number of DOM types were defined as part of this LAI to represent Sybase concepts in the DOM object space. For example, the concepts of relation and tuple in Sybase were mapped to DOM concepts of type and object, respectively. Type SybRelation was defined as a subtype of DomType with behavior to create new relations, and to select, insert, delete, and update tuples. This behavior was implemented using Sybase SQL. Instances of this metatype (a type, like DomType , whose instances are types) correspond to relations within Sybase databases. For example, an instance of SybRelation called SybasePerson was created to correspond to a PERSON relation in Sybase. SybasePerson is a type that has instances corresponding to tuples in the PERSON relation. DOM types were also defined for other required concepts, such as databases (type SybDatabase) 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 the DOM property specification and the corresponding Sybase relation attribute. For example, the S y b a s e P e r s o n property with name l a s t N a m e and type DomString is mapped to the PERSON attribute surname with type varchar(20). Tuples in relational databases such as Sybase are identified by (key) values, unlike DOM objects, which are identified by oids. During application processing, instances of type SybasePerson maintain correspondences between their oids and the corresponding Sybase tuple.
35 5.2.2 HyperCard LAI Overview HyperCard is a hypertext, multi-media authoring system [APPL89]. The HyperCard 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. A card's state is represented in part by fields holding string data. A card can also contain references to image and sound resources. Behavior, in the form of scripts written in HyperTalk, HyperCard's programming language, can be associated with specific stacks, cards, fields, or buttons located on cards. Cards that have identical fields, buttons, and images can place those items in a common background. Creating cards from a background allows the new cards to have the characteristics defined by the background. Creating the LAI for the HyperCard application involved dealing with general principles of mapping applications into the DOM environment, as well as features specific to HyperCard. It also involved dealing with a heterogeneous platform and operating system environment. Because HyperCard serves both as a user interface and an independent data repository in the office automation service, both client and server functionality were designed for the HyperCard LAI, although currently only client functionality has been implemented. Specific client functions in the HyperCard LAI included facilities to convert DOM types to card backgrounds and convert DOM objects to cards with specific backgrounds, as well as general facilities to access DOM objects from scripts in HyperTalk, and transfer data between DOM and HyperCard. Server functions included facilities to access HyperCard objects (stacks, cards, buttons, fields, etc.), create and delete such objects, get and set attributes of objects, and convert card backgrounds to DOM types. The basis of the client interface is a set of external commands (XCMDs) allowing HyperTalk scripts to send messages to the DOM (an XCMD is the HyperCard mechanism for calling programs written in other languages). For example, these messages are used in the office automation service to access DOM OAPerson objects providing data for cards in the HyperCard person stack. Because the HyperCard LAI involved creating an interface not only to a specific application (HyperCard), but also to a different platform and operating environment (the Macintosh), LAI facilities were separated into those specific to HyperCard, and those of a generic Macintosh environment gateway providing facilities for interfacing between DOM objects and data structures and operations common to the Macintosh 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 of any LAI in the Macintosh environment. A similar structure can be useful in creating LAIs in other environments. The Macintosh gateway supports facilities for applications to send messages asynchronously to DOM objects, and provides translations between DOM types and standard formats in the Macintosh environment, such as the PICT format for images.
36 As in the case of the Sybase LAI, providing server functionality involved defining a number of DOM types as part of the HyperCard LAI to represent HyperCard concepts in the DOM object space. For example, type HcBackground was defined as a subtype of DomType with behavior to create and delete backgrounds. DOM types were also defined for other required concepts, such as fields (type HcField) and buttons (type HcButton). HyperCard was not designed to act as a server, as was Sybase. Thus, it does not provide an API for use by external programs. As a result, HyperCard server functionality was designed through the use of an XCMD adapted to respond to a user "release" of HyperCard, allowing it to wait for messages sent from DOM, and respond by invoking the corresponding HyperCard script. 6. Conclusion and Future Work In this paper, we have indicated that future information systems will increasingly be driven by requirements for the integration of heterogeneous components, both programs and databases, and the easy reuse of such components, to address new requirements. 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 of object technologies requiring extension in this new environment, and some work being performed at GTE Laboratories to address some of the related technical issues. The next phase of research activity in our project will involve further work on both the object and transaction models, and their closer integration. Work on the object model will involve improvements in certain parts of the type system, enhancements to the view mechanisms, better integration of rules into the type system, refinements to the query algebra, and investigation of additional implementation aspects of the model. Work on the transaction model will involve further investigation of mechanisms for multidatabase transactions and recovery, and their extension to generalized active objects. The next phase of prototype development activity will focus on implementing the transaction model. This will require improving the persistent storage mechanism and object management features of the current DOM prototype, as well as incorporating rules and active objects. To improve the DOM development environment, we plan to continue work on the DOM Programming Language (DPL), and implementing a compiler or translator for it. A number of research groups are pursuing solutions to the many technical issues raised by DOM technology. These activities, together with the efforts of industry groups, will provide a primary means for the coalescing of various technical solutions into 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 work described here. The authors would also like to thank the referees for their very helpful comments on an earlier draft of this paper. 7. References [AMER90] P. America and F. van der Linden, "A Parallel Object-Oriented Language with Inheritance and Subtyping", in N. Meyrowitz, ed., OOPSLA ECOOP '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 Management Limited, Poseidon House, Castle Park, Cambridge, U.K., 1989. [BADR87] B.R. Badrinath and K.Ramamritham, "Semantics-Based Concurrency Control: Beyond Commutativity", In Proc. 3rd Int. Conf. on Data Engineering, Los Angeles, February 1988. [BEER89] C. Beeri, P. A. Bernstein, and N. Goodman, "A Model for Concurrency in 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, "Concurrency Control in a System for Distributed Databases (SDD-1)", ACM Trans. Database Syst. (March 1980), 5(1). [BERN87] P. A. Bernstein, V. Hadzilacos, and N. Goodman, Concurrency Control and Recovery in Database Systems, Reading, Mass.: Addison-Wesley, 1987. [BREI90] Y. Breitbart, A. Silberschatz, and G. Thompson, "Reliable Transaction Management in a Multidatabase System", Proc. .ACM SIGMOD Intl. Conf. on Management 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 Object Systems", in A. Elmagarmid (ed.), Advanced Transaction Models for New Applications, Morgan-Kaufmann, 1992. [CANN89] P. S. Canning, et. al., "Interfaces for Strongly-Typed Object-Oriented Programming", 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 Reasoning about Extended Transactions", Ph.D. thesis, Department of Computer and Information Science, University of Massachusetts, 1991. [DAYA87] U. Dayal, et. al., "Simplifying Complex Objects: Approach to Modelling and Querying Them", in [ZDON89].
The PROBE
[DAYA88] U. Dayal, A. P. Buchmann, and D. R. McCarthy, "Rules are Objects Too: 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 Activities with Triggers and Transactions”, Proc. 1990 ACM SIGMOD Intl. Conf. on Management 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 for Global Concurrency Control in InterBase", Proc. 15th Int. Conf. on Very Large Data Bases, Amsterdam, August 1989. [ELMA90] A. Elmagarmid, Y. Leu, W. Litwin. and M. Rusinkiewicz, "A Multidatabase Transaction Model for Interbase", In Proc. 16h Int. Conf. on Very Large 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 Transaction Processing ion A Distributed Database", ACM Trans. Database Systems (June 1983), 8(2). [GARC87] H. Garcia Molina and K. Salem, “Sagas,” Proc. SIGMOD 87, San Francisco, May 1987.
39 [GEOR90] D. Georgakopoulos. "Transaction Management in Multidatabase Systems"; Ph.D. thesis, Houston, TX: Department of Computer Science, University of Houston, 1990. [GEOR91a] D. Georgakopoulos, M. Rusinkiewicz and A. Sheth, "On Serializability of 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, April 1991. [HEIL88] S. Heiler and S. Zdonik, "Views, Data Abstraction, and Inheritance in the FUGUE Data Model", in [DITT88]. [HEIL90] S. Heiler and S. Zdonik, "Object Views: Extending the Vision", Proc. 6th Intl. Conf. on Data Engineering, Los Angeles, Feb. 1990. [HERL90] M. Herlihy, "Apologizing versus Asking Permission: Optimistic Concurrency Control for Abstract Data Types", ACM Trans.Database Syst. (March 1990), 15(1). [HORN91] M. F. Hornick, J. D. Morrison, and F. Nayeri, "Integrating Heterogeneous, 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 Programming Languages, Proc. 2nd Intl. Workshop, Morgan Kaufmann, San Mateo, 1989. [INGA86] D. H. H. Ingalls, "A Simple Technique for Handling Multiple Polymorphism", 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 Systems Interconnection", ISO/TC97/SC15 N227, August 1979. [KIFE89] M. Kifer and G. Lausen, "F-Logic: A Higher-Order Language for Reasoning 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 Without Serializability", Proc. ACM SIGMOD Intl. Conf. on Management of Data, June 1988.
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 for Database Concurrency Control", ACM Trans. Database Syst. (December 1983), 8(4). [MAIE86] D. Maier, "A Logic for Objects", Workshop on Foundations of Deductive Databases 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 and Object-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-001406-88-165, GTE Laboratories Incorporated, June 30, 1988. [MANO90] F. Manola and A. P. Buchmann, "A Functional/Relational ObjectOriented Model for Distributed Object Management: Preliminary Description", TM0331-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 10 December 1991. [OMG91b] Object Management Group Object Model Task Force, "The OMG Object 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 for Cooperating Intelligent Information Systems", in this issue. [PU88] C. Pu, G. Kaiser, and N. Hutchinson, "Split-Transactions for Open-Ended Activities", 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 Support Multiple, Independent Roles", Proc. 1991 ACM SIGMOD Intl. Conf. on Management of Data, ACM, New York, 1991.. [RUSI91] M. Rusinkiewicz, A. Sheth, and G. Karabatis, "Specifying Interdatabase Dependencies in a Multidatabase Environment", Computer, 24(12), December 1991. [SCHI89] J. J. Shilling and P. F. Sweeney, "Three Steps to Views: Extending the Object-Oriented Paradigm", in N. Meyrowitz, ed., OOPSLA '89 Conference Proceedings, 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.), Digital Press, 1990. [TOML89] C. Tomlinson and M. Scheevel, "Concurrent Object-Oriented Programming Languages", in [KIM89] [WEGN90] P. Wegner, "Concepts and Paradigms of Object-Oriented Programming", OOPS Messenger, 1(1), ACM, August 1990. [WEIH88] W. Weihl, "Commutativity-Based Concurrency Control for Abstract Data Types", IEEE Trans. Comp. (December 1988), 37(12). [WILL91] G. I. Williamson and M. Azmoodeh, "The Application of Information Modelling in the Telecommunications Management Network (TMN)", Proc. Telecommunications Information Networking Architecture Workshop (TINA91), March 1991. [WOLS90] A. Wollski and J. Veijalainen, "2PC Agent Method: Achieving Serializability in Presence of Failures in a Heteroneous Multidatabases", Proc. PARBASE-90, February 1990. [ZDON89] S. Zdonik, and D. Maier (eds.), Readings in Object-Oriented Database Systems, Morgan Kaufmann, 1989.
