OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide
In the sample application, the objects’ state information is practically identical to the
objects themselves, since the latter seem not to exist at all except as the information
stored in the backing databases. However, this is only partly true. The sample_object
object is indeed a dummy and exists only as a pretext for showing how ACLs on objects
are set up and manipulated. The server management object (server_mgmt), however, is
different: it really has a purpose, although it is an abstraction (that is, access to an
interface). It is used whenever a client attempts to execute a remote management
operation on the server. In the sample application this happens when the client is
invoked with the ‘‘kill’’ option.
3.4.3.4 Why Three Databases?
You might think that only one database would be required to hold the object state
information described above. Why, then, are three backing store databases employed in
the sample application? The answer to this question has two parts.
First: It is true that only one database is needed to hold the object state information itself.
The need for a second database arises from the necessity of organizing the object
information in more than one way, so that it can be retrieved both by name and by object
UUID. The object information is stored directly in a database indexed by object UUIDs,
and that is how it must be retrieved. However, application users will specify resources
by names, not UUIDs. In order to make this work, the application stores its objects’
UUIDs in a separate database indexed by their names. Thus any object’s information
can be retrieved, if the object’s name is known, by means of a two-step process involving
(first) looking up an object UUID from the name-indexed database, and (second) looking
up the object information from the object UUID-indexed database.
Secondly: There is a third database to hold only the objects’ ACLs. Theoretically
speaking, there is no reason why the ACLs couldn’t be held with the rest of the objects’
information, in the object UUID-indexed database. However, the application’s ACLs
must be accessible to the DCE ACL library routines, and these routines expect a
database, indexed by ACL UUIDs, containing only ACLs.
This allows us, for example, to call a DCE routine such as dce_acl_is_client_-
authorized( ) (see the sample_mgmt_auth( ) callback routine in sample_server.c),
passing the ACL manager type UUID and the ACL UUID, and get back an answer to
some query about permissions—the library routine is able to go into the database and
access and read the ACL; we don’t have to bother with that. It also allows the rdacl
implementations in the ACL library to do the same thing, since they have a full ACL
binding (which includes a handle to the database in which the ACL is stored).
3.4.3.5 Object Name Resolution Routine
Our application’s name-to-ACL UUID resolution routine uses the following algorithm:
1. Take the object name that has been passed to it and use it to look up the UUID that
identifies the object itself (in the name-indexed database).
3− 26 Tandem Computers Incorporated 124246