The following sections provide a detailed description of how the interfaces and functionality combine to form the basis for system administration applications.
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
participant in the relationship maintains a list of the
other participant's object
references. Objects supporting the
Sets may be subject to policies, in that an object can inherit both the
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
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.
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
defines interfaces for creating and managing
object instances within the systems management framework.
This service is provided by the
module and defines
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.
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.
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.
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
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
The client's view of object creation is depicted in
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.
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:
field is set to the string passed by the client
of object creation, while the
field is filled in by the
to uniquely identify the
object pair that was responsible for creating the
are responsible for enforcing the fact that the
value for the
field supplied by the client is not already in use by a
contained within the same
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
upon which a creation request was performed, an exception is returned
and the creation fails. Note that
since the label type is really the
type defined in the
module, usage of the
COS Naming Service (see reference COS Volume 1)
to maintain consistency between the
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.
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
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.
When a new instance manager is developed, it is installed into an environment
when it is created by a library object. The
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
call using the
are defined in
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
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.
The policy service defines interfaces related to policy and the management of
This section describes the policy management service including policy regions and policy objects.
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.
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 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.
The mechanism for the enforcement of policy is an application development-time
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