Synchronization method for an object oriented information system (IS) model

FIELD OF INVENTION

The field of invention relates generally to the software arts; and, more specifically, to a synchronization method for an object oriented Information System (IS) model.

BACKGROUND

An information system (also referred to as an “IS system”) is an orchestrated collection of computing and networking hardware and software components designed to collectively support some kind of organization (e.g., a partnership, a corporation or a government institution). Advanced information system (IS) configuration and maintenance software tools are migrating to an environment in which detailed object oriented models for specific IS features (e.g., clients, servers, routers, software installations, hardware installations, etc.) are used to effect intelligent and automatic configuration and/or maintenance tasks. Examples include the efforts of the Web-Based Enterprise Management (WBEM) initiative and the Common Information Model (CIM) specification(s) (e.g., the Common Information Model (CIM) Specification published by the Distributed Management Task Force, Inc., Version 2.2, Jun. 14, 1999).

<figref idrefs="DRAWINGS">FIG. 1</figref> shows an exemplary depiction of such an object oriented model <b>100</b>. According to the depiction of <figref idrefs="DRAWINGS">FIG. 1</figref>, an object is used to represent a server having a dispatcher and worker nodes. Object <b>101</b> represents the dispatcher. Objects <b>102</b>-<b>105</b> represent the worker nodes and objects <b>106</b>-<b>109</b> represent associations between the worker nodes and the dispatcher.

In order to successfully implement maintenance and/or configuration tasks, live “tracking” of the state of an IS system (where, the IS system has two or more IS components having at least one association between them, where, a “component” is some identifiable unit of functionality) is often beneficial. A problem, however, is that the specific changes made to an IS system (e.g., by some kind of “event” (like a failure or bring-up)) may be “lost” or otherwise not presentable for purposes of updating a detailed object oriented model of the IS system to reflect the changes. If so, all that is available is the “new” state of the IS system (i.e., the state of the IS system after the change).

SUMMARY

A method is described that involves generating an update to an object-oriented model of an information system from information that describes a new state of the information system. The generating includes applying a synchronization rule for a sub-system identified within the information system. The synchronization rule indicates whether a new component within the sub-system that appears within the information is merged within the sub-system or replaces a component within the sub-system.

FIGURES

The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:

<figref idrefs="DRAWINGS">FIG. 1</figref> shows an object oriented model for an IS component;

<figref idrefs="DRAWINGS">FIG. 2</figref> shows a synchronization system that can introduce changes to an old IS system model from information describing a new IS system state;

<figref idrefs="DRAWINGS">FIG. 3</figref> shows an exemplary “old” IS system state and corresponding representations thereof;

<figref idrefs="DRAWINGS">FIG. 4</figref> shows a method to establish the synchronization rules for a “planetary system” that is tracked by the synchronization system of <figref idrefs="DRAWINGS">FIG. 2</figref>;

<figref idrefs="DRAWINGS">FIG. 5</figref> shows a first exemplary “new” IS system state relative to the IS system state observed in <figref idrefs="DRAWINGS">FIG. 3</figref>;

<figref idrefs="DRAWINGS">FIG. 6</figref> shows a second exemplary “new” IS system state relative to the IS system state observed in <figref idrefs="DRAWINGS">FIG. 5</figref>;

<figref idrefs="DRAWINGS">FIG. 7</figref> shows an embodiment of a computing system.

DETAILED DESCRIPTION

If all that is available is the “new” state of the IS system, the specific changes that need to be made to the object-oriented model in order to bring it up to date with the new IS system state must therefore be derived from the new state of the system. Of particular concern, is if a “new” component appears in the “new” state information relative to the “old” state information. In this case, a determination needs to be made as to whether the new component is to replace an existing component; or, is to be added to the IS system.

<figref idrefs="DRAWINGS">FIG. 2</figref> shows a depiction of an architecture for deriving updates <b>205</b> to be made to an object oriented model <b>204</b> of an IS system from information that describes the new IS system state rather than the specific changes that were made to the old IS system state. The state of the IS system is essentially a characterization of the IS system's various components including specific software installations, specific hardware installations and the various associations that may exist between software installations, between hardware installations as well as between software and hardware installations. Ideally, an object representing each pertinent IS system component is maintained in the object-oriented model of the IS system <b>204</b> that reflects the IS system's most recent state prior to its change(s).

According to the depiction of <figref idrefs="DRAWINGS">FIG. 2</figref>, information describing a new IS system state <b>201</b> and “synchronization rules” <b>202</b> are presented to the synchronization system <b>200</b>. The information describing the new IS system state <b>201</b> describes, in some fashion, what the server “looks like” after the change(s) were made. The synchronization rules <b>202</b>, as described in more detail below, provide guidance to the synchronization system <b>200</b> on how to apply the new IS system state information <b>201</b> toward the manufacture of one or more updates <b>205</b> to be made to the old object oriented model <b>204</b>. The synchronization system <b>200</b> also receives information from the old object oriented model <b>204</b> as a baseline for comprehending the changes made to the IS system in light of the new IS system state information <b>201</b>.

The new IS system state <b>201</b> can be reflected with various data structures including text pages such as .XML pages. The old IS system state <b>203</b> that is received by the synchronization system <b>200</b> can literally be the objects associated with the present object oriented model <b>204</b>, or other information derived from the old object oriented model <b>204</b> such as text pages including .XML pages.

<figref idrefs="DRAWINGS">FIG. 3</figref> shows information pertaining to an example of an “old” IS system state. Firstly, inset <b>310</b>_<b>1</b> shows a “real world” depiction that is meant to convey the actual “old” state of an exemplary IS system. By contrast, inset <b>320</b>_<b>1</b> and inset <b>330</b>_<b>1</b> are meant to show different manners in which the real world state of inset <b>310</b>_<b>1</b> can be described so that automated systems management tools (including synchronization system <b>200</b> as described above) can perform automated management functions (e.g., configuration, maintenance, etc.). Specifically, inset <b>320</b>_<b>1</b> corresponds to a text page that has been written to reflect the real world state <b>310</b>_<b>1</b>; and, inset <b>330</b>_<b>1</b> corresponds to a collection of model objects in an object oriented environment organized through their various references to one another to reflect the real work state <b>310</b>_<b>1</b>.

The exemplary real world IS system <b>310</b>_<b>1</b> includes a dispatcher D<b>2</b> that distributes HTTP requests across four worker nodes WN<b>1</b>, WN<b>2</b>, WN<b>3</b>, WN<b>4</b>; and, three clients C<b>1</b>, C<b>2</b>, C<b>3</b> that are communicatively engaged with another dispatcher D<b>1</b>. Each worker node may include, for example, a virtual machine (VM), a web application container and an Enterprise Java Beans container. The text page representation <b>320</b>_<b>1</b> of the IS system describes the system by identifying pertinent components of the IS system according to a specific outline. Importantly, certain “planetary systems” (PS) within the IS system can be understood from the text page's outline.

Here, a planetary system is essentially a sub-system within the overall IS system where one or more IS system components (called “members”) that have a specific relationship with another IS system component (called a “root”). A first planetary system PS<b>1</b> is recorded in the text page <b>320</b>_<b>1</b> with respect to the dispatcher D<b>2</b> and the four worker nodes WN<b>1</b>, WN<b>2</b>, WN<b>3</b>, WN<b>4</b>. The first planetary system PS<b>1</b> identifies: 1) the “root” of the planetary system as the dispatcher of name D<b>2</b><b>323</b>; 2) each “member” of the planetary system (worker nodes WN<b>1</b>, WN<b>2</b>, WN<b>3</b> and WN<b>4</b>); and, 3) synchronization rules <b>321</b> (merge_roots_FALSE, merge_members_FALSE, merge_properties_TRUE) which as described further below give the synchronization system guidance on how to handle information describing a new IS system state as it pertains to components within planetary system PS<b>1</b>. In an embodiment, each member in a planetary system has a same set of properties. Thus, in the case of planetary system PS<b>1</b>, the set of properties for member WN<b>1</b> is the same as that found in the set of properties for members WN<b>2</b>, WN<b>3</b> and WN<b>4</b>, respectively. Note that property fields describing various properties of the planetary system's components are observed (e.g., property field <b>324</b> that describes properties of member WN<b>1</b> (e.g., the virtual machine version of WN<b>1</b>)).

For simplicity, associations A<b>1</b> through A<b>4</b> between members WN<b>1</b> through WN<b>4</b> and root member D<b>2</b> are observed in real world depiction <b>310</b>_<b>1</b> but not text page representation <b>320</b>_<b>1</b>. Generally, as will become evident further below, the use of the “merge” flags permit successful synchronization where associations are recorded in an IS system's “old” state information but not in an IS system's “new” state information. Thus, because, text page representation is being presented herein as an “old” system state representation, the A<b>1</b> through A<b>4</b> associations should be present but have not been drawn for illustrative simplicity.

A second planetary system PS<b>2</b> is recorded in the text page <b>320</b>_<b>1</b> with respect to the dispatcher D<b>1</b> and the three clients C<b>1</b>, C<b>2</b> and C<b>3</b>. The second planetary system PS<b>2</b> identifies: 1) the “root” of the planetary system as the dispatcher of name D<b>1</b>; 2) each “member” of the planetary system (clients C<b>1</b>, C<b>2</b> and C<b>3</b>); 3) synchronization rules <b>322</b> (merge_roots_TRUE, merge_members_TRUE, merge_properties_TRUE) which as described further below give the synchronization system guidance on how to handle information describing a new IS system as it pertains to planetary system PS<b>2</b>. Again, note that property fields describing various properties of the planetary system's components are observed (e.g., property field <b>325</b> for member pair WN<b>1</b>). Like planetary system PS<b>1</b>, the associations A<b>5</b> through A<b>7</b> of planetary system are not depicted in the text representation <b>320</b>_<b>1</b> but may be assumed to be recorded there.

Comparison of the text file description of the two planetary systems reveals that the PS<b>1</b> planetary system has its “merge_roots” and “merge_members” synchronization rules set to FALSE and planetary system PS<b>2</b> has its “merge_roots” and “merge_members” synchronization rules set to TRUE. <figref idrefs="DRAWINGS">FIG. 4</figref> reveals a basic methodology that demonstrates the differences between the TRUE and FALSE settings.

According to the methodology of <figref idrefs="DRAWINGS">FIG. 4</figref>, if a planetary system (or the presented new state information) is of such a character that it cannot entertain the addition of a new component <b>401</b> of a certain type, then, the appearance of a “new” component of that type in the planetary system's “new” state information is understood to be the replacement <b>402</b> for an existing component of that type in the planetary system (i.e., the new component replaces a component rather than merges with one or more existing components of the same type within the planetary system, hence the “merge” parameter is set to “FALSE”). Referring back to <figref idrefs="DRAWINGS">FIG. 2</figref>, the replacement of an “old” planetary system component with a “new” planetary system component corresponds to the update <b>205</b> that is made by the synchronization system <b>201</b> to the old state information <b>204</b>.

In the example set forth below, the PS<b>1</b> system is assumed to be a four CPU server that is configured to have only one worker node (WN) per CPU. Moreover, the server is configured to have only one dispatcher (D) that provides HTTP requests to its constituent worker nodes. According to this server architecture, planetary system PS<b>1</b> can only entertain a single dispatcher and a maximum of only four worker nodes. Thus, referring to the parameter settings <b>321</b> in the server state representation <b>320</b>_<b>1</b> of <figref idrefs="DRAWINGS">FIG. 3</figref>, the “merge_roots” parameter of the PS<b>1</b> planetary system is set to FALSE because the appearance of a “new” dispatcher in the new state information for the PS<b>1</b> planetary system must actually correspond to a replacement of the “old” dispatcher (because the server can only entertain a single dispatcher); and, for similar reasons, the “merge_members” parameter of the PS<b>1</b> system is set to FALSE because the introduction of a “new” worker node list in the new state information of the PS<b>1</b> planetary system must actually correspond to a replacement of the “old” worker node list because the server “knows them all”.

By contrast, if a planetary system (or the presented new state information) is of such a character that it can entertain the addition of a new component <b>401</b> of a certain type, then, the appearance of a “new” component of that type in the planetary system's “new” state information is understood to be an additional component of that type to be added <b>403</b> to the planetary system rather than a replacement <b>402</b> for an existing component of that type in the planetary system (i.e., the new component is added to the already pre-existing planetary system, hence the “merge” parameter is set to “TRUE”). Referring back to <figref idrefs="DRAWINGS">FIG. 2</figref>, the addition of a “new” planetary system component to an “old” planetary system corresponds to the update <b>205</b> that is made by the synchronization system <b>201</b> to the old state information <b>204</b>.

In the example set forth below, it is assumed that the PS<b>2</b> planetary system describes the relationship between multiple clients and one or more dispatchers within the IS system, respectively. Here, one or more clients may be added at any time to reflect the addition of a new customer of the IS system. Likewise, it is possible for any client to engage in a communicative session with more than one dispatcher. Hence, referring to the parameter settings <b>322</b> in the server state representation <b>320</b>_<b>1</b> of the PS<b>2</b> system in <figref idrefs="DRAWINGS">FIG. 3</figref>, the “merge_members” and “merge_roots” rules are both set to TRUE. That is, the appearance of a new client/member in the new system state information will simply be added to the PS<b>2</b> planetary system and the appearance of a new dispatcher/root will simply be added to the PS<b>2</b> planetary system.

In summary then, referring to <figref idrefs="DRAWINGS">FIG. 2</figref>, the synchronization rules <b>202</b> effectively tell the synchronization system <b>200</b> what type of update <b>205</b> should be manufactured in light of a detected difference between the old system state <b>203</b> and the new system state <b>201</b>. Here, according to one methodology, the synchronization system <b>200</b> operates as follows: 1) compare old system state information <b>203</b> with new system state information <b>201</b> to identify a difference that corresponds to a “new” component that appears in the new system state information <b>201</b> but not the old system state information <b>203</b>; 2) add the “new” component to the old state information <b>203</b>; 3) if the applicable merge parameter is FALSE: remove a component that appeared in the old state information <b>203</b> to effect its replacement with the new component found in the new state information <b>201</b>; or, if the applicable merge parameter is TRUE: perform no such removal to effect the pure addition of the new component to the old system state information <b>203</b>. The update <b>205</b> is applied to the object oriented model of the old state <b>204</b> accordingly.

<figref idrefs="DRAWINGS">FIGS. 5 through 6</figref> demonstrate examples based on the old system of <figref idrefs="DRAWINGS">FIG. 3</figref>. <figref idrefs="DRAWINGS">FIG. 5</figref> depicts at inset <b>510</b>_<b>1</b> a new system state that is to be compared to the old system state <b>310</b>_<b>1</b> of <figref idrefs="DRAWINGS">FIG. 3</figref>; and, depicts at inset <b>520</b>_<b>2</b> pertinent aspects of the corresponding new state information. Specifically note that, for simplicity, inset <b>520</b>_<b>2</b> only shows the specific differences that would be detected between the old state information and the new state information (i.e., the entire new state of the system depicted at inset <b>510</b>_<b>1</b> is not shown). According to inset, planetary system PS<b>1</b> is provided with four new worker nodes WN<b>11</b> through WN<b>41</b><b>526</b>; and, planetary system PS<b>2</b> is provided with a new client C<b>4</b><b>527</b>.

As described above, because the “merge_members” rules are set to FALSE for the PS<b>1</b> system and TRUE for the PS<b>2</b> system, the WN<b>11</b> through WN<b>41</b> worker nodes of <figref idrefs="DRAWINGS">FIG. 5</figref> would replace the WN<b>1</b> through WN<b>4</b> worker nodes of <figref idrefs="DRAWINGS">FIG. 3</figref>; while, the C<b>4</b> client of <figref idrefs="DRAWINGS">FIG. 5</figref> would be added to the C<b>1</b> through C<b>3</b> clients of planetary system of <figref idrefs="DRAWINGS">FIG. 3</figref>. The former may, for example, correspond to some kind of upgrade (e.g., a new virtual machine or application software suite); while, the later simply corresponds to another client that is using the IS system.

Here, note that a specific semantic is illustrated in which the old A<b>1</b> through A<b>4</b> associations to worker nodes W<b>1</b> through W<b>4</b> are effectively cut in place of new associations A<b>11</b> through A<b>41</b> to worker nodes W<b>11</b> through W<b>41</b>. Such a result could be established, for instance, if the synchronization system first adds new worker nodes W<b>11</b> through W<b>41</b> with corresponding new associations A<b>11</b> through A<b>41</b> before cutting worker nodes W<b>1</b> through W<b>4</b> and corresponding associations A<b>1</b> through A<b>4</b> from the PS<b>1</b> planetary system representation.

<figref idrefs="DRAWINGS">FIG. 6</figref> at inset <b>610</b>_<b>1</b> corresponds to the system state of <figref idrefs="DRAWINGS">FIG. 5</figref> after a new dispatcher D<b>3</b><b>628</b> is added to the PS<b>2</b> planetary system. Here, because the PS<b>2</b> system represents client/dispatcher relationships, its merge_roots rule is set to TRUE which effectively incorporates the D<b>3</b> dispatcher into the PS<b>2</b> planetary system without replacing dispatcher D<b>1</b>. Here, associations A<b>9</b> though A<b>12</b> are also added by the synchronization system along with the D<b>3</b> dispatcher to the PS<b>2</b> planetary system.

Also shown in <figref idrefs="DRAWINGS">FIG. 6</figref> is the introduction of a new dispatcher D<b>4</b><b>629</b> to the PS<b>1</b> planetary system. Here, because of the merge_roots parameter being set to false for the PS<b>1</b> system, the introduction of the D<b>4</b> dispatcher in the new system data is understood to be a replacement for the D<b>2</b> dispatcher. As such, the synchronization system will remove D<b>2</b> from the PS<b>1</b> planetary system, cut the A<b>11</b> through A<b>41</b> associations, add the D<b>4</b> dispatcher to the PS<b>1</b> planetary system, and introduce new associations A<b>12</b> through A<b>42</b>.

Note that the merge_properties rules may work in the same fashion as described above. That is, certain properties of a root and/or member(s) are kept in the old system state record (e.g., the “old” object oriented model); and, the presentation of the new state information includes “new” properties for the root and/or member(s). A setting of FALSE means the new property information replaces the old property information and a setting of TRUE means the new property information is merged with the old property information.

According to one implementation, referring back to <figref idrefs="DRAWINGS">FIG. 2</figref>, the synchronization system <b>200</b> includes at least one director and a network of builders. The builders are responsible for generating “output” corresponding to one or more of the updates <b>204</b> themselves and/or “input” that is used by one or more other builders. The director is responsible for directing terms and/or values from the new server state information <b>201</b> and from the old server state information <b>202</b> to the appropriate builders at the appropriate times such that an organized flow progresses from the old and new server states <b>201</b>, <b>202</b> to the actual updates <b>204</b> that need to be made.

According to a further embodiment, additional synchronization rules are applied to the synchronization system <b>200</b> that define what should be done with a root or member that has had an association to it cut. For any cut association to a root or member, a synchronization rule setting of ALL means that the root or member should be cut/removed as well even if the root or member is coupled to other associations after the cut association is cut; a synchronization rule setting of LONE means the root or member should be cut/removed only if the cut association is the only association to the root or member (i.e., the root or member is “alone” with no other associations after the cut association is cut); a synchronization rule setting of NONE means that the root or member is not cut/removed even if the cut association is the only association to the root or member (i.e., the root or member is allowed to exist without any associations to it).

Processes taught by the discussion above may be performed with program code such as machine-executable instructions which cause a machine (such as a “virtual machine”, a general-purpose processor disposed on a semiconductor chip or special-purpose processor disposed on a semiconductor chip) to perform certain functions. Alternatively, these functions may be performed by specific hardware components that contain hardwired logic for performing the functions, or by any combination of programmed computer components and custom hardware components.

An article of manufacture may be used to store program code. An article of manufacture that stores program code may be embodied as, but is not limited to, one or more memories (e.g., one or more flash memories, random access memories (static, dynamic or other)), optical disks, CD-ROMs, DVD ROMs, EPROMs, EEPROMs, magnetic or optical cards or other type of machine-readable media suitable for storing electronic instructions. Program code may also be downloaded from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a propagation medium (e.g., via a communication link (e.g., a network connection)).

<figref idrefs="DRAWINGS">FIG. 7</figref> is a block diagram of a computing system <b>700</b> that can execute program code stored by an article of manufacture. It is important to recognize that the computing system block diagram of <figref idrefs="DRAWINGS">FIG. 7</figref> is just one of various computing system architectures. The applicable article of manufacture may include one or more fixed components (such as a hard disk drive <b>702</b> or memory <b>705</b>) and/or various movable components such as a CD ROM <b>703</b>, a compact disc, a magnetic tape, etc. In order to execute the program code, typically instructions of the program code are loaded into the Random Access Memory (RAM) <b>705</b>; and, the processing core <b>706</b> then executes the instructions. The processing core may include one or more processors and a memory controller function. A virtual machine or “interpreter” (e.g., a Java Virtual Machine) may run on top of the processing core (architecturally speaking) in order to convert abstract code (e.g., Java bytecode) into instructions that are understandable to the specific processor(s) of the processing core <b>706</b>.

It is believed that processes taught by the discussion above can be practiced within various software environments such as, for example, object-oriented and non-object-oriented programming environments, Java based environments (such as a Java 2 Enterprise Edition (J2EE) environment or environments defined by other releases of the Java standard), or other environments (e.g., a .NET environment, a Windows/NT environment each provided by Microsoft Corporation).

In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.