Computer networks have traditionally been relatively difficult to administer, especially as they grow in physical size and in the number of network-attached entities. One relatively recent advance in administering networks is the directory service. A directory service associates a data structure, such as an object, for each network entity managed by the service. Each object maintains information about a network entity. Some directory services organize these objects into a hierarchical tree structure that simplifies overall management of such entities. The hierarchical tree structure that can be graphically presented to visually illustrate the parent/child relationships between the entities. The advantages of a good directory service has become such an important aspect of a network operating system that network operating systems are frequently purchased solely on the strength of their directory service capabilities.
Some vendor's directory service products allow the directory to be distributed across various servers on a network. One directory service product, NOVELL DIRECTORY SERVICES (NDS), categorizes each object in the tree as either a container object or a leaf object. A container object can be a parent to other container objects, and to zero or more leaf objects. Container objects are typically used to provide a logical organization to the tree, while the leaf objects represent actual network entities, such as servers, printers, facsimile machines, and users.
Objects are created, or "instantiated" from a class definition that defines the default attributes associated with each respective object type. Class definitions are maintained in a data structure referred to as a schema. Each directory tree has its own schema, and more than one schema may be associated with a particular directory tree.
A directory service typically imposes certain containment rules that govern the relationships between objects in the tree. For example, container rules prohibit a container object from being subordinate to a leaf object. Moreover, certain types of container objects, such as an Organization container object cannot be subordinate to an Organization Unit container object. Containment rules help ensure a logical and therefore intuitive structure of the tree and are maintained in the schema.
A directory may administer hundreds or even thousands of network entities. Consequently, directory trees can become very large, and without a logical organization, administering a network entity can become quite cumbersome. For this reason, container objects are used to create logical nodes in the directory tree. For example, a directory may have a respective Organization container as the root, or parent, node for each separate country in which the organization has facilities. Immediately subordinate to the Organization container, there might be one or more Organization Unit objects to further subdivide the respective organization into one or more logical divisions, such as marketing, engineering, and research departments. The directory tree may branch out indefinitely until it terminates with one or more leaf objects, each of which typically represents an actual network entity. Management or administration of a particular object typically involves traversing a graphical representation of the tree, further necessitating a logical order to the tree structure.
Sometimes it would be useful to move a group of objects that share a common node from one location within a tree to another location. For example, an organization may have several directory trees on a network, such as a production directory tree and a test directory tree. It may be desirable to copy a subtree of objects from the production directory tree to the test directory tree for testing purposes. Or it may be desirable to move a subtree of objects within the same tree. For example, due to a company reorganization, it may be useful to move a subtree from one location within the tree to another location within the tree to accurately reflect a new reporting hierarchy. In either of these situations, such a move may violate containment rules and therefore be prohibited. For example, if the subtree has an Organization-type object as its root node, and it is to be moved subordinate to either another Organization-type object, or to an Organization-type Unit object, such a move would be prohibited by containment rules. Consequently, the objects must be deleted from their initial location and then added at the desired location. This can take considerable time, and is fraught with the potential for introducing erroneous data into the attributes associated with the object.
In addition to containment rule problems, moving objects, or groups of objects such as a subtree, across schema boundaries, whether intra-tree or inter-tree poses other problems as well. An object in a directory tree is created from a template, or class, which is defined in the schema associated with the tree. The class definition of an Organization-type object in a source directory tree may differ from the class definition of an Organization-type object in a destination directory tree. For example, the class that defines an Organization-type object in the source directory tree may include a primary contact attribute, while the class that defines an Organization-type object in the destination directory tree lacks such an attribute. Thus, when moving an Organization-type object from the source directory tree to the destination directory tree, a problem arises as to how to maintain in the destination directory tree the primary contact information that is maintained in the source directory tree. Conventional directory service products fail to address these issues.
U.S. Pat. No. 5,608,903 discloses a method for moving a subtree of objects within a directory, but does not allow moves that would violate containment rules, nor does it suggest moving a subtree across schema boundaries.
It is apparent that a method and system that allow a move of a subtree irrespective of the containment rules of a directory, and, ensure migration of all object attribute information when a move crosses schema boundaries would be highly beneficial, and would further simply network directory management.