Access Control Policies for an Object Oriented Database, Including Access Control Lists Which Span Across Object Boundaries

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

Application Ser. No. 07/352,074 filed May 15, 1989 in the name of R. J. Archon et al for "An Initial Program Load (IPL) Base On An Object Abstraction For A Data Processing System", abandoned in favor of continuation application Ser. No. 07/806,815, filed Dec. 6, 1991, which in turn was abandoned in favor of continuation application Ser. No. 02/960,180, filed Oct. 9, 1992, hereby incorporated by reference.

Application Ser. No. 07/352,571 filed May 15, 1989 in the name of R. A. Fabbio for "An Open System Management Architecture For A Data Processing System", now abandoned in favor of continuation application Ser. No. 07/878,615, filed Apr. 20, 1992, hereby incorporated by reference.

Application Ser. No. 07/;352,530 filed May 15, 1989 in the name of R. A. Fabbio et al for "An Object Database-Driven Interactive Shell For A Data Processing System", hereby incorporated by reference.

1. Field of the Invention

This invention relates to object oriented databases in a data processing system, and more particularly to the use of access control policies for the purposes of granting and revoking privileges to the objects.

2. Description of the Related Art

In a relational database, data is viewed as rows and columns, where a row represents a record, in tables. In order to retrieve records that represent the spanning of multiple tables, relational operators, such as a join operation, are utilized. Although relational operators are used within applications or by users through a query language, these relational operations are not incorporated within the data such that the relational database manager can automatically intuit such relationships. In order to retrieve a record from the database, the user must have read permission for that record. In order to change the data in the record, the user must retrieve (select and fetch) the data into memory, update the record in memory, and then write the updated record to the database. The user must have permission to write the record before the database manager allows the previous data to be overwritten in the database. Moreover, in order to update the record in memory, the user must be cognizant of the column's attributes, such as whether that column contains integers, characters, strings etc.

In an object oriented database, the navigation through the data is similar to that of the network model where an object oriented database manager traverses the relationships defined amongst the objects and subobjects. In contrast to the relational database model, relationships between objects and subobjects are defined through the data, and not through explicit operations. Moreover, in complex application environments, objects and their relationships usually show very complex internal structures and comprise larger number of properties; such properties include methods. In addition, the object oriented database model parallels the object oriented programming model in that one may inherit attributes and methods from predecessor objects. However, the object oriented programming model generally deals with objects that are temporal in nature, i.e., memory resident. The object oriented database model extends the programming model by allowing one to deal with objects that persist, i.e., are disk resident. One of the features of object oriented databases (analogous to the programming model) is to provide the ability to define generic operations, i.e. methods, which apply to the objects, for the purposes of manipulating and retrieving them. In the relational database model, all operations to retrieve and manipulate records are performed by using the database manager's application programming interface or query language. The object oriented methodology insulates the users of the database from the data representation and/or data structures that comprise objects. All retrieval and update operations may be performed through the use of these methods.

Object-oriented database systems allow the semantics of a given environment to be modeled as a set of objects and relationships among them. Moreover, in complex application environments, objects and their relationships usually show very complex internal structures and comprise larger numbers of properties. With today's database systems, which are generally based upon a classical data model (hierarchical, network, or relational), they tend to be tailored to represent rather simple entities, thus resulting in large semantic gaps when dealing with more complex entities. In part this is true because one conceptual entity must be represented by a number of database objects (for example, records, tuples and so on). An object-oriented database system differs in that it offers a data model that allows the user to represent one conceptual real world entity by exactly one object or object class. This implies that an object-oriented model allows entities to be composed of subentities that are entities themselves, including recursive definition. There are several levels of object orientation:

Structurally object-oriented: Allows one to define data structures to represent entities of any complexity.

Operationally object-oriented: Includes generic operators to deal with complex objects in their entirety.

Behaviorally object-oriented: Borrows types from the object-oriented programming paradigm, a data model that incorporates features to define object descriptor types of any complexity together with a set of specific operators (abstract data types).

In summary, an object-oriented database paradigm offers increased modeling power by providing the ability to handle semantically meaningful objects rather than normalized tuples or single records. Such an approach greatly reduces the semantic gap between the real world and the database representation, while at the same time offering a more precise semantic definition of our real world.

In the relational database model, access privileges may be set on the records such that grant and revoke authorization privileges can be determined per user of the database. The records are tagged with either read or write privileges for specific users. For example, the first record could be read by users A, B, and C, and only written by user C. Likewise, the second record could be tagged such that only user A has the permission to read, and only user A has the permission to write.

For example, if a database contained payroll information, members of the payroll department may be able to read all of the payroll information for all departments except the payroll record for their payroll department. Only the manager of the payroll department would have the permission to read the record containing the payroll department data. If a user attempted to retrieve the records which did not define read privilege for the user, that user would not be granted the ability to see that record of data.

One shortcoming of relational databases is that access permission control is on a record basis and does not deal with objects, where objects represent complex entities and specific methods.

It is therefore an object of this invention to extend the definition of an access control list such that it applies to objects, and spans the objects and subojects, in an object oriented database.

It is a further object of this invention to apply an access control list to authorize the invocation of an operation on an object for changing the state of the object in addition to the permissions of read and write access.

It is a further object of this invention to facilitate a mechanism whereby access control policies on objects may be inherited from their superclass objects; resulting in the least privilege.

It is therefore a further object of this invention to move the knowledge of each configurable domain into the data by using an object oriented database; thus providing a set of facilities extendable in the field.

In the system and method of this invention, grant and revoke permissions, referred to herein as access control lists, expand the boundaries to a collection of objects in an object oriented database. An object data manager supports composite objects which are multiple objects and the access control policies that apply to such objects transparent to the user. The access control lists span across the objects. Furthermore, not only does the access control lists provide read and write permissions, but also provides execution permission for operations which apply to the objects. The execute semantics apply to methods that are invoked to perform operations on the objects. A user with execute permission can perform operations on those objects.

For example, if the objects in the object oriented database contained information on the configuration of a data processing system, a user could be either granted or revoked the permission not only to read and write the configuration data, but also to perform configuration operations on the data. If the configuration information contained information on the physical devices in the system, the user would be granted or revoked the permission to configure, define, start, stop, unconfigure, and undefine those devices.

Each entry in the access control lists of this invention can contain access control information for either users or groups of users specified by the corresponding user ids or group ids. The access control list has the information necessary to determine the privileges of read, write, or execute for a set of users or groups. Furthermore, upon receiving a list of user ids and group ids, the access control check routines perform a logical AND operation across the set of credentials represented by the different ids and returns the least amount of privilege.

The system and method of this invention provides a layered environment which spans from the task-based user interface to the low level functions of an operating system across all of the configurable domains of a system. The task-based user interface is geared toward the end-user and not the operating environment. The system and its configurable domains are described in a uniform and robust fashion by using an object-oriented paradigm. Since, the techniques used are extendable, the end user can add to their system management environment in any of the different layers of this invention.

The set of configurable domains encapsulated by the architecture are: (1) Devices (disks, printers, terminals and so on); (2) Filesysems/Logical Volumes; (3) Network Nodes; (4) Users and Groups; (5) Queues; (6) Subsystems; and (7) Error Reporting and Problem Management, etc.

The System Management Architecture is based on two key concepts. First, the architecture is highly open and extendable. By being open, a user can readily insert and remove the various aspects of the system management product. Second, the architecture uses an object paradigm for representing the description of the system, independent of its network context.

To provide extendibility, a number of distinct architectural layers were created. These layers are:

User interface

High-level commands

Methods

Low-Level commands/calling interfaces

System Management Services (provided by the Object Data Manager, kernel and so on)

The user interface layer is completely separate from the functions, tasks, and commands that provide the user tasks. To that end, the user is free to provide any user interface desired to represent the different tasks. The high-level commands layer, also referred to as the task layer, is executable entities which provide high level functions. A user is able to add and remove any of the high level commands which allows the user to customize the functions of the tasks which the user may need to utilize. Consequently, a user can add to or delete from the user interface to reflect the new or deleted tasks.

The methods layer views all of the entities in the system as objects. Given that there are objects, the methods define operations and actions that are to be performed on each object. As an example, in the area of devices, all of the devices including real devices and logical devices, are viewed as objects. Methods are used to define and undefine, configure and unconfigure, start and stop, each of the objects within the system environment. The objects are executable entities which perform particular operations that apply to the particular objects under consideration. For example, if a user wants to start an object of type printer, the method to start the printer is invoked. The methods embody low level functions necessary to perform the operations against the object.

Since all of the layers of the system of this invention are open and extendable, a user can easily add methods, objects, and corresponding changes to a user interface to manage system components which were not originally provided for, such as by the manufacturer of the system management product. For example, if a user wanted to include a printer into the system which was not originally provided for, a user could add to the user interface the configuration of the printer, the user could add tasks that would ad, delete, change, and show the printer, the user can then write the methods that apply operations to the printer object by utilizing the next layer of this invention, the low level commands.

The system management services include the kernel of the operating system, system libraries, system calls, and the object data manager.

The system and method of this invention also provides a single data representation across all of the configurable domains. The object oriented representation, i.e. data structure, provides a uniform and consistent representation of all of the data in all of the configurable domains. A configurable domain represents its data through the object storage an internal representation such that the configurable domain can access and retrieve the data appropriately. All configurable domains are reading and writing through the same interface.

FIG. 1 is a block diagram of the system of this invention having an object data manager for controlling the access to objects in an object database according to an access control policy associated with the objects and the user's credentials.

FIG. 2A is a hierarchy of objects in an object database showing superobjects, objects, and subobjects.

FIG. 2B is an illustration of an access control list for each object in an object database.

FIG. 2C is a hierarchy of interface menu objects in and object database showing superobjects, objects, and subobjects.

FIG. 3A is a flow diagram of the object data manager utilizing the access control facilities to determine whether a particular operation against a set of object classes and objects are permitted.

FIG. 3B is a flow diagram of the methodology for granting or revoking the operations based on the access control policies.

FIG. 3C is a continuation of the flow diagram of FIG. 3B.

FIG. 4 illustrates the structure of the access control list.

FIG. 5A shows the access control policy of this invention used in conjunction with a system management interface tool for controlling the administrative views of menu objects.

FIG. 5B shows a hierarchy of system management interface menu option objects.

FIG. 6 shows a block diagram of the layers of the system management architecture of this invention which provide an open and extendable facility.

FIG. 7 shows the system management architecture of this invention across configurable domains.

FIG. 8 shows how the layers are loosely coupled to each other in performing a specific task on an object class.

FIG. 9A is a flow diagram showing the flow of operation of this invention from the user interface layer to the high level command layer.

FIG. 9B is a flow diagram showing the flow of operation of this invention in the high level command layer.

FIG. 10A is a flow diagram of the code that is executed when the object data manager invokes a method.

FIG. 10B is a continuation of the flow diagram of FIG. 10A.

FIG. 10C is a continuation of the flow diagram of FIG. 10B.

FIG. 11A illustrates a user object class linked to other object classes in the object oriented database for the configurable domain users.

FIG. 11B illustrates the flow through the loosely coupled layers when using the system management facility of this invention with the configurable domain for user management and the user object class as shown in FIG. 11A.

FIG. 12 illustrates an object class linked to other object classes in the object oriented database for the configurable domain involving devices.

FIG. 13 shows the structure of a method.

FIG. 14A shows the odmopen interface for opening an object class.

FIG. 14B shows the odmclose interface for closing an object class.

FIG. 14C shows the odminvoke interface for invoking a method for a specified object.

FIG. 14D shows the odmadd interface for adding a new object to the object class.

FIG. 14E shows the odmdelete interface for deleting an object from an object class.

FIG. 14F shows the odmget interface for retrieving an object from an object class.

FIG. 14G shows the odmcreate interface for creating an empty object class.

FIG. 14H shows the odmdrop interface for removing an object class.

FIG. 14I shows the odmchange interface for changing the contents of an object.

FIG. 14J shows the odmterm interface which notifies the object data manager that no further ODM functions will be used.

The data processing system 1 has an operating system running in memory 3 which has tables 30 which contains the credentials 31 for each active user 32. The credentials identity 31 contains the user id 33, and the group ids 34 for which the user belongs and other security information 35. In user memory 4, the object data manager 40 accesses the objects found in the file system. The file system 20 resides on disk 2 which has object classes 50, as shown in FIG. 2A and FIG. 2C.

Referring to FIG. 2A, the object class devices 54 is further described with reference to commonly assigned copending patent application Ser. No. 07/352,571 filed May 15, 1989, in the name of R. A. Fabbio, for An Open System Management Architecture For Data Processing Systems, now abandoned in favor of continuation application Ser. No. 07/871,615, filed Apr. 20, 1992, herein incorporated by reference. Object class 54 is a super class of objects 55 and objects 56, and objects 55 is a superclass of objects 57. Likewise, objects 55 are a subclass of object class 54, and object classes 57 are subobjects of object class 55. The object class of the system management interface tool comprises interface menu option objects, as shown in FIG. 2C, and is further described with reference to commonly assigned copending patent application Ser. No. 07/352,530, filed May 15, 1989, in the name of R. A. Fabbio et al, for "An Object Database-Driven Interactive Shell for a Data Processing System" herein incorporated by reference

Referring back to FIG. 1, the object data manager 40 is cognizant of absolute access control policy assignment and authorization per object. The authorization process reviews the user's credentials 31 described to the object data manager 40 and uses this information to determine the operations which are permissible on each object.

When the object data manager is requested to perform operations on specific objects, i.e. retrieve or modify, the object data manager first determines the current credential attributes 31 for the user 32 requesting the operation by interfacing with the kernel 3. The object data manager then performs the operation which may require inheritance or subclass traversal through the objects. As the object data manager performs such an operation, the access control policies lists are checked for each object satisfying the criteria of the operation. Access control policies are treated like other attributes within an object class in that they may be inherited from other superclasses, thus altering the access control policies as traversal of the objects is performed.

FIG. 2B represents a user defined view of the devices object class 54 and one of its subclasses, customized devices 55. Devices object class 50 contains attributes 71, methods 72 and triggers 73. For example, for an object class of customized devices devices 55, the attributes 71 would represent the definition of the object such as device name 74 character string, device id 75 integer number, and device type 76 character string, etc. The methods 72 are the operations that apply to the object. For example, a method of configuring the device 77, the method of defining the device 78, the method of unconfiguring 79, and the method of undefining 80 the object, etc. Triggers 73 represent the events that are automatically invoked when the objects are manipulated.

In addition to the user defined attributes 71, the object data manager transparently maintains a separate access control list 100 as part of each object within each object class. The access control list is further shown in FIG. 4. The access control list 100 maintains the owning user id 101 and the owning group id 102 for each object. This owning information 101,102 dictates the access control policy for maintenance to the access control list itself. Only those owning users and owning groups can alter the access control list in an object. Before any access control entry is altered for any object, the object data manager first verifies that the user can be identified through its credentials in either the owning user id 101 or the owning group id 102.

The access control attributes on each object consists of eight 32 bit entries 111-118, of which seven of these entries 111-117 represent the user or group ids making up the access control list 100. The eighth entry 118 is divided into eight 4-bit slots 121-128, where the first seven slots 121-127 represent the privileges associated with the corresponding access control entry 111-117. The eighth 4-bit slot 128 is used to keep the count of the number of entries used. In the first seven 4-bit slots 121-127, the first three bits represent read, write, and execute privileges while the last bit of the 4-bit slot indicates whether the corresponding access control entry applies to a user or a group id.

FIG. 3A illustrates the high level flow of the object data manager utilizing the access control facilities to determine whether a particular operation against a set of object classes and objects are permitted. The object data manager opens the appropriate object classes, step 301, and determines if the open succeeded, step 302. The object data manager then iterates for each object class that was opened, step 303. When the list of object classes opened are processed, the results are accumulated and returned to the user, step 304. If there are object classes to process, the object data manager acquires the user's credentials from the operating system (resultant is the least privilege associated for that user based on the set's credentials), step 305. The object data manager then performs the retrieval of the selected objects, step 306, and checks to see if the object is available for further-processing, step 310, specifically whether the access privileges for the user do not conflict with the access controls assigned to the object being accessed. Specifically, the object data manager checks in the operating system for the credentials for the user, and checks these credentials with the list of access control privileges defined by the objects retrieved. If the access privileges are denied, the object data manager then checks to see if there are more objects that meet that selection criteria, step 315. If so, the object data manager returns to step 305. If not, the object data manager returns to step 303. Given that the object holds the appropriate access controls for further processing, step 320, the object data manager performs the specific operations generally defined by the methods. The object data manager accumulates the new set of access control information for the user based on the bitwise ANDing of the object's access controls, step 325 and returns to step 315 to determine whether there are more objects to retrieve. In step 325, the object data manager uses this technique to inherit the least access privilege that spans the objects of interest.

FIG. 3B describes in more detail step 310 from FIG. 3A which describes the methodology for granting or revoking the operations based on the access control policies. The access control facility first determines whether the requested modes supplied to it are valid, step 328. Given that the modes are valid, the object data manager defines a bit mask which is representative of the requested modes, step 331. In addition, the object data manager accesses the in memory version of the access control list assigned to a particular object, step 335. Once the access control list has been acquired, the object data manager determines the number of entries utilized within the list, step 337. If the count is not greater than zero, step 331, the object data manager grants access to the object by the user, step 341. If the count is greater than zero, the object data manager compares the user's credentials to the access control entry representing either a user or a group, step 344. If there is a match, the object data manager saves the index of the matching access control entry, step 346. It then checks to see if there are additional access control entries, step 352, and if so, returns to step 344. If additional entries do not exist, the object data manager determines if there were any matches between the user's credentials and the object's access control entry, step 355. If there are none, the access is denied to the object for that user, step 357. If a match exits, the object data manager acquires the privilege bit mask defined for that user on that object, step 359, FIG. 3C. The object data manager then checks to see if the requested bit mask is greater than the user's bit mask defined by the access control entry within that object, step 361. If the requested bit masks is greater, then access is granted to the object for that user, step 363. If the requested bits are less than or equal to, then a bitwise AND operation is performed between the requested bit mask and the bit mask found in the objects entry for that user, step 365. If the resultant is greater than zero, step 367, then access is granted to the object for that user, step 369. If the resultant is less than or equal to zero, then access is denied to that object for that user, step 372.

If a particular user is associated with multiple groups, and identifies oneself with multiple groups when performing operations on the objects, the object data manager will perform a bitwise AND operation of the particular sets of credentials that are currently associated with that user. This results in a assigning the least privilege associated with the intersection of the credentials sets.

The above described access control policies can be applied to various applications. One such application of this invention is described in commonly assigned copending patent application Ser. No. 07/352,530, filed May 15, 1989, in the name of R. A. Fabbio et al, for "An Object Database-Driven Interactive Shell for a Data Processing System" herein incorporated by reference. The access control lists of this invention can be applied to a system management interface tool for the purposes of defining the authorization policies for the various views that may be accessed by a collection of system administrators with various authorities. Without this invention, one approach would be to define the collection of menus, dialogs, and prompts to represent the permutations of the various administrative views associated with the different administrative privileges. However, this technique typically results in very large databases containing a great deal of redundant information.

In contrast, with the present invention, the various menus, dialogs, and prompts are only stored once in the object database, and are assigned the appropriate access controls on the various objects (menus, dialogues, prompts) such that the various permutations of administrative views are dictated by the access control policies.

For example, FIG. 5B shows a hierarchy of interface menu option objects for performing system management tasks, 500. Along with security and users, 504, other subclasses of system management interface objects include devices, TCP/IP, physical and logical storage, communications applications and services, problem determination, etc. As shown in FIG. 5A, administrator A, 551, may have read, write, and execute privileges for the user interface objects 553 which present the configurable domain of TCP/IP, devices, and users while administrator B, 552, may have read, write, and execute privileges for the user interface objects which present the configurable domain of just users, 554. However, administrator A, 551, may only have the privilege to access to view the users 542 and the groups 543, while administrator B, 552, has access to view and manage the access control lists, 541, the users 542, the groups, 543, and passwords, 544. Therefore, administrator A would only have access to menus 542,543, while administrator B would have access to menus 542,543,544,541 as the subobjects of the configurable domains menu object class for users.

The system management architecture of this invention is based on two key concepts. First, the architecture is highly open and extendable. Second, the architecture uses an object paradigm for representing the description of the system, independent of its network context.

FIG. 6 outlines the layers of the system management architecture of this invention which provide an open and extendable facility. The user interface 620 is the windows, icons, menus, prompts, and choices presented to the user for the purposes of providing system management tasks. An illustration of a possible user interface menu 611 is shown in FIG. 8. The user interface 620 will collect the correct flags, parameters, and options and invoke the appropriate high-level command 630 to perform the desired task. The user interface level 620, has means for adding to the interface including adding menus, dialogs, and the corresponding commands. The System Management Interface Tool (SMIT) is disclosed in a commonly owned copending patent application Ser. No. 07/352,530 filed May 15, 1989 in the name of R. A. Fabbio et al for "An Object Database-Driven Interactive Shell For A Data Processing System", which is hereby incorporated by reference. The System Management Interface Tool runs on al terminals. The interface called Motif was originally developed through Digital Electronics Corporation and Hewlett Packart and is being developed by the Open Software Foundation. The Motif-based User Interface will be used with high function graphics terminals. The fundamental point is that the user interface is an interchangeable entity within the system management architecture of this invention. Other presentation technologies may be substituted by the end-user/OEM community if they so desire without disrupting the other layers of the system management facility of this invention.

High-level commands 630, referred to as system management tasks, effectively provide a sophisticated, complex function geared toward the end-users point of view and not the operating environment. Each high-level command 630 is written as a program or shell script 631. FIG. 8, following the argument syntax and rules as defined by POSIX 1003.2 Section 2.8, which are herein incorporated by reference. The high-level commands 630 execute any number of methods 640 and low level commands 650 in order to complete each user task. Because each high-level command 630 invokes methods 640 through the Object Data Manager (ODM) 610, the high-level commands 630 may be written in a network insensitive fashion to perform generic user tasks, independent of the network context of the object(s) to be manipulated. The essence of this layer 630 is that the user/administrator may develop any number of system management tasks and introduce them easily into the system. Note that high-level commands 630 may be invoked from the shell 631, FIG. 8, without a sophisticated user interface 620. The high level commands can be either in shell script or a C program. Effectively the high level commands perform tasks. In the process of performing these tasks, the high level commands invokes methods.

Methods 640 are operations that apply to objects managed by the object data manager 610. The object data manager 610 provides the ability to associate operations to particular objects, thus providing the notion of "active" data. A method 640 is an executable program 641. The emphasis is for methods 640 to be entities that invoke a variety of low-level commands or low level functions 650 and other facilities that perform specific operations on specific objects. The object data manager 610 acts as a passive participant in the process and passes any or all text and return codes generated form the low-level commands 650 back to the application (high-level command 630) so that they may be diagnosed and reported. It is important to note that the high-level commands 630 invoke methods 640 representing operations that apply to a particular object, independent of the location of the object. Furthermore, new methods 640 may be created and associated with objects at any time.

Methods are operations that apply to the objects that are being manipulated and/or configured. The methods are invoked through a method interface which is defined by the object data manager. The object data manager interface defines the method which needs to be invoked, optional arguments that are to be passed to the method, and pointers to the stderr and stdout buffers. The methods themselves can also generate output. The methods invoke commands and low level functions. The commands and low level functions also generate output which is returned to the methods, the methods return the generated output to the high level commands, and the output from the high level command is returned to the user interface which managers the output. Therefore, there is a synergy between the layers as output is returned.

Low-level commands/interfaces 650 are fundamental. They typically provide simple, stateless, atomic operations and are quite often mapped on top of system level services 660, device drivers or subroutines, as executable entities. The low-level commands 650 are called by both methods 640 and high-level commands 630 and are written following the argument syntax and rules as defined by POSIX 1003.2 Section 2.8. Moreover, for those methods 640 which are written in the C language, the application programmer interface (API) 620 for each low-level command 650 is also available.

System Management Services 670 include system calls, subroutines, device drivers and utilities provided by the kernel, Object Data Manager, Logical Volume Manager, configuration, etc., which support the low-level commands/interfaces 650 and their function.

With the rich set of functions offered by the object data manager 610, each of the configurable domains 701-722, FIG. 7, may be represented, resulting in a consistent data representation across the different domains. Effectively, it has provided an environment whereby a great deal of the intelligence of the traditional application has been moved into the data.

In addition to defining object classes which represent these complex configurable domains and the relationships among them, the object data manager 10 has a variety of methods that been defined for each of the specific object classes, which represent operations that may be applied to each object. For each object, the object specific processing represented by a particular method is performed here, completely insulating all other layers of the details. As an example, for the devices objects 601 (FIG. 12), methods 621-624 have been developed to define 621, undefine 623, configure 622, unconfigure 624, start, stop, test, and problem manage each logical or physical device objects, etc.

The object data manager offers the ability to:

Define arbitrarily complex data types (called descriptors)

Define relationships statically and dynamically between object classes/objects

Apply inheritance such that objects share descriptor values in both a vertical and horizontal direction

Provide a pseudo transactional processing mode which supports the undo of logical versions

Associate methods and triggers with objects

Support authorization such that access control lists may be associated with each object

The object data manager 610 provides to the application writers the ability to create, relate, manage and manipulate object classes and their objects, without having an understanding of how the data is stored, and without having an understanding of what is needed to perform the operations on the objects. This offers a very powerful tool for representing complex objects and subobjects. In keeping with object orientation, the object data manager allows the user to define methods and triggers that relate operations to each object class or object.

FIGS. 9A-9B illustrate the flow of the system and method of this invention. First, a user begins at the top of the tree of the user interface 620 and navigates iteratively through the tree step 901 until the appropriate dialog is reached, step 902, in which the users wishes to enter data, change data, or list data, etc. When the appropriate dialog is reached, the user interfaces with the dialog, step 903, as indicated. Since a dialog represents an action, such as show data, delete data, add data, etc., the dialog is then executed, step 904. The executed dialog may be either adding a disk to a system, adding a user to a system, showing all the devices on the system, showing all the users on the system, deleting devices, or deleting users, etc., depending upon the configurable domain which the user is currently interacting with, and the action represented by the dialog which is chosen by the user.

The user interface 620 is a veneer which sits on top of the high level commands. In this way, the user interface 630 effectively executes the executable command, such as shown n FIGS. 14A-14J, with all of its options, flags, parameters, that had been filled in at step 903 and step 904 which enabled the dialog. In the process of executing the high level command, the user interface code performs the same function as shown and described later with reference to FIG. 10 in the way in which communication channels are managed. A communication channel is set up for reading standard error and standard output of the high level command that is invoked which is similar to the ODM method invocation facility.

After the dialog is executed, step 904, the high level command layer 630 is executed, step 906. Step 907 checks that the input parameters, options, flags, etc., that have been passed into it are valid. If any of these are n valid, step 908, an error is returned as an error message on the stderr communication channel. If an error is returned in text on the stderr communication channel, and the command was invoked from the user interface, at step 906, the user interface can read the error message and display the errors back to the user at step 903.

If the user input was correct, step 908, the flow continues at step 909 FIG. 9B. If a high level command or task is using the object data manager to get configuration represented as an object, the high level command would request that the object data manager open up the appropriate object class, or classes, where the objects are fond, step 909, and perform the appropriate operations no those objects, step 910. Depending upon how the code is written in the high level command, the methods, which are operations that apply to the objects, an either be invoked as part of the ODM call, step 911, such as the, show command, delete command, etc. as illustrated in odmget 812, FIG. 14F and odmadd 808, FIG. 14D, or after the operation is executed o the object, step 913. In either case, step 1001 of FIG. 10 is implemented either after step 911 or after step 919.

When all of the operations are performed, and all of the appropriate methods have been invoked, step 921 determines if the high level tasks are completed. If the high level tasks are completed, the appropriate object class, or classes, is closed, step 914. The appropriate text on standard output and standard error is then returned, step 915.

The invocation of the methods, either step 911 or step 919, causes the ODM to execute the appropriate code to invoke the method, FIG. 10B. The object data manager supports an invoke call which takes a method structure 1301 FIG. 13, as its input, step 1001. The object data manager takes the parameters 1303, FIG. 13, the method name 1302, and searches in the data base for the appropriate method that pertains to the object. The object data manager invoke code insures that the method structure parameters, object handles, and pointers are valid, step 1002. If all of the parameters are valid, step 1003, the object data manager xsystem routine is called, step 1006, and opens two pairs of read/write communication pipes for standard output and standard error, step 1007. The child is forked, step 1008, by making an identical process to the parent. Step 1009 checks to see which of these two processes is the child between the identical copies.

If the process is the parent, the parent process closes all of the write pipes, step 1012, FIG. 10B, that were opened from step 1007. The parent process selects on the read pipes waiting for input, step 1013. The parent process blocks on the select() waiting for output from the child, step 1015. If output comes from the child process, step 1014, the parent process reads the appropriate pipe, either standard error o standard out, step 1018. From the read in step 1017, the parent process fills in the appropriate incore buffer with the text that is being read from the stderr or the stdout communication channel, step 1018. The parent process then loops back to the select, step 1013 waiting for more output from the child process.

A signal handler is used to catch the death of the child process, step 1019. When the signal is caught, the parent cleans out the pipes, step 1021, and returns, step 1023.

If the process is the child, step 1009, FIG. 10A, the child process closes the read pipes, step 1025 FIG. 10C, that were created in step 1007 FIG. 10A. Then, the child's standard out and standard error file descriptors are closed, step 1026. The child process duplicates the write pipes, step 1027, that were opened in step 1007, FIG. 10A, onto the closed stderr and stdout file descriptors. After, stderr and stdout are attached to the write pipes that were opened, then the write pipes are closed, step 1028. The appropriate method is then executed, step 1029. If the method returns output on stdout or stderr, the parent can catch the output, step 1030.

This xsystem code, FIG. 10A-10C performs the equivalent of a popen system call and a fork/exec system call as known in association with the UNIX operating system a described in the AIX Operating System Technical Reference, second edition, Sep. 1986, order number SV21-8009, part number 74X9990, and which is hereby incorporated by reference. With the xsystem code, the interface 620 can capture the standard output. The standard output is the output from the high level commands such as the listing of the disks on the system, etc. The valid output comes out on the channel which is referred to as the standard output channel in the UNIX operating system. The interface also has the ability to capture the output from stderr, stderr output (the error output), of the high level command. The interface 10 can then display, scroll, and manage either standard output or standard error.

The above description illustrates the flow of this invention from calling the object data manager entry points as shown in FIG. 14A to FIG. 14M, and the method structure FIG. 13 which is filled in by the user/application and the object data manager, and the xsystem code FIG. 10A-FIG. 10C that is invoked within the internals of the object data manager.

FIG. 8, FIG. 12, FIG. 11A, and FIG. 11B illustrate the uniform operation of the system management facility of this invention across configurable domains through the loosely coupled layers within the system management facility in conjunction with an object oriented representation of the configuration data. In reference first to FIG. 8 and FIG. 12, the user interface 620 creates a dialog for the configurable domain of devices 702, FIG. 7, by asking for the volume group name, the size, the node, and what logical volumes are in it. The high level command 630 performs an odmopen 1402 on the customized devices object class 601 on a particular node. The high level command 630 also attempts to perform an odmget 1412 on the volume group name to make sure the volume group does not already exist. The high level command 630 then invokes the add method 640 passing the appropriate parameters such as the volume group name, the logical volumes, and the size, etc. Then the high level command 630 performs an odmclose 1404. The vg.sub.-- add method effectively adds objects of type logical volume group (lvg) to the customized devices object class 601, and to the customized attribute object class 631. The high level command 630 opens the appropriate object classes, adds the objects, closes the object classes, and returns any text.

FIG. 12 shows an example of the customized devices definition 601. The object class customized devices 601 is part of the device management configurable domain 702, FIG. 7. The configurable domain devices includes both real devices and logical devices. The names "hdisk0" 602, "lp0" 603, "tty0" 604, "ttyl" 605, and "sa0" 606 represent names of physical entities, such as hard disks, line printers, terminals, and a serial adapter, on a system. These are device objects of type physical. Volume group 1, vg1, 607 and volume group 2, vg2, 608 are logical entities, i.e. objects. They are devices of type logical. These logical devices represent groupings of physical disks that make up volume groups in the logical volume manager. The system management facility of this invention allows the same configuration object class to represent both physical and logical devices. There is a link 630 in the customized devices 601 to customized attributes 631 which links the attributes to each device in the customized devices 601 object class. A link signifies that there is a relationship to another object class.

The operation of the object data manager is illustrated with reference to FIG. 12 as follows. The data, e.g. devices 612, are defined through the fields 613-640. The object data manager will transparently traverse the links 630 to the object classes 631 that relate to the object class that is being searched. For example, if a user opens up the customized object class 601 and requests all of the data for hdisk0 602, the object data manager would retrieve all of the information in the customized devices 601 and the customized attributes 31 relating to hdisk0 602.

The executable methods 621-624 are columns within the object class 601. The executable program for the methods can be fond in the files defined by the path names within the column fields. For example, the define method 621 for hdisk0 602 is found through the path name "/etc/sysmgt/hdisk.sub.-- dfmeth". When the object data manager invokes a method 621-625, the method is executed. For example, to configure an object of type hard disks, there is a config method 622 for hard disks.

Another configurable domain, user management 710, FIG. 7, is illustrated with reference to FIGS. 11A and 11B which illustrates how one would use a user object 950 in the object data manager. A user interface 920 defines the appropriate dialog that is needed, for example, to add a user. The dialog 920 would ask for the user name 918, the password 922, the home directory 923, the groups 924 that the user wants to belong to, and the node 925 that the user is to be added to. Once this data was entered, the high level command makeuser, mkuser 930, would be invoked. The high level command 930 takes all of the parameters 931-935 that were entered in the dialog 920. The high level command 930 validates the parameters for syntactical integrity, 936, issues an odmopen 1402 (FIG. 14A) on the appropriate object class, e.g. users 950 FIG. 11A, and issues and odmget 1412 (FIG. 14F) to ensure that the user does not already exist, 938. Issuing the odmget could also be found in a method. Next, the high level command 930 invokes the add user.sub.-- user method 940 to add the user object to the object classes. The add.sub..sub.-- user method again takes the set of parameters 931-935 to validate the semantic integrity by determining whether a user already exits, and whether the group exists, 941. If these do not already exist, the method 940 adds the user to the appropriate object class 950 (FIG. 11A), and updates or adds the appropriate group information, 942. All of this would be done by calling the appropriate low level functions.

FIG. 11A represents an example of data that would be added by the method 940 of FIG. 11B. FIG. 11A also illustrates an example of object classes representing user information. A user object class 950 has a user name 951, user id 952, the home directory 953, etc. A link 954 to the password object class 960 contains the user name 951, the user password 961, and the date the password was last changed 962, and other relevant information. The password object claws 960 is a separate object class for security requirements. In the user object class 950, there would also be a link to a groupmap 970 which would provide the relationship between the users and the groups that the users belong to. In this example, the user Bob belongs to the admin group and the system group. The groupmap object class 970 has a link 971 to a group object class 980 where the group ids 982 can be obtained along with other relevant information on the groups themselves.

FIGS. 14A-14J illustrate some of the calls and data structures that utilize the object data manager and invoke methods. Both the high level commands and the methods utilize this interface to the object data manager. For example, the odmet 1412, FIG. 14F, specifies the criteria of the objects to be retrieved, passes the parameters, and invoke the methods for the retrieved object. The method structure 1437 contained within the odmget call 1412, FIG. 14F, and the odmadd call 1408, FIG. 14D, is shown as 1301 in FIG. 13.

Referring to FIG. 13, a user would supply method names 1302 to invoke, any optional parameters 1303 that need to be passed down to the method, whether the output of the method is to be returned on stdout 1304, and whether the error is to be returned no stderr 1305. The method is then executed. The object data manager supplies the return code value 1306 of the method. In addition, the object data manager supplies the buffer information for stdout 1304 and stderr 1305 from the code as flowcharted in FIGS. 10A-10C.

Referring to FIG. 14A-14J, the following odm interfaces are described.

odmopen() 1402, opens an object class.

odmclose() 1404, closes an object class.

odminvoke() 1406, invokes a method for the specified object.

odmadd() 1408, adds a new object to the object class.

odmdelete() 1410, deletes an object from the object class, given search criteria.

odmget() 1412, retrieves an object from an object class.

odmcreate() 1414, creates an empty object class.

odmdrop() 1416, removes an object class.

odmchange() 1418, changes the contents of an object.

The subroutine odmopen() 1402, FIG. 14A opens the object class and locks in the manner defied through either the class.sub.-- info structure or the ODM.sub.-- env structure. If EXPAND is specified, all of the class's subclasses are opened also.

The subroutine odmclose() 1404, FIG. 14B performs a virtual close of an object class. The object class is not actually purged from memory unless an odmopen() at some later time runs out of available slots. In this case, those object classes which have been odmclosed will actually be closed out. The force flag provides the capability of forcing the requested object class to actually be closed out.

Upon successful completion, a value of 0 is returned. If the odmclose() subroutine fails, a value of -1 is returned.

The subroutine odminvoke() 1406, FIG. 14C, invokes a method for the specified object(s). This provides the capability of invoking methods without adding, changing, deleting, or retrieving objects. Upon success completion, a value of 0 is returned. If the odminvoke() subroutine fails, a value of -1 is returned.

The subroutine odmadd() 1408, FIG. 14D, given the object class to add to and he corresponding data, will add a new object to the object class. You can add one object to each sub-class of this object class. If inherit substitution is done, then the values to be added will be replaced by the inherit constant if they exactly match the corresponding value.

Upon successful completion, an ID for the object is returned (O). If the odmadd() subroutine fails, a value of -1 is returned.

The subroutine odmdelete() 1410, FIG. 14E, given the object class to delete from a search criteria pointer, deletes all instances which satisfy those criteria.

Upon successful completion, a value of O is returned. If the odmdelete() subroutine fails, a value of -1 is returned.

The subroutine odmget() 1412, FIG. 14F, given the object class, will retrieve the objects from the class which meet the search criteria. If the object class is made of compound object classes, the use can elect to either expand the output or not. In addition this subroutine will support the buffer in ODM, STANZA, or COLON format.

Any descriptor which is not of the type ODM.sub.-- SHORT or ODM.sub.-- LONG and has its value as NULL will not be shown.

The odmget() subroutine needs to be called iteratively in order to fetch multiple objects meeting the selection criteria. This is accomplished in the following manner: 1) to get the first object provide a valid ucrit address to point to a valid search structure 2) for each subsequent call to get the NEXT object, supply a ucrit address of NULL.

Note: Because the ODM uses noncontiguous allocation schemes, it will perform the dynamic allocation of memory on behalf of the caller. It is important that both the ODM and the caller properly manage this dynamic memory. Specifically, the user may pass to odmget() different descriptor pointers for the purposes of caching multiple objects from any number of object classes at the same time. If this is so and the pointers passed to odmget() are automatic variables, odmfreeget() must be called before exiting the local function (this will free the memory). If the caller is using pointers which are not automatic, then one does not need to worry about calling odmfreeget(). The motivation for odmfreeget() is to ensure that the ODM is not continually allocating memory to pointers which are transient and thus resulting in danglingmemory with no way to manage it.

Upon successful completion, the odmget() subroutine returns the number of descriptors. If the subroutine fails, a value of -1 is returned.

The subroutine odmcreate() 1414, FIG. 14G, will create an empty object class by establishing the necessary director structures and creating the necessary files. The object class will be created at the location determined by the node and availability scope in the class.sub.-- info structure. If the object class is created successfully, it will be registered with the appropriate Object Manager. The object class name must be unique within its availability scope.

Upon successful completion, a value of 0 is returned. If the odmcreate() subroutine fails, a value of -1 is returned.

The subroutine odmdrop() 1416, FIG. 14H, removes an entire object class and all of its objects. Not that there is no checking done to see if there are other object classes are linked to the object class to be removed.

Upon successful completion, a value of 0 is returned. If the odmdrop() subroutine fails, a value of -1 is returned.

The subroutine odmchange() 1418, FIG. 14I, given the object class to modify, the search criteria and the new data (only for attributes which need to change), will modify all objects which satisfy the search criteria.

You can also change an object by its ID as returned by odmadd(). There is a #define in odm.h with the name of the object class descriptor which contains the object ID. You need only specify a criteria with this descriptor name and the object ID returned by odmadd(). See the example below.

Upon successful completion, a value of 0 is returned. If the odmchage() subroutine fails, a value of -1 is returned.

The subroutine odmterm() 1426, FIG. 14J, notifies the ODM that no further ODM functions will be used so that all ODM internal data structures can be freed and all updates to the object repository are propagated to disk. After this subroutine is called, the odminit() subroutine must be called again before using any of the ODM subroutines. Upon successful completion, a value of 0 is returned. If the odmterm() subroutine fails, a value of -1 is returned.

While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made without departing from the spirit and scope of the invention.