The currently defined Common Object Request Broker Architecture
(CORBA) services provide capabilities similar or equivalent to
the functions that make up a database management system (DBMS).
Notionally, a DBMS could be considered an implementation of the
Query service that encapsulates, as private methods, the capabilities
of the Naming, Transaction, Concurrency, Persistence, Externalization,
and Collection services. However, while a DBMS can be considered
an implementation of these services, this does not guarantee that
components implementing these services can be combined to form
an effective DBMS. To be an effective DBMS, a collection of components
must meet users expectations of functionality, performance, availability,
data integrity, and access control. In fact, a close look at the
list of services quickly identifies two vital but missing components,
a coordinator to bind the components together into a system and
a schema that describes the data being managed.
The need for a coordinator has been recognized previously. For
example, Orfali [Orfali, 1997] notes the
need for a "Component Coordinator" to form a working
DBMS out of the collection of CORBA service implementations. The
coordinator is responsible for assuring that the actions necessary
to process a query against a collection of objects are performed
in the proper sequence. It contributes to meeting expectations
of functionality and data integrity.
The CORBA Interface Repository is a starting point for building
database schema. It provides access to the interface definitions
of object types or classes. However, it does not contain information
on the relationships among object types or properties associated
with the relationships. Using the Interface Repository and the
Relationship and Property services, it might be possible to build
a database schema service. However, until an interface is standardized
for such a service, other services such as the Query service can't
use it in an interchangeable way.
Each of the user expectations of a DBMS, functionality, performance,
availability, data integrity, and access control, affect the required
capabilities of the coordinator and the schema. This paper explores
the security issues of data integrity and access control and their
impact on the coordinator and the schema.
A DBMS must guarantee "correct" results when operations
are performed concurrently. In a traditional DBMS this is not
a problem because the only access path to data is through the
DBMS. However, in a distributed object system, any object registered
with the Object Request Broker (ORB) may be accessed directly.
While the Concurrency and Transaction services can provide locking
and two phase commit for access to objects, these services do
not guarantee two phase locking nor do they guarantee that access
to a given object must use them. It is the coordinator's job to
ensure that accesses use the Concurrency and Transaction services
in a manner that guarantees correct concurrent execution. However,
the coordinator alone cannot prevent direct access to an object
through the ORB. Hence the potential exists for accesses that
use the Transaction and Concurrency services to occur concurrently
with other accesses that do not.
One approach to preventing direct access to objects is to use
the policy domain concept introduced in the CORBA Security service
(CORBASec). To determine which security policies apply to an object,
CORBASec requires that objects be a member of a security policy
domain. The security policies associated with a security policy
domain apply to all objects that are members of the domain. The
ORB is responsible for determining that a requested method invocation
meets the conditions of the applicable security policies before
delivering the request to the object. The security policy domain
could be extended to include a data integrity policy. The data
integrity policy would require appropriate use of the Concurrency
and Transaction services. The ORB then becomes responsible for
checking conformance to the integrity policy as well as other
security policies before passing a request to an object. While
this approach is a straight forward extension of an existing mechanism,
it adds an additional burden to the ORB infrastructure.
A second approach to this problem builds on the concept of delegation
in CORBASec. CORBASec allows traced delegation of principal credentials
for access control checks. With traced delegation, the invoked
object receives an ordered list of credentials, one per object
on the path between the initial operation invocation and the immediate
target object. This concept of traced delegation could be extended
to provide not just principal credentials but the object type
of and operation invoked on each object between the initial invoker
and the immediate target object. Using this extension, the immediate
target object could verify that the request arrived via a "valid"
path that included correct use of the Transaction and Concurrency
services. Each individual object would then be responsible for
assuring that it only processed requests that produce correct
concurrent behavior. Objects would not have to implement path
checking. The coordinator could provide an interface that objects
used to determine if a particular request path was valid, centralizing
integrity policy decision making while distributing integrity
policy enforcement. Instead of burdening the ORB, data integrity
responsibility is moved back to the data management components.
Previously it was noted that the coordinator must assure that
the Transaction and Concurrency services are used in a way that
guarantees correct concurrent execution. This will be significantly
more difficult in a distributed object system than it is in a
monolithic relational DBMS. A relational DBMS that supports the
Structured Query Language (SQL) performs only three operations
on data, SELECT, INSERT,
and UPDATE. Each of these
operations has well defined semantics with respect to the type
of lock needed to perform the operation. SELECT
requires a read lock. INSERT,
and UPDATE require write
locks. An object oriented DBMS that supports the Object Data Management
Group's (ODMG) Object Query Language (OQL) must handle the invocation
of arbitrary object class-specific operations. To do this, the
coordinator must be able to determine the semantics of the operations,
read or write, to properly use the Concurrency service. The database
schema is the appropriate place to store information about the
semantics of object class-specific operations. Hence, the schema
will be more complex and extensive than the schema of a modern
relational DBMS.
Authorization for access control in an object-oriented DBMS is
very different from authorization in a relational DBMS. In a relational
DBMS, users are granted access to collections of data, tables,
or specific columns of tables, attributes. From an SQL query it
is generally easy to determine what authorizations are necessary
to perform the query. All of the tables accessed are explicitly
listed in from clause of the query and all attributes accessed
are explicitly listed in the select list and the where clause
of the query. In an object-oriented database built from the CORBA
services users are authorized to use operations on objects. To
successfully authorize the use of an operation, it is necessary
to authorize the use of all operations that the target operation
may use to perform its function. In addition to operation semantics
for locking, the database schema must contain information for
each object method that identifies the other methods and object
classes used by the target method during its execution. Failure
to correctly authorize operation use may be more serious than
failure to authorize access to the correct data. If data authorizations
are incorrect, the results of queries may be incomplete, however,
if operation authorizations are incorrect, the query may not be
able to execute at all.
The current Domain Access Policy specified in CORBASec may not
be adequate for data management. In an object oriented DBMS, it
may be necessary to grant or deny access to an object method based
on the path associated with the invocation. That is, it may acceptable
for a user to perform operation X() on object A if operation X()
is invoked by operation Y() of object B, but not acceptable if
operation X() on object A was invoked in some other manner. For
example, it may be acceptable for a student taking a course to
access the test scores of other students in the class when using
a method on a collection object that aggregates the scores and
reports only the average. However, the student should not be allowed
to access other students' scores directly. The current Domain
Access Policy does not provide a means to specify such access
control requirements. However, using the extension to traced delegation
described earlier for data integrity, the Domain Access Policy
could be extended to handle these authorizations.
The CORBA Services appear to be a good starting point for building
component-based DBMSs. However, some additional services, such
as a metadata or schema service, will be needed and some existing
services will need to be enhanced. The fully encapsulated nature
of CORBA distributed objects places significant requirements on
the database schema that do not exist in relational databases
and that may be difficult to satisfy.
Despite these difficulties, there are benefits to using components
to manage data. With interchangeable components, system developers
are free to choose those component implementations that best fit
their needs. It is possible, for instance, that several different
Transaction service implementations will be available at different
costs and supporting different overall capabilities. One implementation
may be fairly expensive but support an unlimited number of simultaneous
transactions. Another implementation might support a limited number
of simultaneous transactions but cost significantly less. Similarly,
some system designers may not need the power of a full DBMS. Some
systems may need to perform correct concurrent operations on non-persistent
objects. Cost effective custom data management services could
be developed for specialized markets by using standard services
and a custom coordinator. System developers need only pay for
the data management services they really need.
Cattell, R. G. G, 1991, Object Data Management: Object-Oriented
and Extended Relational Database Systems, Addison-Wesley,
Reading, MA.
Cattell, R. G. G. and D. K. Barry, 1997, The Object Database
Standard: ODMG 2.0, Morgan Kaufman, San Francisco, CA.
Melton, J. and A. R. Simon, 1993, Understanding the New SQL:
A Complete Guide, Morgan Kaufman, San Francisco, CA.
Object Management Group, July 1997, CORBAservices: Common Object
Services Specification, Framingham, MA.
Orfali, R., D. Harkey, and J. Edwards, 1997,
Instant CORBA, John Wiley & Sons, New York, NY.
Session, R., 1996, Object Persistence: Beyond Object-Oriented Databases, Prentice Hall, Upper Saddle River, NJ.