Databases in Object Management Systems

1 THE OMG REFERENCE MODEL (Feb 16, 1990)

[The following is a view of the OMG reference model as interpreted by members of the OMG OODB task force. This draft was prepared by Mary Loomis, Kevin Wentzel, and myself.]

Here is another architecture for the OMG to consider in developing its reference model. It draws heavily from OMG document 90.1.6 from Texas Instruments.

The following diagram depicts the major modules of the architecture. They are connected by an object bus. For multiple vendors' products to be able to share responsibilities in this architecture, they must agree on the protocol(s) to be used on this bus.

The diagram depicts one node in a multi-node configuration. The Remote Bus is in another node. A Foreign Bus represents an environment which does not follow the O-O protocol, requiring a protocol adapter.

A brief description of the functionality of each module follows the diagram.

------------- # |Application| B ------------- U | S ........... --------- # : Request :--|Request|--# : Adapter : |Manager| # ........... --------- # ------ #--| UI | --------------- # ------ |Location/Name|--# | Broker | # --------------- # ------------ #--|Type/Class| ------------- # |Manager | |Transaction|--# ------------ |Manager | # ------------- # ------------------------- # |Transient Environment | # |......... -------------| #--|:methods: |system code|| -------- # |......... -------------| |File |--# ------------------------- |System| # -------- # ------------------------- # |Persistent Environment | # |......... -------------| #--|:methods: |system code|| ---------------- # |......... -------------| |Security/ |--# ------------------------- |Access Control| # ---------------- # --------- #--|Version| ----------- # |Manager| |Query |--# --------- |Processor| # ----------- # --------- # #--|Bus |--#Foreign -------------- # |Adapter| #Bus |Data Adapter|--# --------- # |(Translator)| # -------------- # --------- # #--|Network|--#Remote # |Manager| #Bus # --------- # #

The Request Manager module provides the programming interface to the environment for applications. It orchestrates the sequences of events involved in servicing requests. It invokes the Location/Name Broker, Type/Class Manager, File System, etc. as needed. It may also be involved in determining the appropriate communication mode for a particular request (e.g., general message handling vs. dedicated session).

Object-oriented applications interface directly with the Request Manager. Conventional applications use a Request Adapter, which makes their requests appear to be object-oriented. A Request Adapter functions like a Wrapper for these non-object-oriented applications.

The User Interface module provides the display capabilities of the environment. It typically supports multimedia data types (graphics, audio, video, and so forth) and supports alternative views of hierarchies, tables, graphics, menus, and other complex objects. It provides window management, supports icons, and is the principal mode of interaction with the system for end-users.

The Location/Name Broker module provides a directory and addressing mechanism for the rest of the modules. It helps determine where a request is to be executed, which might be based on the identities of one or more operands, the request itself, resource availability, and other factors in the environment. For localized objects, this module can map an object's identifier to the object's storage location. It also has responsibility for keeping object identifiers unique.

The Type/Class Manager module plays a role similar to data dictionaries in conventional database environments. This module knows the semantic relationships between classes and keeps track of object types. The module provides the schema manager functionality expected in database environments in order to define, install, and maintain type and classes.

The Transaction Manager saves, retrieves and sends messages to other modules on the system. It may start, commit, or abort transactions, and provides the coordinating role for the actions that comprise a transaction. It is responsible for ensuring that the actions of a transaction are serializable, as expected in database systems. Also supported are long transactions, which may span hours or days and must be treated differently than short conventional database transactions. It is essential for cooperative environments where multiple applications must be able to interact, seeing each other's incomplete results in consistent ways. The Transaction Manager must provide a locking mechanism, a way to keep track of locks for long periods of time, and recovery mechanisms to handle network and processor failures.

The Transient Environment module represents the run-time program space of applications. This space is typically managed by the compiler or interpreter of the language used to specify the application, and by the operating system. If an object-oriented programming language was used, then the transient environment may include methods execution.

The Persistent Environment module represents the database space, which may be shared by applications. This module provides non-volatile storage of objects, with controls for concurrent access to that store. It supports backup and recovery mechanisms, as well as low-level support for locking and access authorization. Depending on the implementation of the persistent environment, methods may be executed within the database.

The File System module provides input and output services to secondary storage devices. It treats data as files of bits, with no knowledge of their semantics. There may be some access authorization or fundamental format checking performed by this module.

The Security/Access Control module provides for user authentication and access authorization for objects in the environment.

The Version Manager module keeps track of versions (object histories), configurations (the parts of an object), and transformations (dependencies among objects). It maintains status information about versions and can enforce constraints about transitions between version states.

The Query Processor module operates on transient and persistent objects. In order to frame queries, it must communicate with the Type/Class Manager to find the data types of the target objects, to determine object extent (part-of, refers-to), and to disambiguate language constructs that it may find. It also optimizes queries, semantically restricting the search space based on constraints associated with types. The Query Processor may also manage queries spanning multiple nodes.

The Bus Adapter module is a protocol adapter which connects the object system with the non-object environment.

The Network Manager provides communication services to other peer nodes.

The Data Adapter module maps objects between their in-memory computational forms and portable external representations appropriate for long-term storage and transmission. The module is used to allow objects defined and implemented in one language environment to be accessed and manipulated in another language environment. When an object is moved between environments, its semantics must remain the same.

There are several open questions raised by this architecture, including:

• Are these the right modules?
• What is the required functionality of each module?
• What is the desirable (but not required) functionality of each module?
• Are there multiple layers for the object bus?
• What mode of communications should be used on the object bus? Two possibilities are via the protocol of the location broker, or via direct communication between particular modules. A given product might have components that communicate directly without using the bus. Should OMG specify the bus protocol?
• Can this model be successfully integrated into the other OMG reference model work?

2 ORB AND OODBMS (Aug 29, 1990)

One of the questions that the OMG Database SIG will address is how an object-oriented DBMS fits into a general object system architecture. Here's a proposed sketch of the relationship between an OODBMS and the ORB (Object Request Broker) within the reference model of the Object Management Architecture (OMA). A lot of stuff needs to be filled in.

We also need to track how this relates to the currently evolving definition of the ORB itself.

The overall task is to map a client's request into a method which will perform the requested service. The ORB (a separate component from the DBMS) plays a variable role in this process. In general, we can describe its mission as routing a request to some target object, which might not be any of the objects mentioned in the request. ORB-like services might be provided by the separate ORB component or by other components.

The interesting variables in this scenario:

• Who provides ORB services.
• The nature of the request.
• The nature of the target object.
• The ORB's decision paradigm.

2.1 Who Provides ORB Services?

ORB-like services may be provided by components other than the ORB itself, such as a DBMS. All of the following scenarios might be supported:

• The client directs all requests to the ORB, which will in turn route some requests back to a local DBMS.
• The client separately directs requests to the ORB or to a local DBMS.
• Requests directed by the client to a local DBMS might be totally processed within the DBMS, or may in turn cause requests to be directed to the ORB.

2.2 The Nature of the Request

The client's request might be complex, e.g., a query, or a composite expression in which operands are represented by other requests. Or it might be a simple request, referring to an operation and some operands. I assume that the ORB does not handle complex requests, but depends on other components such as a DBMS to reduce them to simple requests. This will be addressed in a later section.

The operation and operands might be referenced by handles (values serving as globally unique identifiers) or by other names.

The operation involved might be generic, i.e., there are several candidate methods for executing the request, or "direct" (only one corresponding method).

2.3 Target Objects

There are various sorts of objects to which the ORB component might route a request.

There might be a "local ORB" at each node. If an ORB determines that a request needs to be handled at a remote node, the request might be routed to the local ORB at that node for further processing.

An application object, incorporating one or more methods. The application may contain the logic for ultimately choosing the method.

Some other system component, such as a DBMS. After an ORB determines that the request is to be handled by a DBMS, it routes the request to the DBMS for further processing.

A user object (e.g., a document or a spreadsheet), causing the appropriate method to be chosen within that object.

(Other possible target objects?)

2.4 ORB Decision Paradigms

I will just sketch a few sample possibilities here. I'd like to see the SIG work together in identifying the range of reasonable paradigms. We can probably rank them on a time line as to which are the most feasible in the near term and which need to wait for enabling technology.

In all my examples here, more detail needs to be worked out for the decision algorithms, particularly when the target object is not any of the objects referenced in the request.

If the ORB can determine that routing of a request is to be based on the identity of one operand, then the ORB invokes a "name broker" to determine the target node. If the target node is local (where the ORB resides), the request might be routed to the operand object itself, or to an application object or other component such as a DBMS. If the target node is remote, the request might be routed to the local ORB at that node for further processing. The decision to route the request to an application object requires the ORB to determine the type of the operand object in order to choose the application.

Requests involving certain operations might be routed directly to certain application or system objects regardless of the operand objects.

In the extreme, the routing decision might eventually depend on:

• The requested operation.
• The types and/or locations of one or more operands.
• Other "environmental" factors, such as the location or identity of the client, time of day, etc.

For example, various operations relating to academic matters for students may be routed to one application object, while another set of operations relating to financial affairs of students may be routed to a different application object.

The decision process may involve a complex interaction with other components. Binding a generic request requires knowledge of the type system and inheritance mechanisms, and could result in bindings to methods at different nodes or in different applications.

There's a lot more to be done here. It would be useful if we could organize these into a rational sequence of increasingly sophisticated capabilities, and spell out the interactions between ORB and other components.

One consideration is that an OODBMS itself presumably has mechanisms for dealing with type systems and inheritance, and should get involved in the binding process. The ORB may simply hand off a generic request to a DBMS for further resolution, or there might be more complex interaction.

2.5 Queries, Distribution, Federated Databases

There are situations in which the ORB appears to be both above and below a DBMS.

It seems reasonable to model a query as a request, routed by an ORB to a query processor object, e.g., a DBMS. The query may have to be decomposed into sub-queries to be handled by other databases in a federation of heterogeneous autonomous databases (or other data sources). The query decomposition requires DBMS capabilities such as schema mappings and query plan optimization.

2.6 Candidate Example

2.7 Conclusion

2.8 Postscript

The following topics should be considered for the SIG's work plan:

• How OODB fits into the OMG reference model.
• The role database might play in converging programming language object models.
• Utilization of database by OMG services.
• Query languages and interfaces.

3 THE RELATIONSHIP BETWEEN OODBMS AND ORB IN OMG (Oct14, 1990)

3.1 Introduction

This is a preliminary draft of a working paper of the OMG DB SIG. It is a somewhat modified version of the e-mail I circulated in August.

The larger question concerns how database fits into the OMG architecture, but it essentially boils down to the relationship between OODBMS and ORB. This draft mainly describes the situation and raises some questions. In fact, it turns out to consist mostly of speculations about ORB. The questions and issues will have to be resolved jointly with the ORB task force.

3.2 ORB Functionality

3.3 OODBMS Functionality

A minimal OODBMS is a passive repository of structured object data which is exported to programming-language spaces for method execution.

A full-function OODBMS provides active support of abstract object interfaces. It manages types, classes and methods, including the execution of methods.

(In the absence of a full-function OODBMS, we might explore the question of how objects can be shared among tools written in different OO languages.)

Some of the capabilities of a full-function OODBMS relevant to this discussion include:

• Encapsulation (level of abstraction).
• Type/class definition.
• Checking inheritance consistency.
• Object creation/destruction.
• Add/remove objects in types/classes.
• Name management: oid's, external names, synonyms, homonyms.
• Evaluate operand expressions (composed operations/messages).
• Bind requests to methods. (Operator aliases, operand types/classes, early/late binding, ...)
• Execute methods.
• Return results.
• Query.
• Distribution.
• Export/import.

3.4 The Mission

The overall task is to map a client's request into a method which will perform the requested service. The ORB (a separate component from the OODBMS) plays a variable role in this process. In general, we can describe its mission as routing a request to some target object, which might not be any of the objects mentioned in the request. ORB-like services might be provided by the separate ORB component or by other components.

The interesting variables in this scenario:

• Who provides ORB services.
• The nature of the request.
• The nature of the target object.
• The ORB's decision paradigm.

3.5 Who Provides Orb Services?

----- ---- ----- <---- | | | | | | | v | v | v | | | | | | | | | | | |-------->| ORB |-------->| |----- | | | | | | | | ---------- | | | | | ^ | | | | | | | | | | v | | | | | ---------- | | | | | | | | | REQUESTOR |-------->| DBMS |-------->| methods | | | | | | | | | ---------- | | | | | ^ | | | | | | | | | | v | | | | | ---------- | | | | | | | | | |-------->| OTHERS?|-------->| |----- | | | | | | | ------------- ---------- ----------- | | ^ | ^ | | | | | | ----- ----- <----

ORB-like services may be provided by components other than the ORB itself, such as an OODBMS. All of the following scenarios might be supported:

• The client directs all requests to the ORB, which will in turn route some requests back to a local OODBMS.
• The client separately directs requests to the ORB or to a local OODBMS.
• Requests directed by the client to a local OODBMS might be totally processed within the OOBDBMS, or may in turn cause requests to be directed to the ORB. For example, the OODBMS might directly execute methods.

Requests not being routed via the ORB are sometimes thought of as passing through a channel opened by a request to the ORB. Question: is that always the case?

Question: does a user necessarily know which requests are going to the ORB and which aren't? Or is there some facility in his interface which figures this out?

Question: are requests not going to the ORB governed by the OMG architecture? Are they constrained to conform to ORB behavior? Is the OMG architecting object systems, or is it only concerned with traffic via the ORB?

For example: does the OMG architecture apply to the case of a user interacting with an OODBMS in a conventional way, with no ORB component involved?

Question: what are the criteria which determine whether a request goes via the ORB? Some possibilities:

• "Grain size" of the target, e.g., data object vs. subsystem or application.
• Whether the request is to a local or remote site.
• Whether the request is inter- or intra-component.
• Whether a channel has been opened for direct communication.

3.6 The Nature Of The Request

The request may be in various combinations of the following forms:

• A direct request object with one (significant) operand object.
• Zero or n>.1 significant operands.
• Request or operands as non-unique names. Aliases?
• Generic request (not direct), requiring a binding choice among multiple candidate methods.
• Query or composite request.

3.7 Target Objects

There are various sorts of objects to which the ORB component might route a request:

• A specific method.
• An application object, incorporating one or more methods. The application may contain the logic for ultimately choosing the method.
• Some other system component, such as a DBMS. After an ORB determines that the request is to be handled by a DBMS, it routes the request to the DBMS for further processing.
• A "local ORB" at another node, or some other sort of node manager. If an ORB determines that a request needs to be handled at a remote node, the request might be routed to the local ORB at that node for further processing.
• A user object (e.g., a document or a spreadsheet), causing the appropriate method to be chosen within that object.

3.8 Decision Paradigms

The choice of target might be governed by any combination of:

• Requested operation.
• Operands (based on type, location, or other attributes).
• Request context (user, location, machine, workloads, ...).

The total problem space we are dealing with is approximately the cross product of the various request forms, routing targets, and decision paradigms.

For example...

If the ORB can determine that routing of a request is to be based on the identity of one operand, then the ORB invokes a "name broker" to determine the target node. If the target node is local (where the ORB resides), the request might be routed to the operand object itself, or to an application object or other component such as a DBMS. If the target node is remote, the request might be routed to the local ORB at that node for further processing. The decision to route the request to an application object requires the ORB to determine the type of the operand object in order to choose the application. The object may have multiple types, and they might not be encoded in the object identifier.

Requests involving certain operations might be routed directly to certain application or system objects regardless of the operand objects. A database query might be one such request. A request to invoke an editor or spreadsheet processor (with or without specifying operands) might be another.

The decision process may involve a complex interaction with other components. Binding a generic request requires knowledge of the type system and inheritance mechanisms, and could result in bindings to methods at different nodes or in different applications.

There's a lot more to be done here. It would be useful if we could organize these into a rational sequence of increasingly sophisticated capabilities, and spell out the interactions between ORB and other components.

One consideration is that an OODBMS itself presumably has mechanisms for dealing with type systems and inheritance, and should get involved in the binding process. The ORB may simply hand off a generic request to a DBMS for further resolution, or there might be more complex interaction.

3.9 Complex Control Flows

There are situations in which the ORB appears to be both above and below a DBMS.

It seems reasonable to model a query as a request, routed by an ORB to a query processor object, e.g., a DBMS. The query may have to be decomposed into sub-queries to be handled by other databases in a federation of heterogeneous autonomous databases (or other data sources). The query decomposition requires DBMS capabilities such as schema mappings and query plan optimization.

Deciding where to route the sub-queries, and transmitting them to those other data sources, requires facilities much like the ORB. It would be redundant, and probably inconsistent, for the distributed DBMS to provide such facilities apart from the ORB. Some coordination would be appropriate here.

We might also try to account for the treatment of objects at different levels of abstraction. A user request involving a student object may eventually cascade into a lower-level request dealing with a storage manager's page object. This may involve multiple transits through an ORB.

(Which raises an interesting related question. All these requests might go through the same ORB, yet the storage manager's objects are supposed to be hidden from the end user. Does the ORB get involved in enforcing encapsulation?)

Another question concerns distributed database. This is yet another area in which every component might think it is the center of the universe. Distributed databases could be managed by ORB facilities above the DBMS, by the DBMS itself, or by a storage manager below the DBMS.

It may sometimes be appropriate to think of the ORB as receiving a message and routing it to the ultimate method, but in general this is a grossly oversimplified scenario. The general case involves a complex control flow, iterating several times through one or more ORB's as well as other components, with complex decision algorithms involved at each stage, and cascading through multiple levels of requests and methods. It would be useful to have such a flow architected. In the process, we might identify how many layers of client/server interfaces might be involved.

3.10 Candidate Example

We might build some interesting examples and scenarios around a "Register" request. Just for starters, this might be interpreted as a request to register a new user to a system, to register a new application in a system, to register a person as a voter, to register a patient in a hospital, to register a student in a course, to register a car in a state, and probably others. Lots of details can be varied to illustrate various things as needed. Future drafts of this working paper will include such examples.