Management Facilities Architecture

• Separation of interface and implementation

• Object references are typed by interfaces

• Clients depend on interfaces, not implementations

• Use of multiple inheritance of interfaces

• Use of subtyping to extend, evolve, and specialize functionality

The following sections provide a detailed description of how the interfaces and functionality combine to form the basis for system administration applications.

Managed Set Service

In the set relationship, all member objects know of all sets to which they are members, and all sets know of all objects which are members of the set. Each participant in the relationship maintains a list of the other participant's object references. Objects supporting the Member interface contain back references. A back reference is a reference from an object to the set object to which the object belongs.

Sets may be subject to policies, in that an object can inherit both the Set and PolicyDrivenBase interfaces. The decision about whether a set is policy-driven is independent from the decision of whether to associate policy with the members of a set. A set may be subject to policy, and its members may not.

Set objects contain references to a set of objects, which are referred to as it's members. There is no unified ordering to the members of a set. Objects must support the Member interface in order to be allowed as members of a set. The Set interface itself inherits the Member interface. Therefore, set objects can be members of sets.

An example of a set could be the users within a system who are members of the company volleyball team, or all users that receive mail regarding company marketing plans. Sets offer a way for system administrators to organize resources into logical groups.

Because sets can refer to other sets, they can be organized into hierarchies. In addition, because sets are just groups of references to objects, an object can belong to any number of sets. Users of an application can organize their managed resources into a suitable hierarchy, and create multiple sets of those resources. A set can be heterogeneous, meaning that it can group objects of different types. Application developers can create sets that have as members a combination of hosts, users, or other types of objects.

Managed Sets Compared with UNIX File Systems illustrates the parallel nature of managed sets and UNIX directories. Both sets and directories contain various types of items, including subsets and subdirectories. You can think of a set as a directory and an object as a file. Note that the figure shows the Hosts set object as an example of an set that is not a member of any other set. In this way it is similar to the root directory of a file system. As shown in the figure, the Hosts object contains the Engineering and Marketing objects, which contain the hosts maintained by these departments. The parallel to a UNIX file system is not exact, however, because you can remove a set without deleting its members. In fact, you can remove the last set to which an object belongs without deleting the object.

Because they inherit the Member and Set interfaces, operations invoked on an object supporting the Set interface will not propagate along the relationships of the set. That is, when a set is removed, the objects that are members of the set are not affected.

Policy-driven Base Service

The operations defined in the PolicyDrivenBase interface are the minimum required to support object-oriented policy-driven application integration and installation in the framework. Without such a capability each application and policy-driven object within an application would not be able to be integrated except in a superficial manner. This service provides a strong foundation that enables applications to be more fully integrated and function in a similar manner.

The PolicyDrivenBase interface inherits the ManagedInstances::Instance interface. Thus, all policy-driven base objects exhibit the behaviors of managed instances, such as having a name, being capable of belonging to sets, and being managed by an instance manager.

The PolicyDrivenBase interface is to be inherited by policy regions and by any object that is to be a member of a policy region. A policy region is a entity that allows a system administrator to associate custom rules or policies with objects in an installation.

Instance Management Service

The Instance Management Service defines interfaces for creating and managing object instances within the systems management framework. This service is provided by the ManagedInstances module and defines three fundamental roles; an object can be:

• A managed instance

• A factory for and managed set of a specific type of managed instances (instance manager)

• A factory for and managed set of instance manager objects (library)

A managed instance is an instance of a particular type of managed object that is represented and managed by a single instance manager. A managed instance object supports the Instance interface. The Instance interface provides operations that determine and report the object's type and return the object reference of the instance manager by which it is managed.

An instance manager acts as a factory for managed instances, encapsulating the type and implementation specific information needed for managed object creation. There may be many managed instances of a given type within an installation. Additionally, there may be one or more instance managers that manage the instances of a given managed object type. The BasicInstanceManager interface defines operations needed to create managed instances and group them into sets. The InstanceManager interface provides all capabilities of the BasicInstanceManager and the additional capability to support the specification of policy to be associated with managed instances.

A library acts as a factory for creating instance managers and has the ability to maintain a list of instance manager objects. A library also acts as a factory finder, allowing instance managers to be selected based on characteristics such as the interface of managed instance that they support and the type of policy objects that are registered with them. The creation and deletion of instance manager objects through the library has the effect of adding and removing managed object types to the running environment. In a given installation, there may be more than one library object maintaining instance manager information.

Instances

The Instance interface inherits the ManagedSets::Member interface. This is fundamental to allowing managed instances to be managed by instance managers. It also provides the Identification::Labeled interface which allows a managed instance to be named, which instance managers require of their instances.

The Instance interface introduces new operations which can report information about the managed object's type, who its instance manager is and the location where the managed object exists.

Basic Instance Managers

It is important to note that the relationship between managed instances and basic instance managers is one-to-many - one instance manager for many instances. The relationship between managed object types and basic instance managers is also one-to-many - potentially many basic instance managers supporting a single managed object type.

This is illustrated in Managed Object Types Relationship to Basic Instance Managers . Because there may be more that one basic instance manager per managed object type, basic instance managers could also represent a scope of influence, and manage the object types within their scope.

Each managed object type controlled by a basic instance manager can be identified by both a type name and a type definition. The type definition is specified in the IDL interface defined by a programmer and is contained in an InterfaceDef. The type name should be a name suitable for display at the user interface and for use as an argument in command line operations and programs. The basic instance manager maintains the type definition and the type name. The type name is available on a read-only basis from each managed instance of the type.

As a participant in object creation, a basic instance manager encapsulates much of the behavior commonly considered factory object and factory finder object behavior. A factory can create objects. A factory finder locates a factory for a particular type of object in a particular location. In the general case, a factory finder can be used to locate a factory that can create objects of type X in location Y. The factory behavior of the basic instance manager is exposed to the client through the CosLifeCycle::GenericFactory interface, while the factory finder behavior is not exposed to the client for direct use.

The client's view of object creation is depicted in Client View of Object Creation . When a client creates a managed object, the client locates the basic instance manager associated with the managed object type to be created. The basic instance manager can be located using the library object. The client invokes the create_object operation, inherited from the OMG standard CosLifeCycle::GenericFactory interface, on the instance manager object. This operation provides a common interface for creation of all managed objects. The create_object operation is a specialization of object creation as defined in the OMG Life Cycle Service. When invoking the create_object operation, the client specifies a label for the new managed instance and the desired location of the managed instance identified by a location object reference. These parameters are passed through the the_criteria parameter of the create_object operation. If each of these parameters is not specified, an exception is raised. The label and location are a specialization of object creation as defined in the OMG Life Cycle Service.

The Common Object Services Specification (see reference COS Volume 1) defines the k parameter of the create_object operation (of type Key) as being used to identify the desired type of object to be created. This definition, while interesting in a more general application domain, is redundant with the concept of instance managers. Thus, the specification of the Key in the k parameter is not required, and may be ignored by implementations of the create_object operation of the GenericFactory interface when inherited by the BasicInstanceManager interface. Alternatively, implementations may use this information, if supplied by clients of creation, as a basic form of run-time type checking to ensure that the basic instance manager really creates the managed object type the client desires.

When a managed instance is created, the requested label must be verified for uniqueness. The label that is stored within the state of each managed instance is actually comprised of two fields: id and kind. The id field is set to the string passed by the client of object creation, while the kind field is filled in by the BasicInstanceManager to uniquely identify the BasicInstanceManager/Library object pair that was responsible for creating the instance. BasicInstanceManagers are responsible for enforcing the fact that the value for the id field supplied by the client is not already in use by a managed instance contained within the same BasicInstanceManager. In this way, the two-component label of any object is unique among all managed instances created within the environment. If the requested label id is already used by a managed instance contained by the BasicInstanceManager upon which a creation request was performed, an exception is returned and the creation fails. Note that since the label type is really the NameComponent type defined in the CosNaming module, usage of the COS Naming Service (see reference COS Volume 1) to maintain consistency between the managed object namespace and managed object containment hierarchy is straightforward¹.

The location of the managed instance is specified by supplying an object reference to an object supporting the Location interface. This interface defines the logical location for the managed instance. The location could be a set of hosts in an environment, or it could be a specific machine. In system administration applications it is critical to be able to locate a managed instance on a particular host. For example, if a managed instance represents a user account, then when the account information changes, the files on exactly one specific machine should be changed to reflect the new information.

Any type-specific initialization for a newly created object is handled by interactions between the basic instance manager and the factory object. This design allows a client to treat managed objects of all types identically for object creation, yet allows object-type specific interfaces to be used with the actual operation on object factories. Therefore, to the client a managed object creation request simply involves invoking a standard request on a basic instance manager and having the object reference of the new object returned.

Type- or implementation-specific initialization may involve creating or allocating persistent storage, defining default values for attributes or states, or involving the new managed instance in relationships with other objects. When a managed instance is created, regardless of the type, it becomes a member of the basic instance manager set. This set serves as a repository that may be queried to find managed instances of a given type. Other name spaces for managed instances may be created for performance or organizational reasons. However, this default set ensures that managed instances are not orphaned, and serves as a starting point for building alternate name spaces.

The basic instance manager performs all required work to satisfy the request for managed object creation. The basic instance manager finds a factory of the correct type, in the correct location. Once the factory is located, the basic instance manager can enter into a private protocol with the factory to provide object type- or implementation-specific initialization or other information. The basic instance manager can obtain the object reference of a factory in a particular place in any of a variety of ways. For example, by querying a name service, if one is present, or it can maintain a private copy of the object references to factories on other client machines or servers using the location object reference.

Because of their use for object creation and the need to interact with the actual object factories for creation of managed objects, much of the implementation of a basic instance manager will normally be tied to a specific ORB implementation. Since a basic instance manager deals with only one type of object, the InterfaceDef used when registering managed instances with the basic object adapter (BOA) will be the same for all instances. The ImplementationDef used may vary across instances based on the host or server in which the managed instance is created. The information needed by a basic instance manager at the time it is created and installed in an environment will be dependent upon the needs of the ORB implementation to which it is related.

Instance Managers

The create_object operation on an instance manager is a further specialization of what is defined in the OMG Life Cycle Service. In addition to the specializations defined for the basic instance manager, the instance manager requires that one or more policy regions be passed in the the_criteria parameter of the create_object call. The policy-driven base managed object that is created will be added as a member of each of these policy regions.

Instance managers provide operations for the registration of initialization policy objects and validation policy objects. These policy objects are specifically associated with the type of policy-driven base managed object supported by the instance manager. These are the policy objects that are available to policy regions for use with this type of managed object.

The initialization policy objects and validation policy objects are used by policy regions to encapsulate a set of management policies and support high-level operations that control a particular managed object type. Initialization policy objects support operations to define the initial (default) values of the policy-driven object attributes. Validation policy objects support methods that can validate initial values or changes to object attributes, and also methods that can be used to control object behaviors. In Instance Managers and Policy Object Relationships , the Library object is shown referencing an instance manager and several basic instance manager objects.

A single instance manager object may contain references to one or more initialization policy objects and one or more validation policy objects. Each such policy object can define different policies that can be used to control managed instances. Users can define their own management policies by customizing an implementation for an existing initialization policy or validation policy object, or by creating a new implementation of an initialization policy or validation policy object and attaching the new object to the instance manager.

In general, throughout this specification, the use of the terms instance manager and basic instance manager is not precise. A reference to a basic instance manager describes all instance managers, and reference to an instance manager may well also apply to basic instance managers, unless the subject matter specifically deals with policy management.

Library

When a new instance manager is developed, it is installed into an environment when it is created by a library object. The create_object method used to create the instance manager is a specialization of object creation as defined in the OMG Life Cycle Service. There are several different elements that can be passed on the create_object call using the the_criteria parameter (these are defined in Management Facilities Specification ). Which of these elements are required, which are optional and which are not supported is implementation specific.

The find_factories method of the CosLifeCycle::FactoryFinder interface is used to locate instance managers which have certain characteristics. These include thing such as the type of objects the instance manager supports, the interface of the instance manager itself and the kinds of policy objects registered with it. Clients can use this capability to locate an instance manager which meets their exact needs.

It is anticipated that in an implementation of the system administration framework with a name service, the name(s) and object reference(s) to the library object(s) will be bound into the name service. This binding will allow objects to know very little about an installation prior to beginning to discover instance manager objects and managed objects in the installation starting at the library object.

Policy Management Service

Policy makes it easier for administrators to customize applications by allowing administrators to make the applications reflect the way their systems are managed. With policy, administrators can implement their own organization-specific rules for system administration.

Like any other set of rules, policy must be enforced to be effective. Policy regions enable the enforcement of policy. Policy regions associate specific policies with instances of policy-driven object types. A policy region is a special type of set of policy-driven objects. Like sets, policy regions can be arranged hierarchically according to organization- and administrator-specific criteria and can contain any set of objects an administrator wants.

The policy service defines interfaces related to policy and the management of policy. These interfaces relate to the establishment of policy regions, the objects within a policy region, the reporting of associated policy, and the definition of policies themselves.

This section describes the policy management service including policy regions and policy objects.

Policy and Administrators

Policy regions are filtered sets to allow them to be grouped and managed in an organization that is natural to the administrator. While the selection of members for a policy region is arbitrary in terms of the framework itself, policy regions can be used to model real-world organizations. For example, an administrator could create a policy region that represents the network resources belonging to the Engineering Department. Member objects of the policy region would follow policies governed by the Engineering Department. A policy region can contain any object supporting the PolicyDrivenBase interface, including other policy region objects.

One of the most important requirements of policy regions is that they be easily customizable by an administrator to implement the local policy of an organization. This can be done in one of two ways: by replacing or customizing one or more operations of an existing policy object whose operations are used by the policy region object, or by creating entirely new policy objects that implement a different policy than the original. A single instance manager that supports objects of a single type may reference many policy objects, each of which implement a different kind of policy, such as an engineering user policy and marketing user policy. Only one of a given instance manager's policy objects may be associated with any given policy region.

Policy Region and Policy-Driven Object Relationships illustrates the relationships between policy regions and policy-driven objects. A policy region is shown referencing several instance managers, initialization policy and validation policy objects, and instances of policy-driven objects. Each policy region object references a set of policy-driven objects called its members. In the Engineering policy region, these objects might represent all the users and all the hosts that are part of Engineering. For each type of object supported, the policy region maintains a reference to the appropriate instance manager object and uses the methods from a single initialization policy object and a validation policy object associated with that instance manager.

In addition, this figure reflects the fact policy regions are themselves managed by an instance manager. This is labeled "Policy Regions Instance Manager".

Policy Region

• The policy region has a reference to the instance manager(s) for the type.

• The policy region maintains a reference to an initialization policy object for the instance manager.

• The policy region maintains a reference to a validation policy object for the instance manager.

Policy region objects supply the policy implemented by the initialization policy and validation policy objects for each supported type. The initialization policy object for a type provides a method to initialize new objects. New objects are thus always created within the context of a policy region and are said to be members of the policy region.

An initialization policy object provides methods to generate initial (default) values for the attributes of the policy-driven objects. The methods of an initialization policy object thus provide a set of recommended values to use when creating new objects. These may be modified on a per-policy region basis, thus allowing for different configurations for the same type in separate policy regions. For example, the default login shell policy for a user in the Engineering policy region might be /bin/ksh while the default login shell policy for a manager in the Executive policy region might be a window-shell. Note that an initialization policy object does not, however, provide enforcement as far as maintaining those values. This is performed by validation policy methods.

A policy region may also use the methods from a validation policy object for an object type. When this is true, the policy region object is said to have validation of policy enabled for that type managed by the instance manager. When validation of policy is enabled, the policy region object provides a powerful mechanism that enables enforcement of management policy. The validation policy object provides a validation method for each aspect of a managed object that is subject to policy. Validation operations enable the state of objects to be verified against policy. Object state in this context includes such things as data values stored by the object (attributes) and operational information related to the object (backup this object's state daily), etc. Thus, a broad range of components may be validated using this service. Typically, each validate operation is defined to take as input data that reflects the proposed change to the state and returns TRUE or FALSE as to whether the new value is valid. If FALSE is returned by the validate method, the update (or initial value) of the attribute is rejected and the modification request can be aborted.

Enforcement of Policy

The mechanism for the enforcement of policy is an application development-time procedure. The policy-driven base object designer defines which attributes, activities or methods should be subject to policy. Recall that policy is enforced by methods that encapsulate the particular policy and evaluate a proposed change. The policy method either evaluates to true or false and the requested activity is either allowed or rejected, respectively. Given that it is not possible to associate a policy with something at application run-time, it is strongly recommended that the application developer take a liberal view of what might be subject to policy. In general, all operations that can cause a change in state of the object and the underlying system resource it models are appropriate for the application of policy. Typically, policy methods are, by default, disabled so that the policy is not checked, or the policy methods are hard-coded to return true without any further processing.

Each invocation of a policy method is preceded by a check to see whether policy has been enabled or disabled. If policy is disabled, then the policy-driven base object should be structured to act as if there was no policy associated with the activity. Again, if policy is enabled, then the policy method associated with the particular activity is invoked to determine whether to allow or disallow the operation.

Given this means for the enforcement of policy, the application developer has significant latitude in the ways in which policy is enforced by an application. For example, when an object could not be subjected to policy validation on a regular basis, it could be an administrator defined time when the policies are checked. As another example, when an object is moved from one set to another, or simply added to a set, then the set object could, prior to adding it to the set, check to verify that the object to be added conforms to the relevant policy for the set.

This discussion has focused primarily on policy validation, the verification that an object conforms to the policy to which it is subject. In addition, there are initialization policies that might be associated with objects. Initialization policies are generally associated with object creation and enable system administrators to write a method that will generate default values for parameters that might follow a simple formula, thereby saving the administrator significant time during the operation of the network and day-to-day administration. Additionally, a more senior administrator might determine the defaults to be used and thus not require or enable a more junior administrator to "make up" values for particular parameters.

Footnotes

1.

In fact, a possible implementation of the ManagedSet service would be to wrapper an implementation of the CosNaming service.