Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1997-11-18
2001-09-18
Amsbury, Wayne (Department: 2171)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000
Reexamination Certificate
active
06292803
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to the management of objects in a computer system, and in particular to the tracking of state change and history of objects.
BACKGROUND OF THE INVENTION
Databases contain information, commonly in a relational form that can be queried and presented to a user. Query languages were used to describe the data that was to be retrieved from a database, and also to describe how it was to be organized for viewing by a user.
Many new software applications, including databases, are written using object oriented languages. The use of object oriented languages generally results in the encapsulation of data in containers called objects, which contain data or code or a combination of both. The objects are related together in a hierarchy. The objects have a number of functions called methods that can be applied to them to manipulate the data within them or cause them to perform a function. Display objects are used to present information to a user, by receiving data from the database objects and processing it in a desired manner to provide a view of the data to a user.
In prior programs, display objects subscribed to receive change notifications from the database objects when data in the database object changed. Initially, the change notifications were very primitive, just indicating that a change had occurred. It was then up to the display object to actually generate a communication to ask the database object for the new information, or rerun the query.
Improvements to the change notifications removed the need for back and forth communications to obtain the data that changed. Newer object models include typed event services, which provide self contained update notices. Display objects, sometimes referred to as target objects are able to receive updates from source objects and immediately process the new data to update the display. In the case of a target display display object, that meant providing an updated display of the information, whether directly, or following some permutation into a desired format, such as a graphical representation.
The form of the updates is different than one would expect in prior programming environments. The updates are actually in the form of methods or functions that were applied to the source object to update the data as in the case of a database source object. Thus, the method “insert” would specify what datum to insert where in a table. The change notification then would specify the same method or an equivalent method to be applied to the target object. The target object would then perform the appropriate method or function to change its operation consistent with the change in the source object.
The use of applying equivalent methods to source and target objects works very well when there is consistency between the source and target object. When they both start in the same state, change notices work very well, as volumes of data need not be transferred or processed each time a change occurs in the source object. Only the changes need to be applied consistently to each object.
While the source and target objects have been described so far as a database and display objects, there are many different target objects in an application whose state is a function of another object or objects' states. The target objects are sometimes referred to as a view. These views allow users and applications to define their informational needs and to be notified of new or changed information that is relevant to their view of the data. The source objects may not only be databases, but other objects as well, including but not limited to objects representing live real-world entities.
One problem with the method of change notification is that new target objects or views need a way to become initialized in the correct state. The current methods of change notification provide no mechanism for this to occur. Further, there is no means of synchronizing the source and target object to ensure that they are applying changes to the same data.
Relational database management systems have implemented the concept of views for many years. Basically, a view is a derived subset of data referred to as a table. The contents of the table are defined by a query posed against other tables in the database. For example, a view can be defined as all records in a table for the month of July. Relational views were originally frozen in time. They represented that state of the database at a particular point in time. Whenever an application required the content of the view, it had to be completely recomputed from the underlying data. Techniques were developed to intercept incremental changes to the source tables and determine if they affected the content of the view. If they did, the incremental update was performed on the materialization of the view. This added significant complexity and consumed much system resource. Further, a relational database management system has trouble dealing with unstructured data such as maps, and cannot support incremental updates to the map or perform operations such as map cropping.
There is a need for a better way to track and update state changes to objects and the objects that depend on their states. There is a need to provide such a way for unstructured data, such as maps. There is a further need to synchronize related objects when one of the objects changes states and to ensure that they continue to remain synchronized. There is yet a further need to track the history of changes and to be able to traverse historical states of sets of objects. Still further, is a need to offer users flexibility in defining views which filter the massive amounts of information available into views of the data that provide them with only the information that they need.
SUMMARY OF THE INVENTION
A system of managing changes in state of interrelated objects provides for synchronization of change notifications transferred between source and target objects. In one embodiment, target objects subscribe to state changes in source objects and the change notifications are provided with unique state identifiers such as a system time stamp or an assigned number to provide a temporal dimension and allow synchronization of the notifications at the target object. The state changes are actually in the form of methods applied to the source, and equivalent or identical methods are then invoked on the target.
In a further embodiment, when a new target object is instantiated or becomes active, a complete history of change notifications is provided, and each of the notifications are applied to the target object to synchronize it with relevant source objects to which it is dependent upon. This essentially synchronizes the target object with the present states of the source objects.
Several services comprising methods are provided to enable the system of change notifications. A get_current_state method is invoked to bring a target object from an initial state to a current state of a source object. Subscribe and unsubscribe methods are used to manage if and when a target object is to be initialized and be updated periodically. History type methods are used to place an object in a state consistent with a desired time from a past or current state.
One embodiment of an application implementing this system of change notifications comprises a simulation of a military air encounter, having an animated map with moving icons showing enemy flights over a region of interest. A target object referred to as a view is defined by composing basic view functions. An animated map object is updated whenever an underlying continental map changes, aircraft positions are updated in a situation database object or the region of interest is changed by a user viewing the action on a display. Histories of the source object updates permit reconstruction of the map for any point in time and enables provision of new views without transferring entire states for each source object. Several different views are provided, each allowing different users to do their jobs. One view includes an ai
Agrawal Mukul B.
Richardson James P.
Amsbury Wayne
Honeywell International , Inc.
Shudy, Jr. John G.
LandOfFree
Object state change and history management mechanism does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Object state change and history management mechanism, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Object state change and history management mechanism will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2547576