Patent Application
20060123016
The present invention relates generally to the fields of computer management and configuration of subsystems by an administrator, information rights management and authentication.
Distributed systems are computer systems (a system comprising I/O, memory, processors and the like) that are networked throughout a geographical area. A distributed system typically is composed of a number of subsystems, controlled by a system administrator (e.g., a system administrator of a system may control various users of the subsystems who may have fewer permissions and control over the system than the administrator). The systems and subsystems may be configured as clients in a N-tier client/server relationship, in a peer-to-peer relationship, or some other combination. Such subsystems may reside on different hosts in the network, and more than one subsystem may co-exist on the same host.
It is advantageous for an administrator to centrally manage and configure the subsystems. Further, the administrator may perform operations based on the relationships among the subsystems. For example, the administrator can subdivide common subsystems into groups. To change the configuration or state of subsystems en masse, operations may be applied to groups, rather than to each subsystem individually, to prevent information overload by the administrator, and to allow the scaling of the administration of the subsystems.
An incorrectly configured subsystem can misbehave or crash. It is thus important to validate the configurations of each subsystem. However, it is a challenge to design an administrative tool to enforce the validation. Present solutions implement separate logic to account for subsystem differences. This approach, however, does not scale well when the number of versions and the number of subsystems increase. Not only does the required development effort by programmers multiply, this approach is prone to produce erroneous code. A more systematic, scalable approach is desired.
The complexity in validating the configurations of subsystems lies in the number of possible permutations as subsystems evolve. Each subsystem may be customized through a configuration schema. Except for the simplest of schemas, each schema that configures a subsystem can be further subdivided into schema components that map to some runtime components within the subsystem. As a subsystem evolves, a new version of a schema having changes may be distributed. These schema changes, which complicate configuration and validation of a subsystem, may include:
Factoring all of the above, it can be seen that the complexity of configuration management of subsystems with schemas increases quickly. Even with just two to three coexisting subsystems, it is difficult to handcraft the configuration validation logic necessary. What is needed is a superior method and apparatus to configure heterogeneous distributed systems.
Accordingly, an aspect of the present invention is to provide an improved, scalable, method and apparatus to configure heterogeneous distributed systems.
The present invention uses a meta-data driven method and apparatus to manage configurations of coexisting heterogeneous subsystems. The present invention recognizes that schemas evolve incrementally from version to version. In a preferred embodiment, the method and apparatus of the present invention employs a software tool running on a computer.
The present invention employs two stages: an identification specification stage, to identify and/or specify any changes in a heterogeneous distributed system, and a configuration validation stage, to implement and/or validate the changes thus identified or specified.
In the first stage, the identification specification stage, the present invention programmably compares the next version of the schema from its previous version. This allows meta-data to be created that describes how a schema component evolves from version to version. In addition, a user (e.g., administrator) may specify what appears in the schema by adding additional metadata not automatically captured programably by the tool.
In the second stage, the configuration validation stage, the meta-data created in the first stage can be used to determine whether a particular component version of the subsystem is valid for a particular schema component, and vice versa, and/or to configure the subsystem to conform to the schema.
The advantage of the present invention is that it is scalable, flexible and extensible. The present invention is scalable because the logic used in the configuration validation stage needs no prior knowledge of the configuration schema. As the number of versions, subsystems, or subsystem features increases, no change to the validation knowledge is required. The present invention is flexible because the schema for each subsystem may be changed without affecting the validation logic. The present invention is extensible because validation of a new subsystem may be extended simply by generating a new set of meta-data for the new subsystem.
The method and apparatus of the present invention is a computing platform running a software tool, which can accept human input, and may be written in any computer language (such as C, C++, Perl, Java or the like) run by a computer system having an operating system. The computer system typically has one or more processors, primary and secondary memory cooperating with the processor(s), which executes instructions stored in the memory, an Operating System (OS), I/O means such as monitor, mouse and keyboard, and any necessary specialized hardware or firmware. Depending on the language used to construct and implement the software tool, the source code, object code and/or executable code of the tool may have any number of classes, functions, objects, variables, templates, lines of code, portions of code and constructs (collectively and generally, “a process step”, “step”, “block”, “functional module” or “software module”) to carry out the invention in successive stages as described and taught herein, and may be either a standalone software application, or employed inside of or called by another software application, or as firmware. The software process or software module may be constructed so that one portion of code in the application performs a plurality of functions, as for instance in Object Oriented programming (e.g., an overloaded process). The converse is also true, in that a plurality of portions of code could perform a plurality of functions, and still be functionally the same as a single portion of code. At any stage of the process step of the present invention, intermediate values, variables and data may be stored for later use by the program. In addition, the binary executable or source code data comprising the software of the present invention may reside on computer readable storage medium (e.g., a magnetic disk, which may be portable, such as a hard drive, floppy drive; memory (e.g., flash RAM); or a CD-ROM disk).
The sum total of all of the above advantages, as well as the numerous other advantages disclosed and inherent from the invention described herein creates an improvement over prior techniques.
The above described and many other features and attendant advantages of the present invention will become apparent from a consideration of the following detailed description when considered in conjunction with the accompanying drawings.
The numerous advantages of the present invention may be better understood by those skilled in the art by reference to the accompanying figures in which:
The present invention is to configure heterogeneous distributed systems. These systems may be any computer system such as a personal computer, personal digital assistant, mainframe computer, wireless telephone, web server, or any electronic device of any kind having electronic components and communicating with another electronic device of any kind. As explained herein, heterogeneous distributed systems are comprised of subsystems. Each subsystem has a set of features, which may be thought of as state variables, or subsystem features (configuration variables) that uniquely or as completely as possible describe the subsystem. For example, these state variables of a subsystem may include, but are not limited to, variables that identify a subsystem such as: operating system name, version number of one or more pieces of software (threads, processes, kernels and the like), firmware in the subsystem, hardware components in the subsystem (e.g., type of hard drive, memory, IO devices), or data (e.g. MAC address, Internet address, digital signature stored in the subsystem), and the like. The state variables can also be variables that describe a particular subsystem in real time, such as variables that map to runtime components or processes within the subsystem. The state variables may be defined during installation of the subsystem and stored in permanent memory of the subsystem, or, the state variables may be added at any time during the life of the subsystem. The state or configuration variables simply attempt to uniquely identify or capture a snapshot of each subsystem having one or more subsystem components or subsystem features, singularly and collectively, subsystem feature components (e.g., subsystem hardware components such as a particular hard drive, or subsystem software components such as a particular kernel in an OS, or a subsystem feature such as having a particular version of software on the subsystem). These subsystem feature components may change over time.
Ultimately, the goal of the invention is to identify the state variables, subsystem features or configuration variables that adequately describe the subsystem feature components, store these state variables as meta-data (data about data), and then map this meta-data onto a configuration schema which describes a particular state or configuration of a subsystem (i.e., a particular set of subsystem feature components for one or more subsystems). Then, any changes to the configuration schema can be detected, showing that the configuration of the heterogeneous distributed system has changed (i.e., one or more subsystem feature components have changed over time). Thus, one main idea of the invention is: 1) Schema and changes in schema are captured automatically (programmatically) in the meta-data; 2) State variables and how they place constraint on how the schema is applied to the subsystem is also captured in the meta-data; 3) The meta-data is used to determine whether or not a specific configuration may be applied to a specific subsystem.
In addition to this “bottom-up” approach, where changes are detected programmatically, changes can also be applied “top-down” manually for the distributed system. For example, an administrator can specify whether or not a schema component has been deprecated.
Finally, if a new version of a schema is used to reconfigure a component or a subsystem, the tool may be used update the metadata with information about the new schema, and the constraints under which to apply the new schema.
To this end, a preferred embodiment of the invention employs two stages: (1) the identification—specification stage, to identify and/or specify the state variables and schema subcomponents of the subsystem in the heterogeneous distributed system, and changes in the state variables and schema subcomponents, and how the state variables place a constraint on how the schema subcomponents may be used to configure the subsystem; and, (2) the configuration—validation stage, to validate and/or implement the changes in the subsystems of the heterogeneous distributed system thus identified and/or specified. It is understood from the teachings of this invention that the process of identifying a change in the state variables is not necessarily limited to passive observance of these variables but could mean actively specifying what the state variables should be, such as in the case of a system administrator who wants to make changes to subsystem components on a global basis.
Turning now to
Though arrows are shown in
Another step, shown in
A further optional step would include identifying any configuration schema change (i.e. change in subsystem features) that is conditional, that is, the validity is based on the presence or absence of some other subsystem features or state variables. Thus the dependency of the subsystem features may be expressed as either valid with the existence of a subsystem feature (e.g., a new schema or subsystem component is valid only when the subsystem is installed with a particular operating system), or, the non-existence of a subsystem feature (e.g., a new schema component is valid only when the subsystem is not installed with a particular operating system). A more complicated dependency can be expressed through logical operations on subsystem features. For example, a new schema component is valid only when feature “A” is present, and feature “B” is not present, which can be expressed by the XOR (exclusive-or) logical operator. Dependency can also be expressed more efficiently by applying pattern matching on subsystem features.
This step of conditional changes in the schema is shown in
Another optional step would include user intervention, shown in
Finally, an additional optional step may be added, as shown in block 20, so that additional meta-data regarding configuration schema changes can be generated with the schema diff tool shown by
At block 12, labeled “Meta-Data” in
Turning attention now to
Thus, as shown in
The tool then proceeds to block 205, labeled “Match Subsystems Features”, to match or find an association or nexus between the schema change of component “C” against the actual subsystem schema features (subsystem component features) present on the host. For performance reasons, if the current version of the subsystem does not have a schema change regarding “C”, but an earlier version does, the schema change for the earlier version of the subsystem (including all its subsystem feature dependencies) may be assumed to carry forward to the current version.
If there is no match, as shown in the “No” branch of decision block 210, the configuration validation operation ends and the program ends, as indicated by block 212, labeled “Operation Disallowed”, with suitable notice given to the user of the tool. The absence of a match means there is no association or nexus between any schema component “C” against any subsystem component. This may imply a systematic error, such as where one were to try and find a match between totally dissimilar electronic equipment and components having no similar architecture, such as a match between a mainframe computer and a wireless telephone. Or this may be because the component has not been installed on the subsystem, in which case the administrator has the option of upgrading the system or subsystem so that the component is present.
If there is one match, the meta-data is used to determine whether the configuration operation may be performed. As stated above, the categories for adding, deprecating and invaliding are as follows: adding a new schema component—the schema component did not previously exist on the subsystem (i.e., no subsystem feature component is associated with the schema component), or it was previously invalidated; deprecating a schema component—the schema component is still valid now, but will become invalid in the near future; invalidating a schema component—the schema component is no longer valid in the subsystem.
In all cases of a match, if the meta-data associated with the schema, as outlined in connection with
The configuration operation in the case of one match, as indicated by the “No” branch of the conditional block 215 in
(1) if the schema component “C” is added then the operation is performed (e.g., the actual subsystem(s) is upgraded so that schema component “C” forms a new subsystem feature component and so the subsystem now has the schema component “C” present), after checking to see if any allowed value “V” is within range, shown in
(2) if the schema component “C” is deprecated (i.e., the schema component “C” is still valid now in the subsystem, but will become invalid in the near future) then the operation is performed, after checking to see if any allowed value “V” is within range, but deprecated with a warning to the end user, i.e., as shown in the flow of
(3) if the schema component “C” is no longer valid (invalidated) in the subsystem, then the operation cannot be preformed (shown in
At the end of all possibilities, the program ends (e.g. as shown in
Turning attention now in
When there are multiple matches, a disambiguating rule must be applied as to whether or not to allow the configuration (e.g., upgrade) of the actual subsystems. There can be several such rules, depending on the semantics of the system (represented in
For example, a system that allows for two subsystems to share the same schema component may use the following rule (represented in
The configuration operation validation logic in the case of more than one match is as follows, which may be implemented in the source code of the tool by suitable logic, e.g., such as a CASE statement.
A preferred disambiguating rule for a two subsystem multiple match, shown in box 255 in
a. {added, added}—added, the configuration operation may be performed
b. {added, deprecated}—added, the configuration operation may be performed
c. {added, invalidated}—added, the configuration operation may be performed
d. {deprecated, added}—added, the configuration operation may be performed
e. {deprecated, deprecated}—deprecated, the configuration operation may be performed, with a warning to the user
f. {deprecated, invalidated}—deprecated, the configuration operation may be performed
g. {invalidated, added}—added, the configuration operation may be performed
h. {invalidated, deprecated}—deprecated, the configuration operation may be performed with a warning
i. {invalidated, invalidated}—invalidated, the configuration operation may not be performed
The above disambiguating rules are for purposes of illustration and not by way of limitation.
As indicated by boxes 250 and 252 in
As shown in
The tool then terminates at the end condition, box 241 in
As one of skill in the art should understand from the teachings of the present invention, while the configuration validation system using “added”, “deprecated”, and “invalidated” is one main concern of the present invention, the meta-data mechanism described herein is also capable to capture other validation information. For example, one important class of validation is checking if certain operations can be performed with a schema component, such as whether or not the subsystem configuration may be “created”, “modified”, or “deleted” on a particular subsystem. In addition, the present invention may be used in a digital rights management scheme, such as to validate certain components are legally installed in a heterogeneous distributed system.
Although the present invention has been described in terms of the preferred embodiments above, numerous modifications and/or additions to the above-described preferred embodiments would be readily apparent to one skilled in the art.
By way of example and not limitation, each subsystem may be customized through a configuration schema that associates with and maps to subsystem features components within the subsystems. In addition to preexisting software and hardware, the configuration schema can include schema components that map to some runtime components within the subsystem in real-time. As a subsystem evolves, a new version of a schema having changes may be distributed. These schema changes may include:
adding a new schema component to a subsystem (viz, adding a new subsystem feature component to a subsystem): the schema component did not previously exist, or it was previously invalidated;
conditionally making a schema component (viz, a subsystem feature component associated with a schema) valid based on certain other subsystem features, e.g., based on actual features installed in the subsystem, or the actual operating system features of the cost, or some other prerequisites;
deprecating a schema component: the schema component (subsystem feature component) is still valid now on the subsystem, but will become invalid in the near future;
invalidating a schema component: the schema component is no longer valid in the subsystem;
changing the allowed values for a schema component;
coordinating changes among subsystems: (1) moving a schema component from one subsystem to another, by invalidating the schema component in one, and adding it to another; (2) sharing a schema component, by adding a schema component to one or more subsystems; (3) unsharing a schema component, by invalidating a schema component in all but one subsystem
It is intended that the scope of the present invention extends to all such modifications and/or additions and that the scope of the present invention is limited solely by the claims set forth below.
