Tracking and propagating updates to a message-driven system of interdependent components

[0002] 1. Field of the Invention

[0003] This invention relates in general to message driven systems, and in particular to track and propagate updates to a message driven system with interdependent components.

[0004] 2. Description of Related Art

[0005] In a message-driven system, the state of a component or object may depend on the state of several other components or objects. However, the state of a dependent component should not be changed until its corresponding access message is to be received, i.e., the update propagation needs to be delayed. Thus, there is a need in the art for a systematic way to track and propagate updates to dependent components in a message driven system.

[0006] To overcome the limitations in the prior art described above, and to overcome other limitations that will become apparent upon reading and understanding the present specification, the present invention discloses a method, apparatus, and article of manufacture for tracking and propagating updates in a message-driven computer program. In accordance with the present invention, a program in the memory of a computer receives a notification signal indicating that an event has occurred and transitions from a current state to a new state based on the notification signal, wherein the states are represented by discrete objects or components. The computer program propagates, to a second component subordinate to a first component representing the new state, a signal indicating the new state of the first component.

[0007] Referring now to the drawings in which like reference numbers represent corresponding parts throughout:

[0008] FIG. 1 is a block diagram illustrating an exemplary hardware environment used to implement the preferred embodiment of the invention;

[0009] FIG. 2 is a flow chart illustrating the steps performed in this invention;

[0010] FIG. 3 is a flow chart illustrating the steps performed in an alternative embodiment of the propagate state change step of this invention; and

[0011] FIG. 4 is a block diagram illustrating the internal structure of a system according to the present invention.

[0012] In the following description of the preferred embodiment, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration a specific embodiment in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention.

[0013] Overview

[0014] The present invention provides a method for tracking and delaying the update propagation in a relational network that mirrors the component relationship. The method requires no restriction on the component relationship, i.e., it could be a tree, graph, network, etc. A component may be a guardian, such that the state of other components depends on its state, a dependent, such that its state depends on the state of other components, or both. When an access message is received, the corresponding message handler of a component checks the updates based on the relationship with its dependency components. The message handler of the component applies the update and forwards its own updates to its dependent components.

[0015] Hardware Environment

[0016] FIG. 1 is a block diagram illustrating an exemplary hardware environment of the present invention. The present invention is typically implemented using a computer 100 comprised of a processor 102 and memory 104. It is envisioned that attached to the computer 100 may be a keyboard 106, display 108, and data storage devices 110a-c, such as fixed data storage devices 110a, removable data storage devices 110b, and media therefore 110c. The computer 100 operates under the control of an event manager 114.

[0017] The present invention is preferably implemented using an application program 112, an event manager 114, and a graphical user interface (GUI) 116. Generally, the application program 112, the event manager 114, and the graphical user interface program 116 are tangibly embodied in a computer-readable medium, e.g. one or more of the fixed and/or removable data storage devices 110a-band/or media 110c. The application program 112, the event manager 114, and the graphical user interface program 116 may be loaded from the data storage devices and media 110a-cinto the memory 104 of the computer 100. The application program 112, the event manager 114, and the graphical user interface program 116 all comprise instructions which, when read and executed by the computer 100, causes the computer 100 to perform the steps necessary to execute the steps or elements of the present invention.

[0018] Those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope of the present invention.

[0019] Update Tracking and Propagation

[0020] FIG. 2 is a flow chart illustrating the steps performed in this invention. Block 200 represents the computer 100 receiving an event notification signal. The event notification may be a user input from the GUI 116. Block 202 represents a first component in the application program 112 transitioning to a new state in the memory 104 of the computer 100 in response to receiving the notification signal. Block 204 represents the computer 100 propagating, from the first component to a second component, a notification signal indicating the new state of the first component, wherein the state of the second component is dependent on the state of the first component.

[0021] FIG. 3 is a flow chart illustrating the steps performed by the computer 100 in an alternative embodiment of the propagate state change step of this invention. Block 300 represents the computer 100 evaluating the state of a third component, wherein the first component is dependent on the state of the third component. Block 302 is a decision block that represents the computer 100 determining whether the state of the third component indicates that the first component should propagate its state change to its dependent components. If so, control transfers to Block 204 which represents the computer 100 propagating, from the first component to a second component, a notification signal indicating the new state of the first component; otherwise, control transfers to Block 304 which represents the computer 100 not propagating the state change of the first component to its dependent components.

[0022] FIG. 4 is a block diagram illustrating the internal structure of the application program 112 that interfaces to the event manager 114 and finally to a GUI 116 that displays information for an operator. In the application program 112, there may be a number of different states represented as components or objects represented in FIG. 3 as A, B, and C. In a particular instance of this example, the GUI 116 includes fields 400 and 402, respectively, for entering a user ID and password. These events trigger communication through the event manager 114 to the application program 112. Internally to the application program 112, the events are mapped into states within the application. For example, B may be a user ID state and C may be a password state.

[0023] Event driven systems are very different from non-event driven systems. For example, if component B in a non-event driven system was changed, then components that were dependent on B, such as component A, could be changed as well. In an event driven system, such actions can not take place because the operator is not expecting to be in that state yet, and thus component A cannot be changed except in response to the appropriate inputs from the operator. The components A, B, and C of the application program 112 illustrate a dependent relationship wherein component A is dependent on component B for the user ID and component C for the password, so that until the user ID and password have been entered by an operator, a transition to state A can not occur.

[0024] In this example, as soon as the user ID is entered component B sets its state to 1. Originally, components B and C both had a state of 0, as does component A. Later on, component C will also change its state to 1 when a password is entered by the operator. Component A is dependent on both component B and C and so when both components B and C change their state to 1, component A can also change its state to 1.

[0025] After component B sets its state to 1, component B propagates a message to component A indicating that component B's state is now 1. This message may set a flag in component A indicating that component B's state is now 1. A similar flag is set in component A when component C propagates a message to component A indicating that component C's state is now 1. Each dependent component of B receives a message from B indicating that B's state is now 1.

[0026] In an alternative embodiment, a dependent component provides a queue to store propagated messages. For example, at time t=0, the GUI 116 may provide a notification signal to component B within the application program 112 indicating that the userID has changed. Component B changes state from 0 to 1 and propagates a message to its dependent component A indicating its state has changed. At time t=1, the GUI 116 may provide a second notification signal to component B indicating that the userID has changed. If component A does not change state in response to the first notification signal until t=2, component B's flag will already be set to 1 when the second notification signal arrives, and thus the second notification signal will be ignored. The present invention provides a queue for storing subsequent messages to a dependent component indicating that the state of its guardian has changed. The dependent component can then process the messages according to the system requirements, such as FIFO or LIFO.

[0027] In another embodiment of the invention, the guardian component may not always propagate its state change to its dependent components. Since a component can be both a guardian and a dependent, a guardian component evaluates the states of its guardian components upon receiving a notification signal from the GUI 116 indicating that it should change state. Depending on the states of its guardians, the guardian may change state, but then delay propagating its state change to its dependent components.

[0028] Of course, the dependencies can be cyclical in that not only is component A dependent on the states of components B and C, for example, but component C could be dependent on the state of component A.

[0029] Conclusion

[0030] This concludes the description of the preferred embodiment of the invention. The following describe some alternative embodiments for accomplishing the present invention. The present invention may be implemented in any type of computer, such as a mainframe, minicomputer, or personal computer. Moreover, the present invention is not limited to a particular programming language, but extends to any method of implementing a message-driven system.

[0031] Furthermore, this invention requires no restriction on the component relationship. The relationship could include a tree, graph, or network.

[0032] In summary, the present invention discloses a method, apparatus, and article of manufacture for tracking and propagating state changes in a message-driven computer program. In accordance with the present invention, a program in the memory of a computer receives a notification signal indicating that an event has occurred and transitions a first component from a current state to a new state based on the notification signal, wherein the states are represented by discrete objects or components. The computer program propagates, to a second component subordinate to a first component representing the new state, a signal indicating the new state of the first component.