Recording changes to a record while preserving the immutability of the record

Abstract

Aspects of the present invention disclose methods, computer program products, and systems for recording changes to a record while maintaining availability of the record. The method includes capturing, by one or more processors, changes to a record object. The changes include details of the record object to be changed and a change instruction for how the object is to be changed. The method further includes storing, by the one or more processors, the change object as a standalone object, along with the change instruction and metadata that points to the record object. The method further includes modifying, by the one or more processors, metadata of a previous version of the record object to include a pointer to the change object. The method further includes applying, by the one or more processors, the change instruction to the record object in responding to a retrieve or restore request for the record object.

Description

[Technical Field]

[0001] The present invention relates generally to the field of maintaining backup and archive records, and more particularly to recording changes to records while maintaining the immutability of the records. [Background technology]

[0002] Many regulatory systems require data to be stored in an immutable manner, i.e., to guarantee that no changes are made to data while it is stored. Storing data immutably is required not only by regulatory schemes but also by user demands for best practices (e.g., in industries such as financial services, telecommunications, and law). It is common to request that stored data be changed, deleted, or modified. Examples include the right to be forgotten and the right to rectify personal data under the General Data Protection Regulation (GDPR) in European Union law. Furthermore, data storage systems are required to guarantee that data committed to the system is the same when it is retrieved from the system. Summary of the Invention

[0003] Aspects of the present invention disclose a method, computer program product, and system for recording changes to a record while maintaining availability of the record. The method includes capturing, by one or more processors, changes to a record object. The changes include details of the record object to be changed and a modification instruction for how the object is to be changed. The method further includes storing, by the one or more processors, the modified object as a standalone object, along with the modification instruction and metadata pointing to the record object. The method further includes modifying, by the one or more processors, metadata of a previous version of the record object to include a pointer to the modified object. The method further includes applying, by the one or more processors, the modification instruction to the record object when responding to a request to retrieve or restore the record object.

[0004] The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed at the conclusion of this specification. The invention, both as to organization and method of operation, together with its objects, features and advantages, can best be understood by reference to the following detailed description taken in conjunction with the accompanying drawings.

[0005] For simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous features.

[0006] Embodiments of the present invention will now be described, by way of example only, with reference to the following drawings: [Brief explanation of the drawings]

[0007] [Figure 1] 1 is a flowchart of an exemplary embodiment of a method according to an embodiment of the present invention. [Figure 2]1 is a flowchart of an exemplary embodiment of an object commit flow as an aspect of a method according to an embodiment of the present invention. [Figure 3] 1 is a flowchart of an exemplary embodiment of an object modification flow as an aspect of a method according to an embodiment of the present invention. [Figure 4] 1 is a flowchart of an exemplary embodiment of an object retrieval or restore flow as an aspect of a method according to an embodiment of the present invention. [Figure 5] 1 is a flowchart of an exemplary embodiment of an object merge flow as an aspect of a method according to an embodiment of the present invention. [Figure 6] 1 is a schematic diagram of an exemplary embodiment of a data object illustrating one aspect of a method, according to an embodiment of the present invention. [Figure 7] 1 is a block diagram of an exemplary embodiment of a system according to an embodiment of the present invention. [Figure 8] FIG. 1 is a block diagram of one embodiment of a computer system or cloud server on which the present invention may be implemented, according to an embodiment of the present invention. [Figure 9] 1 is a schematic diagram of a cloud computing environment in which the present invention may be implemented, according to an embodiment of the present invention. [Figure 10] FIG. 2 is a diagram of an abstraction model layer of a cloud computing environment in which the present invention may be implemented, according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0008]

[0003] Embodiments of the present invention recognize that the requirement to store data immutably while allowing for modification can put archival or backup data storage systems in conflict with regulations. Data storage systems are required to ensure that data committed to the system is identical when retrieved from the system. Currently, such modifications are accomplished by either completely deleting stored data records or by creating notes of changes made to online or production systems and detailing the changes during restore and / or retrieval from backup or archival systems through a manual process. Embodiments of the present invention recognize that this process is subject to failure and provides little assurance that changes will be properly captured or preserved without accidental or intentional modification.

[0009] In traditional scenarios, changes to stored data are made by restoring the original committed data, making the changes, and re-backing / archiving it. However, embodiments of the present invention recognize that such a process breaks the chain of assurance that the object has not changed and is therefore not immutable because there is no guarantee as to exactly what changes have been made. Furthermore, storing modified objects separately along with existing objects not only significantly reduces storage efficiency but can also complicate the restore / retrieval process because it is very easy to select the wrong object. Furthermore, embodiments of the present invention recognize that it is not possible to apply changes to an existing version of an object without jeopardizing the integrity of the entire backup / archive system. This is because commercial implementations do not support this, and such processes must be implemented on an ad-hoc, bespoke basis or by manual processes, both of which are prone to failure.

[0010] Embodiments of the present invention operate to provide a method and system that allows for the modification of records, such as backup or archive records, without compromising the immutability of the data, and allows the changes to be captured individually within a storage repository along with a description of the reason for the change. Details of the changes to the record, or a set of interdependent changes, are stored and the changes are applied when the record is retrieved or restored. Further embodiments of the present invention can notify the user or system making the restore or retrieval request that there are changes available to apply.

[0011] Further embodiments of the present invention may provide the ability to record changes to an archive system and apply these changes to previous versions of objects stored in the archive. This means that object versions and dependencies of changes applied to objects can be tracked over time. Changes for regulatory compliance may be made and applied to objects stored before the changes were made. This allows data to be deleted / modified as required by law, without requiring application-specific handling.

[0012] Various aspects of embodiments of the present invention build on the immutability capabilities of existing archive and backup storage systems while operating within the system to enable changes to be captured individually along with a description of the reason for the change. Additionally, embodiments of the present invention (described in more detail below) return updated records while maintaining the immutability of objects, thereby enabling the return of compliant versions of stored data.

[0013] FIG. 1 is a flowchart 100 illustrating an exemplary embodiment of the method outlined herein. For illustrative purposes, the process illustrated in flowchart 100 (described in FIG. 1) may be implemented in one or more of the blocks and systems illustrated in the exemplary system (e.g., computer system 700) of FIG. 7. In an exemplary embodiment, the processing steps of flowchart 100 may be performed by one or more components of computer system 700, such as record monitoring system 710 (and its internal components). Alternatively, the implementation of flowchart 100 is not limited to this implementation. In various embodiments, the method of flowchart 100 is applied to record storage that preserves record objects that are not subject to change and maintains immutability.

[0014] The method of flowchart 100 captures changes to record objects in process 101, including details of the record objects being changed (step 102), change method instructions by which the record objects are changed (step 103), and a description of the reason for the changes (step 104). The method of flowchart 100 then modifies the metadata of all previous versions of the record objects identified by the captured changes to include information about the changes in step 105.

[0015] The method of flowchart 100 saves the change object in process 106 as a standalone object that includes instructions on how to make the change (step 107) and a description of the reason for the change (step 108). In a further aspect, the method of flowchart 100 can save the change object (in process 106) separately and immutably. In an exemplary embodiment, the information saved to represent the changes made is how the changes were made (e.g., Structured Query Language (SQL) statements, text substitutions, regular expressions (REGEX), etc.), rather than the results of the changes made (block storage deltas, database logs, etc.).

[0016] The method of flowchart 100 includes, at step 109, notifying a user making a data request for an object that one or more modifications are available to be applied when the object is retrieved or restored. The retrieve or restore process for a record object can then reference one or more modification objects associated with the record object, and the method of flowchart 100 can apply one or more modification instructions to the record object to effect the modifications as needed, at step 110. Depending on the configuration, the modifications can be forced, or both the record object and the modification objects can be restored separately or merged. In an exemplary embodiment, the modifications to be applied can be configured to be selected by the user or automatically applied by default.

[0017] Thus, the original object is saved unchanged, and later versions can be saved along with change objects that describe the changes applicable to the original and later versions of the object. In this way, the initial data is saved unchanged, and details of a single change or set of interdependent changes that need to be made at restore / retrieval are saved. Thus, changes can point to versions of the initial object before the changes were made, and to versions of the object on different software versions or hardware platforms.

[0018] Once captured, non-compliant data should not be able to be put back into online or production systems, while the integrity of that data is guaranteed throughout its retention period. This resolves the conflict between requiring data to be stored in an immutable form and requiring stored data to be able to be modified or deleted under certain regulatory regimes.

[0019] In various embodiments, no changes are made to the original record object until the record is restored and checked for integrity. Instead, the changes made are stored as a description of the process that made the changes, such as SQL statements, text search and replace strings, REGEX, etc., that are run on the restored database. Metadata describing why the changes were made is also stored along with the changes. Changes can point to versions of the stored object prior to the time the changes were made, and to versions of the object saved from different hardware or software instances on the source system.

[0020] Various aspects of the present invention may operate to support multiple different changes, which may be interdependent, to allow for multiple changes to a single object over time (i.e., multiple different saved versions of the object).

[0021] In an exemplary embodiment, the primary stored object is not subject to change, but changes can be made when the object is retrieved or restored, at which point the unmodified object can be retrieved and changes can be automatically applied to make the data compliant before being moved to a system that allows general access.

[0022] Three broad processes are described: committing an initial object, committing modifications to that object, and retrieving the object and merging the appropriate changes. Figure 2 is a flowchart 200 illustrating an example of a commit object flow. Figure 3 is a flowchart 300 illustrating an example of a modify object flow. Figure 4 is a flowchart 400 illustrating an example of a retrieve / restore object flow. Additionally, Figure 5 is a flowchart 500 of an object merge flow, which is a sub-process used in the retrieve / restore object flow flowchart 400.

[0023] 2 is a flowchart 200 illustrating an example of an object commit flow, according to an embodiment of the present invention. For illustrative purposes, the process illustrated in flowchart 200 (described in FIG. 2) may be implemented in one or more of the blocks and systems illustrated in the exemplary system (e.g., computer system 700) of FIG. 7. In an exemplary embodiment, the processing steps of flowchart 200 may be performed by one or more components of computer system 700, such as recording monitoring system 710 (and its internal components). Alternatively, the execution of flowchart 200 is not limited to this implementation.

[0024] The method of flowchart 200 first includes, in step 201, submitting a record object (e.g., a file) along with corresponding metadata to a data store (e.g., a database archive). In step 202, the method of flowchart 200 includes analyzing the submitted record object to generate information for verifying the immutability of the record object. For example, the analysis may generate a checksum for verifying whether the record object has been modified. In step 203 (as an optional step), the method of flowchart 200 may include creating redundancy information to ensure that the file is correctly stored. For example, creating redundancy information may include redundant array of inexpensive disks (RAID), erasure coding, deduplication information, or the like, if not created by the storage system.

[0025] At step 204, the method of flowchart 200 includes creating metadata for the recording object, where information for validating the metadata may be generated, and at step 205, the recording object and metadata may be committed to storage, which may be, for example, tape, disk, object, database, etc.

[0026] The method of flowchart 200 determines whether the commit was successful at decision step 206. If it is determined that the commit was successful (YES at decision step 206), the method of flowchart 200 includes returning retrieval information that includes a success report (step 207). If it is determined that the commit was not successful (NO at decision step 206), the method of flowchart 200 includes returning a failure report (step 208).

[0027] 3 is a flowchart 300 illustrating an example of an object modification flow, according to an embodiment of the present invention. For illustrative purposes, the process illustrated in flowchart 300 (described in FIG. 3) may be implemented in one or more of the blocks and systems illustrated in the exemplary system (e.g., computer system 700) of FIG. 7. In an exemplary embodiment, the processing steps of flowchart 300 may be performed by one or more components of computer system 700, such as recording monitoring system 710 (and its internal components). Alternatively, the execution of flowchart 300 is not limited to this implementation.

[0028] The method of flowchart 300 begins at step 301 by submitting details of a record object (e.g., a file) to be modified and the change data along with corresponding metadata. At step 302, the method of flowchart 300 includes creating a change object. In an exemplary embodiment, the change object includes change instructions (e.g., SQL statements, REGEX, etc.) for how the record object is to be changed and a description of the reason for the change. At step 303, the method of flowchart 300 may modify the record object metadata of all previous versions of the original record object to include information about the existing changes and point to the new change object.

[0029] At step 304, the method of flowchart 300 may include analyzing the submitted modified object to generate information for verifying the immutability of the modified object. For example, the analysis may generate a checksum for verifying whether the modified object has been modified. At step 305 (optional), the method of flowchart 300 may include creating redundant information to ensure that the modified object is saved successfully.

[0030] At step 306, the method of flowchart 300 may commit the changed object to storage. The method of flowchart 300 may then determine whether the commit was successful (decision step 307). If the commit was determined to be successful (YES at decision step 307), the method of flowchart 300 returns the acquired information along with a success report (step 308). If the commit was determined to be unsuccessful (NO at decision step 307), the method of flowchart 300 returns a failure report (step 309).

[0031] 4 is a flowchart 400 illustrating an example of a recording object acquisition flow according to an embodiment of the present invention. For illustrative purposes, the process illustrated in flowchart 400 (described in FIG. 4) may be implemented in one or more of the blocks and systems illustrated in the exemplary system (e.g., computer system 700) of FIG. 7. In an exemplary embodiment, the processing steps of flowchart 400 may be performed by one or more components of computer system 700, such as recording monitoring system 710 (and its internal components). Alternatively, the execution of flowchart 400 is not limited to this implementation.

[0032] The method of flowchart 400 first includes submitting a retrieval request (such as an API call to a file) to a data store for a record object at step 401. In a further aspect, embodiments of the present invention can perform an equivalent method for restoring a record object.

[0033] The method of flowchart 400 determines, at decision step 402, whether the record object being retrieved / restored has metadata indicating that changes exist. If it determines that the metadata indicates that changes exist (YES at decision step 402), the method of flowchart 400 may retrieve a list of all changes that point to the requested record object (step 403) and report the changes to an operator (step 404). At step 405, the method of flowchart 400 may prompt (via the operator) for the selection of a version of the record object to return. Next, at step 406, the method of flowchart 400 may identify all necessary changed objects and dependencies. If it determines that the metadata does not indicate changes (NO at decision step 402), the method of flowchart 400 retrieves the objects (the record object and any changed objects) and their respective metadata from the storage system (step 407). For example, the method of flowchart 400 may determine that no changes exist in the metadata or that the metadata indicates that changed objects have been identified.

[0034] At decision step 408, the method of flowchart 400 determines whether the object and metadata pass error detection. If it determines that the object and metadata do not pass error detection (NO at decision step 408), the method of flowchart 400 generates a warning / failure (step 409).

[0035] If it is determined that the error detection is successful (YES at decision step 408), the method of flowchart 400 determines whether the object is a single record object or whether the object contains one or more modifications to a record object (decision step 410). If it is determined that the object is a single record object ("Single" at decision step 410), the method of flowchart 400 returns the record object and metadata to the requestor (step 411) and provides a success report (step 412). On the other hand, if it is determined that the object contains modifications to a record object ("Modifications" at decision step 410), the method of flowchart 400 performs an object merge subprocess (step 413). In various embodiments, the object merge subprocess is performed as described in flowchart 500 of FIG. 5 to apply the modifications to the original record object.

[0036] At decision step 414, the method of flowchart 400 determines whether the merge was successful. If the merge was successful (decision step 414: YES), the method of flowchart 400 returns the resulting merged object and metadata to the requestor (step 411) and provides a success report (step 412). If the merge was not successful (decision step 414: NO), the method of flowchart 400 generates a warning / failure (step 409).

[0037] 5 is a flowchart 500 illustrating an example of an object merging sub-process (shown in step 413 above) according to an embodiment of the present invention. For illustrative purposes, the process illustrated in flowchart 500 (described in FIG. 5) may be implemented in one or more of the blocks and systems illustrated in the exemplary system (e.g., computer system 700) of FIG. 7. In an exemplary embodiment, the processing steps of flowchart 500 may be performed by one or more components of computer system 700, such as recording monitoring system 710 (and its internal components). Alternatively, the execution of flowchart 500 is not limited to this implementation.

[0038] The method of flowchart 500 begins by receiving a record object and one or more change objects and metadata to be merged at step 501. In another aspect, the method of flowchart 500 may begin by incrementing a processing loop (step 502).

[0039] At decision step 503, the method of flowchart 500 determines the type of the next change object to be merged. In an exemplary embodiment, text replacement, SQL, or other process types are considered. If it is determined to be a text replacement change ("Text Replacement" at decision step 503), the method of flowchart 500 performs the search and replace described in the change object on the record object (step 504). If it determines that the change is associated with an SQL statement, the method of flowchart 500 restores the current record object to the appropriate staging database server, mounts the database (step 507), and can then execute the SQL query and return the resulting database object (step 508). If it determines that the change is associated with another process, the method of flowchart 500 can apply another descriptive process, for example, apply REGEX to the flat file (step 509).5 ).

[0040] Next, at decision step 509, the method of flowchart 500 determines whether there are more changes available for merging the objects. If it determines that there are more changes (YES at decision step 509), the method of flowchart 500 may increment the processing loop (step 502). do not If so (NO at decision step 509), the method of flowchart 500 may return the resulting merged object (step 510).

[0041] 6 is a schematic diagram 600 illustrating an example of the method described herein. A plurality of record objects (e.g., record database (db) object version 1 (601), record db object version 2 (602), record db object version 3 (603), record db object version n (604), record db object version n+1 (605), record text object version 1 (611), record text object version 2 (606), record text object version 3 (607), record text object version 4 (608), record text object version 5 (609), record text object version 6 (611), record text object version 7 (612), record text object version 8 (613), record text object version 9 (614), record text object version 10 (615), record text object version 11 (616), record text object version 12 (617), record text object version 13 (618), record text object version 14 (619), record text object version 15 (620), record text object version 16 (621), record text object version 17 (622), record text object version 18 (623), record text object version 19 (624), record text object version 20 (625), record text object version 21 (626), record text object version 22 (627), record text object version 23 (628), record text object version 24 (629), record text object version 25 (630), record text object version 31 (631), record text object version 32 (632), record text object version 33 (633), record text object version 19 (634), record text object version 26 (635), record text object version 27 (636), record text object version 28 (637), record text object version 31 (638), record text object version 19 (639), record text object version 29 (640), record text object version 32 ( 2 (612), and other record objects version 1 (621)) are shown with their respective change objects, for example, change object 606, change object 607, change object 608, change object 613, and change object 622.

[0042] In the illustrated example, primary database record objects 601-605 are stored as versions 1 (601), 2 (602), 3 (603), N (604), and N+1 (605). Three change objects 606, 607, and 608 are stored. The first change object 606 is for an SQL query applied in version 3, the second change object 607 is for an SQL query applied in version n, and the third change object 608 is for an SQL query applied in version n.

[0043] Also shown is a primary text object with two versions 611, 612 and a linked modification object 613 that applies REGEX. Also shown is another primary object 621 and a linked modification object 622 for modifying information, for example by search and replace.

[0044] In various embodiments, a record object may have metadata that includes pointers to applicable change objects and pointers to other versions of the same record object. A change object may have metadata that includes pointers to dependent change objects and dependent record objects.

[0045] Dependent change objects are different versions of the same record object. For example, you might back up multiple different versions of the same record object to protect against deletion or corruption, or you might need to perform periodic archiving of the same record object for regulatory compliance. All different versions of a record file can have the same change object applied when restored.

[0046] Change objects can also point to other change objects, allowing for multiple different changes to be made to data over time, allowing the objects to be processed in order, and can also indicate whether a change object is standalone or dependent on other change objects.

[0047] In the example of Figure 6, the first change described in the first change object 606 makes a change in version 3 of the record object 603 and does not need to be applied to subsequent versions 604 and 605. The two change objects 607 and 608 applied in version n need to be applied to all previous versions of the record objects 601, 602, 603, and 604. Record object n+1 (605) is from a point in time after the other changes have been applied to the data source, so no changes need to be applied to this object when it is restored.

[0048] Thus, changes can be made after an object has been saved to an archive / backup system and linked to the previous version of that object that was saved. By recording when changes were made to the data source, the archive / backup system knows what changes need to be made.

[0049] Examples of object metadata for record and change objects are described below. Object Type: {Record|Modify} Object Data Types: Database (DB), Image / Backup, File System, Binary Large Object (BLOB), Text File, Flat File, Other; SQL Statement, Find and Replace Details, REGEX, Other Source data (application type, application version, file system details, OS, architecture, etc.) A checksum to ensure the object has not been modified. Recording Object: A pointer to the applicable change object; A pointer to another version of the same recording object (such as a backup / archive version). Change object: Pointers to the dependent change and record objects; Description of the change (free-form as requested by the user).

[0050] The object data for the record object and the change object is described below. Recording objects: DB image / backup, file system, BLOB, text file, flat file, etc.; Change objects: SQL statements, search and replace details, REGEX, and more.

[0051] A recording object may have the following: Object data: DB images / backups, file systems, BLOBs, text files, flat files, etc. Object Metadata: -Object data types: DB image / backup, file system, BLOB, text file, flat file, etc.; - Source data (application type, application version, file system details, OS, architecture, etc.); - checksums to ensure the object has not been modified; - a pointer to the applicable change object; -Pointers to other versions of the same recording object (e.g. backup / archive versions).

[0052] A change object may have the following: Object data: SQL statements, search and replace details, REGEX, and more. Object Metadata: - Object data types: SQL statements, search and replace details, REGEX, etc.; - Source data (application type, application version, file system details, OS, architecture, etc.); - checksums to ensure the object has not been modified; -Pointers to the dependent change and record objects; -Description of the change (free form as requested by the user).

[0053] The methods and systems described herein use change method instructions, such as SQL statements, to provide details of the changes to be made that are small enough to be applied without a large set of sequentially dependent data logs, allowing them to be stored efficiently and applied across different versions of database applications, architectures, or file systems.

[0054] This implementation differs from database transaction logs, which store binary diffs of changes made by transactions to the main database. Database transaction logs are used so that if a system failure occurs after a previous backup, the previous backup and subsequent logs can be used to restore to any point before the failure. Logs also help migrate database changes to a replicated server for high availability and disaster recovery reasons. Due to their binary nature, database logs can become very large if not regularly cleared.

[0055] Database transaction logs can only be replayed sequentially and cannot be applied to different instances of the same system, unlike the methods described herein, which allow a single change to be applied independently.

[0056] Similarly, the above-mentioned advantages of the methods described herein are not present in file system snapshots, which are loosely similar to database logs but are application independent. Generally, a snapshot is a point in time, described as a binary bitmap that represents changes made to the file system since the snapshot was taken. All changed data (blocks / tracks) is required to construct a valid snapshot image.

[0057] A codebase repository allows for a simple progression of changes over time in a manner roughly similar to a file system snapshot or database log. The key difference is that a series of development branches can be created in which independent changes can be fully developed before being merged back into the production version of the codebase for the product being developed. The system relies on files being submitted incrementally. Files are either saved in their entirety or represented by changes from one file to another, called "deltas." If files are saved in their entirety, the changes between each file are calculated at the time the files are compared.

[0058] Again, the primary difference between the method described herein and a code repository is that traditional methods store data that is the result of changes made, rather than the way those changes were made (e.g., REGEX, SQL statements, etc.). This not only means that storage efficiency is much less efficient, but also that the risk of data corruption is significantly higher if changes are applied out of sync or before the changes are made. Furthermore, embodiments of the present invention recognize that it is difficult to apply changes to saved versions of files / objects before those changes are made in production systems.

[0059] 7 is a block diagram illustrating an exemplary embodiment of a computer system 700 that provides a record modification system 710 for recording changes to record objects while maintaining the immutability of the objects, according to an embodiment of the present invention. The records may be provided to a storage system 720 that includes a record object 721 and a change object 722. Here, pointers are provided in the metadata of the record object 721 and the change object 722 that associate the change object 722 with the corresponding record object 721 and other change objects 722, while storing both the record object 721 and the change object 722 in an immutable form.

[0060] The computer system 700 includes at least one processor 701, circuitry for performing the functions of the described components, which may be hardware modules or software units running on at least one processor. Multiple processors may be provided that execute parallel processing threads, thereby enabling parallel processing of some or all of the functions of the components. The memory 702 may be configured to provide computer instructions 703 to the at least one processor 701 to perform the functions of the components.

[0061] The record modification system 710 includes a change capture component 711 for capturing changes to record objects, including details of the record objects being changed, instructions on how the objects are changed, and a description of the reasons for the changes.

[0062] The record modification system 710 can include a change saving component 712 for saving the change object as a standalone object that saves instructions on how to make the change, metadata pointing to the record object, and a description of the reason for the change.

[0063] The record modification system 710 can include a metadata modification component 713 that modifies the metadata of all previous versions of the record object to include a pointer to the change object.

[0064] The record modification system 710 can include a user notification component 714 for notifying a user requesting a record object that one or more modifications to the record object are available.

[0065] The record modification system 710 can include a record request component 715 for receiving a request for a record object and applying modification instructions for one or more modification objects pointed to by the record object. The record request component 715 can include a selection component 716 for accepting a user selection for one or more modification objects pointed to by the record object and a default component 717 for applying the one or more modification objects pointed to by the record object.

[0066] The record modification system 710 may include a change application component 724 for applying the modification method instructions to the record object when responding to a retrieve or restore request for the record object. The record modification system 710 may include an iteration component 718 for applying the one or more modification method instructions to the record object by iterating through applicable modification method instructions of the one or more change objects pointed to by the metadata of the record object.

[0067] The record modification system 710 can include an integrity component 719 for checking the integrity of the record object and the change object before applying the change object's modification method instructions to the record object.

[0068] The record modification system 710 may include a configuration component 723 for configuring enforced processing of record objects with changes (or changes independent of the object) to either apply the changes or return the unchanged object depending on the server-side configuration. This may be applied to server software and client software to return the unchanged object to an appropriately authorized operator, as appropriate.

[0069] Figure 8 is a block diagram of computing system components such as may be used in computer system 700 in accordance with one embodiment of the present invention. Note that Figure 8 is merely illustrative of one implementation and is not intended to imply any limitation with respect to the environments in which different embodiments may be implemented. Many modifications to the depicted environment are possible.

[0070] The computing system may include one or more processors 802, one or more computer-readable RAMs 804, one or more computer-readable ROMs 806, one or more computer-readable storage media 808, device drivers 812, read / write drives or interfaces 814, and network adapters or interfaces 816, all interconnected through a communications fabric 818. The communications fabric 818 may be implemented with any architecture designed to pass data and / or control information between processors (such as microprocessors, communications and network processors), system memory, peripherals, and other hardware components in the system.

[0071] One or more operating systems 810 and application programs 811, such as record modification system 710, are stored in one or more of the computer-readable storage media 808 for execution by one or more of the processors 802 via one or more of the respective RAMs 804 (which typically include cache memory). In the illustrated embodiment, each of the computer-readable storage media 808, according to an embodiment of the present invention, may be a magnetic disk storage device of an internal hard drive, a CD-ROM, a DVD, a memory stick, a magnetic tape, a magnetic disk, an optical disk, or a semiconductor storage device such as a RAM, a ROM, an EPROM, a flash memory, or any other computer-readable storage medium capable of storing computer programs and digital information.

[0072] The computing system may also include a R / W drive or interface 814 that reads from and writes to one or more portable computer-readable storage media 826. Application programs 811 on the computing system may be stored on one or more of the portable computer-readable storage media 826, read via the respective R / W drive or interface 814, and loaded into the respective computer-readable storage media 808.

[0073] The computing system may also include a network adapter or interface 816, such as a TCP / IP adapter card or a wireless communication adapter. Application programs 811 on the computing system may be downloaded to the computing device from an external computer or external storage device via a network (e.g., the Internet, a local area network, or other wide area network or wireless network) and the network adapter or interface 816. From the network adapter or interface 816, the programs may be loaded into the computer-readable storage medium 808. The network may include copper wire, fiber optic, wireless transmissions, routers, firewalls, switches, gateway computers, and edge servers.

[0074] The computing system may also include a display screen 820, a keyboard or keypad 822, and a computer mouse or touchpad 824. The device driver 812 interfaces with the display screen 820 for imaging, interfaces with the keyboard or keypad 822, interfaces with the computer mouse or touchpad 824, and / or interfaces with the display screen 820 for alphanumeric entry and pressure sensing of user selections. The device driver 812, the R / W drive or interface 814, and the network adapter or interface 816 may include hardware and software stored in the computer-readable storage medium 808 or in the ROM 806, or both.

[0075] The programs described herein are identified based on the application in which they are implemented in particular embodiments of the invention, although specific program names herein are used for convenience only and, therefore, the invention is not limited to use with the particular application identified and / or suggested by such names.

[0076] The present invention may be a system, method, or computer program product, or combination thereof, integrated at any possible level of technical detail. The computer program product may include a computer-readable storage medium having stored thereon computer-readable program instructions for causing a processor to carry out aspects of the present invention.

[0077] A computer-readable storage medium may be a tangible device that can hold and store instructions used by an instruction execution device. The computer-readable storage medium may be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or a suitable combination thereof. More specific examples of computer-readable storage media include portable computer diskettes, hard disks, RAM, ROM, EPROM (or flash memory), SRAM, CD-ROMs, DVDs, memory sticks, floppy disks, punch cards, or mechanically encoded devices having instructions recorded on ridge-in-groove structures, and the like, and suitable combinations thereof. As used herein, a computer-readable storage medium should not be construed as a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over a wire.

[0078] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing device / processing device. Alternatively, they can be downloaded to an external computer or external storage device via a network (e.g., the Internet, a LAN, a WAN, or a wireless network, or a combination thereof). The network can include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing device / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions to a computer-readable storage medium in the respective computing device / processing device for storage.

[0079] The computer-readable program instructions for carrying out the operations of the present invention can be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, and procedural programming languages ​​such as the "C" programming language and similar programming languages. The computer-readable program instructions can execute entirely on the user's computer as a stand-alone software package, partially on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a LAN or WAN, or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry, including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), can execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to customize the electronic circuitry for carrying out aspects of the present invention.

[0080] Aspects of the present invention are described herein with reference to flowchart and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. Each block of the flowchart and / or block diagrams, and combinations of blocks in the flowchart and / or block diagrams, can be implemented by computer-readable program instructions.

[0081] These computer-readable program instructions can be provided to a processor of a computer or other programmable data processing apparatus to produce a machine, whereby the instructions, executed by the processor of such computer or other programmable data processing apparatus, create means for performing the functions / acts identified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions can also be stored on a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner. The computer-readable storage medium having instructions stored thereon thereby constitutes an article of manufacture including instructions for performing aspects of the functions / acts identified in one or more blocks of the flowcharts and / or block diagrams.

[0082] Computer-readable program instructions may also be loaded into a computer, other programmable apparatus, or other device and a series of operational steps executed on the computer, other programmable apparatus, or other device to create a computer-implemented process, whereby the instructions executing on the computer, other programmable apparatus, or other device perform the functions / operations identified in one or more blocks in the flowcharts and / or block diagrams.

[0083] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for performing specific logical functions. In some implementations, the functions shown in the blocks may be performed in an order different from that shown in the figures. For example, depending on the functionality involved, two blocks shown in succession may actually be accomplished as a single step, may be executed simultaneously or substantially simultaneously, may be executed in a partially or fully overlapping manner, or the blocks may even be executed in reverse order. Note that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs specific functions or operations or executes a combination of dedicated hardware and computer instructions.

[0084] While various embodiments of the present invention have been described by way of example, they are not intended to be exhaustive or to be limited to the disclosed embodiments. As will be apparent to those skilled in the art, many modifications and variations are possible without departing from the scope of the present invention. The terms used herein have been selected to best explain the principles of the embodiments, their practical applications, or technical improvements over technologies recognized in the marketplace, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0085] <Cloud Computing> Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the teachings described herein is not limited to cloud computing environments. Rather, embodiments of the present invention may be practiced in conjunction with any other type of computing environment now known or later developed.

[0086] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a service provider. This cloud model includes at least five characteristics, at least three service models, and at least four deployment models.

[0087] The characteristics are as follows:

[0088] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time or network storage, automatically as needed, without the need for human interaction with the service provider.

[0089] Broad network access: Computing power is available over the network and can be accessed through standard mechanisms, facilitating use by heterogeneous thin or thick client platforms (e.g., cell phones, laptops, PDAs).

[0090] Resource Pooling: Computing resources from a provider are pooled and offered to multiple consumers using a multi-tenant model. Various physical and virtual resources are dynamically allocated and reallocated based on demand. Consumers generally have no control or knowledge of the exact location of the resources they are provided with, resulting in a sense of location independence. However, consumers may be able to determine location at a higher level of abstraction (e.g., country, state, data center).

[0091] Rapid Elasticity: Computing capacity can be provisioned quickly and elastically, sometimes automatically, to instantly scale out and quickly release to instantly scale in. To the consumer, the computing power available for provisioning often appears unlimited, and can be purchased at any time and in any quantity.

[0092] Service Metering: Cloud systems leverage metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, active user accounts) to automatically control and optimize resource usage. Resource usage can be monitored, controlled, and reported to provide transparency to both providers and consumers of utilized services.

[0093] The service model is as follows:

[0094] Software as a Service (SaaS): The functionality offered to the consumer is the availability of a provider's applications running on a cloud infrastructure that can be accessed from a variety of client devices through a thin client interface such as a web browser (e.g., webmail). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functionality, except for limited user-specific application configuration settings.

[0095] Platform as a Service (PaaS): The capability offered to consumers is to deploy applications they create or acquire using programming languages ​​and tools supported by the provider onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the configuration of their hosting environment.

[0096] Infrastructure as a Service (IaaS): The functionality offered to consumers is the provisioning of processors, storage, networking, and other basic computing resources on which they can deploy and run any software, including operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating system, storage, and deployed applications, and in some cases partial control over some network components (e.g., host firewalls).

[0097] The deployment model is as follows:

[0098] Private Cloud: This cloud infrastructure is dedicated to a specific organization and can be managed by that organization or a third party, and can exist on-premise or off-premise.

[0099] Community Cloud: This cloud infrastructure is shared by multiple organizations to support a specific community with common concerns (e.g., mission, security requirements, policies, and compliance). This cloud infrastructure can be managed by those organizations or a third party and can exist on-premises or off-premises.

[0100] Public cloud: This cloud infrastructure is available to the general public or large industry organizations and is owned by an organization that sells cloud services.

[0101] Hybrid cloud: This cloud infrastructure combines two or more cloud models (private, community, or public), each of which retains its inherent nuances but is bound by standards or specific technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0102] A cloud computing environment is a service-oriented environment that emphasizes statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0103] FIG. 9 illustrates an exemplary cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10, with which local computing devices used by cloud consumers (e.g., PDAs or cell phones 54A, desktop computers 54B, laptop computers 54C, or automobile computer systems 54N, or combinations thereof) can communicate. The nodes 10 can communicate with each other. The nodes 10 can be physically or virtually grouped (not shown) in one or more networks, such as the private, community, public, or hybrid clouds described above, or combinations thereof. This enables the cloud computing environment 50 to provide infrastructure, platform, or software as a service, or combinations thereof, for which cloud consumers are not required to maintain resources on their local computing devices. It should be understood that the types of computing devices 54A-N illustrated in FIG. 9 are merely exemplary, and that the computing nodes 10 and the cloud computing environment 50 can communicate with any type of electronic device via any type of network or network-addressable connection (e.g., using a web browser), or both.

[0104] A set of functional abstraction layers provided by the cloud computing environment 50 (FIG. 9) is now shown in FIG. 10. It should be understood in advance that the components, layers, and functions shown in FIG. 10 are merely exemplary, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0105] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe 61, reduced instruction set computer (RISC) architecture-based server 62, server 63, blade server 64, storage device 65, and network and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0106] The virtualization layer 70 provides an abstraction layer from which virtual entities such as virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75 can be provided.

[0107] By way of example, the management layer 80 may provide the following functionality: Resource provisioning 81 enables dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 82 enables cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. By way of example, these resources may include application software licenses. Security enables identification and verification of cloud consumers and tasks, as well as protection for data and other resources. User portal 83 provides consumers and system administrators with access to the cloud computing environment. Service level management 84 enables allocation and management of cloud computing resources so that requested service levels are met. Service level agreement (SLA) planning and fulfillment 85 enables advance arrangement and procurement of anticipated future cloud computing resources required in accordance with SLAs.

[0108] The workload layer 90 provides examples of functionality that can be leveraged in a cloud computing environment. Examples of workloads and functionality that can be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom instruction delivery 93, data analytics processing 94, transaction processing 95, and record object processing 96.

[0109] The computer program product of the present invention includes one or more computer-readable hardware storage devices having computer-readable program code stored thereon, the program code being executable by one or more processors to perform the methods of the present invention.

[0110] The computer system of the present invention comprises one or more processors, one or more memories, and one or more computer-readable hardware storage devices, the one or more hardware storage devices containing program code executable by the one or more processors via the one or more memories to implement the methods of the present invention.

[0111] While various embodiments of the present invention have been described by way of example, they are not intended to be exhaustive or limited to the disclosed embodiments. As will be apparent to those skilled in the art, many modifications and variations are possible without departing from the scope of the described embodiments. The terms used herein have been selected to best explain the principles, practical applications, or technical improvements to commercially recognized technologies of the embodiments, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0112] Improvements and modifications can be made to the foregoing without departing from the scope of the present invention.

Claims

1. capturing, by one or more processors, changes to a record object, the changes including details of the record object being changed and instructions on how the record object is to be changed; saving, by one or more processors, the modified object as a standalone object and saving the modification instructions and metadata pointing to the recording object; modifying, by one or more processors, metadata of a previous version of said recording object to include a pointer to said changed object; applying, by one or more processors, the modification method instructions to the recording object in response to a request to retrieve or restore the recording object; 11. A computer-implemented method comprising:

2. Capturing changes to the record object further includes capturing, by the one or more processors, a description of the reason for the change; The method of claim 1 , wherein saving the modified object as a standalone object further comprises saving, by one or more processors, the description within the modified object.

3. The method of claim 1 , further comprising checking, by one or more processors, the integrity of the record object and the change object before applying the change method instructions of the change object to the record object.

4. 1. A computer program comprising program instructions, the program instructions comprising: program instructions for capturing changes to a record object, the changes including details of the record object being changed and instructions on how the record object is to be changed; program instructions for saving the modified object as a standalone object and saving the modification instructions and metadata pointing to the recording object; program instructions for modifying metadata of a previous version of the recording object to include a pointer to the changed object; program instructions for applying the modification method instructions to the recording object in response to a request to retrieve or restore the recording object; a computer program comprising:

5. the program instructions for capturing changes to the record object further include program instructions for capturing a description of the reason for the change; 5. The computer program product of claim 4, wherein the program instructions for saving the modified object as a standalone object further comprise program instructions for saving the description within the modified object.

6. 5. The computer program of claim 4, further comprising program instructions for storing a set of interdependent change objects to accommodate multiple changes made to the record object over time, the interdependent change objects including metadata with pointers to dependent change objects.

7. receiving a request for a record object; applying one or more modification method instructions to the recording object by iterating through applicable modification method instructions of one or more modification objects indicated by metadata of the recording object; 5. The computer program of claim 4, further comprising program instructions for executing:

8. receiving a request for a record object; notifying the requesting user that one or more changes to the record object are available; and applying modification method instructions of one or more modification objects pointed to by said record object in accordance with a user selection; 5. The computer program of claim 4, further comprising program instructions for executing:

9. Receiving a request for a record object; forcing, by default, the modification method instructions of one or more modification objects pointed to by the metadata of said recording object; 5. The computer program of claim 4, further comprising program instructions for executing:

10. one or more processors; one or more computer-readable storage media; and program instructions stored on the computer-readable storage medium for execution by at least one of the one or more processors, the program instructions comprising: program instructions for capturing changes to a record object, the changes including details of the record object being changed and instructions on how the record object is to be changed; program instructions for saving the modified object as a standalone object and saving the modification instructions and metadata pointing to the recording object; program instructions for modifying metadata of a previous version of the recording object to include a pointer to the changed object; program instructions for applying the modification method instructions to the recording object in response to a request to retrieve or restore the recording object; 2. A computer system comprising:

11. the program instructions for capturing changes to the record object further include program instructions for capturing a description of the reason for the change; 11. The computer system of claim 10, wherein the program instructions for saving the modified object as a standalone object further comprise program instructions for saving the description within the modified object.

12. program instructions stored on the computer-readable storage medium for execution by at least one of the one or more processors, 11. The computer system of claim 10, further comprising program instructions for storing a set of interdependent change objects to accommodate multiple changes made to a record object over time, the interdependent change objects including metadata with pointers to dependent change objects.

13. program instructions stored on the computer-readable storage medium for execution by at least one of the one or more processors, receiving a request for a record object; applying one or more modification method instructions to the recording object by iterating through applicable modification method instructions of one or more modification objects indicated by metadata of the recording object; 11. The computer system of claim 10, further comprising program instructions for executing:

14. program instructions stored on the computer-readable storage medium for execution by at least one of the one or more processors, receiving a request for a record object; notifying the requesting user that one or more changes to the record object are available; and applying modification method instructions of one or more modification objects pointed to by said record object in accordance with a user selection; 11. The computer system of claim 10, further comprising program instructions for executing:

15. program instructions stored on the computer-readable storage medium for execution by at least one of the one or more processors, receiving a request for a record object; forcing, by default, the modification method instructions of one or more modification objects pointed to by the metadata of said recording object; 11. The computer system of claim 10, further comprising program instructions for executing:

16. The computer system of claim 10, further comprising configuring the one or more processors to process requests to access recorded objects or modified objects, and allowing an authorized operator to retrieve or restore unmodified recorded objects.

17. Program instructions stored on the computer-readable storage medium for execution by at least one of the one or more processors, comprising: further comprising program instructions for obtaining a record object for the recording, the program instructions for obtaining the record object for the recording comprising: requesting the recording object from storage; retrieving the record object from storage and reading metadata of the record object to identify changes to the record object; Retrieving one or more change objects from storage; applying one or more modification method instructions defined in the one or more modification objects to the record object; applying the one or more modification method instructions to the record object and returning the resulting object; 11. The computer system of claim 10, comprising program instructions for executing:

Images