Data processing control system

Abstract

The present invention relates to a computer-implemented method for data processing control. The method comprises: providing (102) at least one append-only storage (224, 322); providing (103) a framework (210); using (104) an application (226) to perform a change operation (206, 208) on an external object (202, 204, 304) generated by the application; creating (106) a Δ object (216, 218, 310) by the framework, the Δ object (216, 218, 310) indicating a property change of the external object generated by the application caused by the change operation; and sequentially storing (108) a sequence of data objects in the at least one append-only storage by the framework, the sequence of data objects being stored in the at least one append-only storage. The columns include a mixture of Δ objects (211, 212, 214, 310, 312, 404, 406) and RS objects (216, 218, 314, 316, 318, 320), each RS object being a data object that specifies requirements on how the framework must process and output attribute information of one or more application-generated external objects included in the Δ object; executing (110) one or more framework functions, which are used to return an output (230) calculated as a function of the attribute information in the Δ object, which output (230) conforms to the requirements specified in the RS object.

Description

Technical Field

[0001] The present invention relates to methods and systems for data processing and / or data access control in various application scenarios (such as the Internet of Things, smart homes, automated industrial workflows, and heterogeneous software environments), particularly methods and systems for data processing and / or data access control in application environments where data integrity, data consistency, and data security are very important. Background Art

[0002] Software-based systems are becoming increasingly important in almost all areas of life. Industrial production processes are highly automated. Special programs continuously monitor product quality, check whether the required raw materials and substances are in sufficient quantity and quality, and automatically ensure that replenishments are ordered or produced when necessary. Other programs ensure that the machines used in the production process meet safety standards, in order to prevent robots or automated transport systems from injuring people, or that pollutant emissions or noise pollution exceed limits, etc.

[0003] Especially when production is based on an "Internet of Things" approach, a large number of automated or semi-automated units work together in a complex, dynamic but coordinated manner. Raw materials, intermediate products and machines (and sometimes machine components and / or human users) exchange data and control commands with each other in a complex and dynamic manner, for example, to coordinate the manufacturing process in a way that takes into account a large number of requirements regarding quality, data integrity, data consistency, data or product security and / or process efficiency.

[0004] Another problem is that the data generated in heterogeneous IT infrastructures often include sensitive information. Measures to improve data security and data integrity often conflict with the flexibility and scalability of IT infrastructures.

[0005] Furthermore, in the private sector, heterogeneous systems based on hardware and / or software are increasingly used in areas such as smart homes, smart wearables, semi-autonomous driving and the use of various services such as medical services, banking and insurance services. Furthermore, a large number of requirements have to be met, for example with regard to the authenticity of the user and / or the protection of the transmitted and / or stored data. Furthermore, the data may include sensitive data that needs to be protected against unauthorized access and / or manipulation.

[0006] In all the above scenarios, components of the hardware- and / or software-based systems are provided by different organizations. Requirements regarding the safety of employees, regarding the authenticity of participants and / or regarding the security and confidentiality of transmitted, processed and stored data may be defined by other organizations, which are not always the same as those that provide the corresponding system components. Especially in the field of security control or data security control, it is actually necessary to perform the control functions by organizations other than the organization responsible for executing the action to be controlled.

[0007] The large number of organizations involved and the associated heterogeneity of the software and / or hardware components of the system components involved pose significant problems for the reliability, consistency, integrity and security of the complex and heterogeneous data processing workflows implemented in these systems. The goal of making a large number of system components interoperate with each other while taking into account various safety-related and other requirements means that, in the prior art, the corresponding heterogeneous, complex systems can be difficult to maintain or even expand after a relatively short operating period. Due to the large number of interfaces and functional dependencies between the individual system components, at a certain point it will no longer be possible to perform small adjustments with respect to functionality and / or with respect to one or more requirements without having to adjust a large number of related system components. At a certain level of complexity, even the interdependencies between the system operators are no longer known, and changes in requirements and / or changes in functionality of the individual components quickly lead to the operating mode of the system eventually no longer meeting the respective requirements, without this even being noticed. Errors occasionally occur, and as the complexity of the system increases, it becomes increasingly impossible to assign errors to specific system components. Typically, after a few years at the latest, a state is reached where a constant adaptation of the system to new requirements is technically impossible or at least no longer economically justifiable. This problem is exacerbated in application scenarios where requirements change frequently, since any formulation of new requirements and any modification of existing requirements carries the risk that one or more system modules may come under oversight that at least occasionally have an impact on whether the requirements are met.

[0008] Today, the logical consistency and compliance of software programs with requirements is usually enforced by various testing procedures prior to delivery. However, it is usually impossible to predict all possible user inputs in order to completely exclude errors. In the case of heterogeneous software systems with different components and combinations of requirements that cannot usually be foreseen in advance and may change unpredictably over time, it is impossible to guarantee, based solely on preliminary tests of the expected life of the system components, that it will meet all requirements that may only be known in the future and must be met. For example, maximum permissible limits for contamination and / or regulations regarding the transmission and storage of sensitive data that are considered secure change over time, and there are usually different rules in different countries or in different application scenarios.

[0009] Therefore, there is a need for technical solutions that allow flexible control and adjustment of complex computer-implemented data processing tasks which also ensure data integrity and data security. Summary of the invention

[0010] The object of the invention is to provide an improved computer-implemented method and system for providing data processing control as specified in the independent claims. Embodiments of the invention are given in the dependent claims. If the embodiments of the invention are not mutually exclusive, they can be freely combined with each other.

[0011] In one aspect, the present invention relates to a computer-implemented method for data processing control. The method comprises:

[0012] Provide at least one append-only store;

[0013] Providing a framework; in particular, the framework may be software, such as a software program or a software module;

[0014] performing, using the application at runtime of the application, change operations on application-generated external objects, each application-generated external object being a data object instantiated within the application, the change operations comprising creating, modifying and / or deleting one or more application-generated external objects in the application, the application being configured to notify the framework of any change operation;

[0015] In response to any one of the change operations, automatically creating a delta object indicating a change in a property of at least one of the external objects generated by the application caused by the change operation, wherein the delta object is created by the framework;

[0016] sequentially storing, by the framework, a sequence of data objects in at least one append-only storage, the sequence of data objects comprising a mixture of Δ objects and RS objects, each RS object being a data object that specifies requirements regarding how the framework must process and output attribute information of one or more application-generated external objects included in the Δ objects, wherein the framework comprises a set of framework functions, wherein one or more of the framework functions are functional extensions of the application programs and are configured to, when called, process the attribute information included in the one or more Δ objects according to the requirements stored in the RS objects;

[0017] One or more skeleton functions are executed to return output computed as a function of the attribute information in the Δ object that conforms to the requirements specified in the RS object.

[0018] Embodiments of the present invention may have the following advantages: a general, flexible and highly scalable method for processing and storing application data may be provided, so that the data stored and / or processed meet the needs of flexible changes: a framework is a software program including one or more framework functions, which are functional extensions of an application or multiple applications, which are configured to solve the same or different computing tasks. This means that some functions of an application (or multiple applications) are implemented in the application, and other functions as functional extensions of the application functions are implemented in the framework. The framework is instantiated independently of one or more applications. The framework not only acts as a functional extension of one or more applications. The framework is also configured to store data changes caused by data change operations performed in the runtime environment of the application and by change operations performed by framework functions in the runtime environment of the framework in the same data storage in the same data format (Δ object). Therefore, the framework acts as a functional extension of one or more applications, and in addition acts as a persistence layer for storing functionally related data changes, regardless of whether these data changes are performed in the framework or in the application. Delta objects stored in append-only storage can provide a history of all data changes performed over a given period of time on external objects related to a specific function or entity (e.g., a natural or legal person, a machine, a vehicle, etc.). This history of change operations can be used as the basis for many different downstream data processing operations, such as reconstructing the state of applications and frameworks at a specific time, generating reports, performing statistical analysis, exporting selected parts of external objects, etc.

[0019] According to an embodiment, the method for data processing control is a method for providing a tamper-proof archive of dynamic state changes of application programs and external objects generated by the application. At least one append-only storage is used as a tamper-proof archive.

[0020] According to an embodiment, the tamper-proof archive is used as the data basis for reports generated by the framework.

[0021] Thus, according to an embodiment, append-only Δ objects in storage may provide a common data base that may be accessed by other applications (preferably only via the framework) that are components of a heterogeneous, complex, multi-module hardware and / or software based system. In case an application should lack some functionality that is considered necessary to meet a specific requirement, the required functionality may be easily implemented as part of the framework. This may have the advantage that the framework functions may also be used by other applications that have the same deficiency in terms of requirements as functional extensions of their own functionality.

[0022] Embodiments of the present invention may also have the following advantages: the append-only storage includes a mixture of Δ objects and RS objects, the RS objects specifying requirements for how the Δ objects stored in at least one append-only storage must be accessed and processed. Thus, the framework may include framework functions that are functional extensions of the functionality of an application (or multiple different applications) that may be used to process payload data at runtime of the application and / or framework functions for accessing and processing Δ objects already stored in the append-only storage. For example, the framework function may be used to export patient-related medical data such that the identity of the patient is not revealed. The framework function may act as a functional extension of the patient management software application by providing a "data export" function to an application (e.g., a medical patient management software application), whereby the data export function complies with one or more requirements specified in the corresponding RS object, such as data privacy requirements. The framework function (e.g., a data export function such as a "privacy-compliant data export" function) may be reused by one or more other applications. For example, a hospital using the framework as a functional extension of a patient management program may use the framework and the "data export function" in addition to being a functional extension of another application for controlling incoming and outgoing payments for patients. For example, a framework "data export" function may allow exporting a history of all payments received from all patients over a specific time interval without revealing the patient's identity to the recipient or reporting (e.g., tax authorities or tax inspectors).

[0023] Embodiments of the present invention may also have the following advantages: Append-only storage is a memory suitable for sequentially reading and writing data very quickly. Since append-only storage does not allow modification of existing data records, time and storage are consumed to process and measure to ensure that individual stored data records do not have to be modified later. Since data changes performed within the application and data changes performed on various external objects within the framework are stored in the same type of data object (i.e., Δ object), embodiments of the present invention may allow append-only storage to be provided as a kind of functional extension "overlay interface" to other applications (preferably only via the framework), which "overlay interface" allows any other application to use the Δ object, which is the result of the combined action of the application's functions and the functional extension of the application provided by the framework.

[0024] Embodiments of the present invention may also have the following advantages: the append-only storage includes not only "payload data" in the form of a Δ object, but the append-only storage also includes an RS object that defines how the data included in the Δ object must be processed. Preferably, only frameworks or one or more specific applications that are considered to be highly trusted are allowed to access, process and output data stored in the append-only storage.

[0025] According to an embodiment, the RS object is created by the framework in response to a request by a client application to create the RS object, whereby the framework is configured to receive one or more requirement specification requests from one or more clients, for example, during runtime of the application. The RS object is created independently of and / or asynchronously with the creation of the Δ object by the framework. According to an embodiment, the RS object is stored in the context of an integration transaction along with one or more Δ objects.

[0026] According to an embodiment, the sequence of data objects includes a mixture of Δ objects and access control objects (AC objects instead of RS objects). According to other embodiments, the sequence of data objects includes a mixture of Δ objects, RS objects, and access control objects (AC objects). Each AC object is a data object that specifies that the framework allows or denies a user access to a Δ object, and the Δ object includes change information for a specific external object among the external objects generated by the application. The method also includes:

[0027] Receiving, by the framework, a user's request to access property information of at least one external object generated by an application; and

[0028] In response to receiving the request, traversing, by the framework, at least one append-only store to process an AC object, the AC object comprising access control data regarding at least one application-generated external object; and

[0029] granting or denying, by the framework, user access to attribute information included in a Δ object of at least one application-generated external object based on access control data in the processed AC object; or

[0030] A report is outputted by the framework to a user, the report selectively including attribute information included in the delta object of at least one application-generated external object that can be disclosed according to the access control data in the processed AC object.

[0031] Embodiments of the present invention that include a mix of data objects including AC objects can be used for data access control, for example, for controlling which user or user group should be allowed to access selected attributes and attribute change information of selected external objects. By integrating AC objects into at least one append-only storage, a data archive is provided that essentially specifies which parts of the data in the archive are disclosed to which user or user group under what conditions. For example, the framework can selectively convert those parts of the archive (change information of selected attributes of selected external objects) that are allowed to be disclosed to specific users into a report or data output format that conforms to the data output requirements specified in the RS object in the append-only storage based on the AC object in the at least one append-only storage.

[0032] For example, the steps of granting or denying access and / or outputting a report may include a second traversal of at least one append-only storage, thereby processing attribute information included in the Δ object based on information specified in the RS and / or AC objects obtained during at least a first traversal of the append-only storage and making the attribute information accessible to the user.

[0033] This can have the following advantages: the Δ objects and the data objects that control access to the Δ objects by one or more users and the data objects that control how the data is processed are all stored in the same append-only storage. This means that by transferring the contents of the append-only storage to a new location (e.g. a new, faster server computer), not only the payload data (Δ objects) is provided, but also complete access and processing control is provided. This greatly simplifies maintenance and improves security because the payload data and the processing and / or access control data form a monolithic data unit that cannot be separated from each other and can be quickly accessed by performing one or two sequential scans. Preferably, the append-only storage is based on a sequence of adjacent data storage blocks, so the read / write head of the storage device can obtain all RS objects and / or AC objects in a first sequential scan, which specify how to process the Δ objects and who is allowed to process the Δ objects, and then can sequentially obtain and process all Δ objects in at least one second scan of the append-only storage. Speed ​​can be improved by storing all Δ objects, RS objects and AC objects of attribute information about external objects generated by different applications in a separate append-only storage.

[0034] This means that an embodiment of the present invention provides a specific and fast way to process attribute data related to data objects generated by a specific application (e.g., business objects representing machines, vehicles, legal persons or natural persons, etc.): all Δ objects, RS objects and / or AS objects related to the attribute information of the first vehicle instance V1 are stored in a first append-only storage, and all Δ objects, RS objects and / or AS objects related to the attribute information of the second vehicle instance V2 are stored in a separate append-only storage. Therefore, in order to determine whether a specific user should be allowed to access the attribute information of vehicle 2, and to determine whether some attribute information of vehicle 2 needs to be anonymized, pseudonymized or otherwise hidden from the user requesting access, the framework does not have to scan or access the first append-only storage. All attribute information as well as access control data and / or requirement information on how to process the attribute data are included in the second append-only storage. In response to receiving a request for some data related to vehicle 2, the framework will selectively scan the data content of the second append-only storage representing vehicle 2, rather than any of the other append-only storages representing external objects generated by other applications or external objects generated by the framework. Thus, substantially all information derived from one or more linear scans of the second append-only store will be relevant to processing the request regarding vehicle 2, and the time to compute a response will be very short, even in the event that the application should have instantiated millions of different application-generated external objects.

[0035] It should be further noted that, in contrast to prior art methods of storing application payload data in a relational database, according to embodiments of the present invention, there is no need to perform table joins or other complex data operations that consume large amounts of memory or CPU capacity during joins. Instead, since the framework is configured to create and manage multiple append-only stores that represent one of the application-generated or framework-generated external objects, respectively, the framework will find all relevant attribute information and access control and / or data processing requirement information in a single coherent data store that does not include data that is not relevant to the object of interest.

[0036] According to an embodiment, the RS object comprises an indication of how to process attribute values ​​of one or more attributes of a specific external object, whereby the indication is specified on a per-attribute level.

[0037] According to an embodiment, the RS object comprises an indication of which users or user groups should be allowed or denied access to attribute values ​​of one or more attributes of a specific external object, whereby the indication is specified on a per-attribute level and on a per-user or user group level.

[0038] This may be beneficial for highly flexible, fine-grained control over how data generated by an application is processed (e.g., generating reports) and which data is provided to which user.

[0039] According to an embodiment, the framework stores data objects including:

[0040] identifying, by the framework, for each Δ object to be stored, one of the application-generated external objects whose attribute change information is included in the Δ object; and / or

[0041] Identifying, by the framework, for each RS object to be stored, its attribute information, processing one of the external objects generated by the application controlled by the RS object; and / or

[0042] Accessing, by the framework, one of the external objects generated by the application controlled by the AC object for each AC object to be stored to identify its attribute information;

[0043] For example, when the framework creates a Δ object in response to notification of a property change event in an application or an external object change event, or when the framework creates a new RS object and / or a new AC object in response to receiving a specification of an RS object or an AC object from a user via a GUI, the framework will identify the object ID of the application-generated external object or the framework-generated external object that is changed or whose access control and / or processing will be affected by the AC object or RS object.

[0044] The method further includes:

[0045] selectively identifying, by the framework, for the identified application-generated external object, an encryption key, the encryption key being specifically assigned to the application-generated external object; and

[0046] The identified Δ object, RS object and / or AC object is encrypted using the identified encryption key, wherein the Δ object, RS object and / or AC object is stored in encrypted form in at least one append-only storage.

[0047] For example, in the case where a new application-generated external object representing a patient P2 is created in the application, the framework will not only create a Δ object indicating the instantiation / creation of the new application-generated external object P2, but the framework will also create an encryption key pair, such as a symmetric encryption key or key pair. The framework stores these encryption keys in a secure space. For example, the framework can use the framework's internal master key to encrypt all keys created for external objects. Then, various attributes of the patient P2, such as address, current symptoms, diagnosis and / or medication, etc., can be set in the application. The framework will automatically create Δ objects reflecting these changes. All Δ objects reflecting the creation, change and / or deletion of the patient data object P2 include the object ID of the patient P2. The framework can automatically create some default RS objects that specify some default data processing routines, such as that diagnoses and symptoms should be output based on the accounting code of a specific insurance company, or should be clustered based on a specific medical clustering algorithm, and / or some default AS objects can be created that specify that doctors can access all patient information, while administrators can only access payment-related data for patients. Before storing the Δ objects, RS objects and / or AC objects related to patient P2 in the (preferably P2-specific) append-only storage, these objects are encrypted using a P2-specific encryption key (a private key in case of asymmetric encryption).

[0048] This may have the advantage that in the event of any key being lost or stolen, only the data of a single entity (e.g., patient P2) may be accessed. Data of other entities represented by application-generated external objects or framework-generated external objects are not affected. Thus, a particularly fine-grained and secure way of storing data, controlling the manner in which that data is reported, and / or controlling who is allowed to access that data is provided.

[0049] According to an embodiment, a framework is a software program operably coupled to an application. When a new application-generated external object is instantiated in the application, the application sends a notification of the new application-generated external object to the framework. The notification includes the object ID of the instantiated application-generated external object. In response to receiving the notification, the framework automatically creates a symmetric or asymmetric encryption key pair. The key pair is specific to the application-generated external object whose object ID is indicated in the notification. The framework stores the encryption key pair associated with the object ID of the application-generated external object.

[0050] Preferably, the storage is implemented so that the framework, but not other software programs or users, can access the key for decrypting the at least one data object in the append-only storage. For example, the framework can be configured to create and manage encryption keys for multiple different application-generated external objects of one or more applications. The encryption keys for the external objects generated by the different applications can optionally be encrypted with the framework's master key.

[0051] According to some embodiments, the framework includes a registry of multiple users, whereby a user may be a natural or legal person, a software program, or any other entity that may be implemented as a digital identity.

[0052] The framework may optionally include a configuration where some default access permissions for some registered users or user groups may be specified.

[0053] The framework is configured to, upon receiving a data access request from a particular user regarding an external object generated by an application of interest, evaluate to identify the encryption key stored in association with the object ID of the external object of interest generated by the application, and decrypt all Δ objects, RS objects, and / or AC objects (if any) that include the same object ID (and preferably stored in the same one of multiple different append-only stores). The framework analyzes the AC object to determine whether the user should be allowed to access information related to the external object of interest. For example, the AC object can specify which user should be allowed to access attribute information of the external object of interest. The AC object can also specify additional conditions regarding the time when user access rights should be granted, regarding attributes that should be accessible to the user and should be hidden, and regarding the time during the "lifetime" of the external object of interest that should be disclosed to the user submitting the request. The framework will only decrypt those Δ objects and disclose their contents to the user, which can be disclosed based on the AC object.

[0054] According to an embodiment, in addition to or in lieu of receiving a request, the framework may include a scheduler for automatically generating one or more reports for one or more different users. The scheduler will trigger the above-mentioned identification of one or more external objects related to the report to be generated, the identification of the encryption key associated with the one or more identified external objects, the decryption of the Δ object, AC object and / or RS object with the same object ID as the one or more identified external objects, and the report generation performed by the framework. In order to generate a report, the framework will analyze the AC object to determine which users are allowed to receive the report, determine which attributes of the external object of interest should be reported, and / or determine the time period covered by the report. When generating a report, the framework uses the control information stored in the RS object to process the information included in the decrypted Δ object to meet some requirements. For example, the RS object can indicate a specific clustering algorithm to be used when generating a report.

[0055] According to an embodiment, the framework is configured to store the sequence of data objects as at least one blockchain. Each Δ object and each RS object and / or AC object represents a block. The method further comprises:

[0056] by the framework, upon accessing any block in append-only storage, checking whether the cryptographic hash of that block is included in a subsequent block in the blockchain;

[0057] If the cryptographic hash is included in a subsequent block, processing the accessed block; and

[0058] Otherwise, an alarm is output and / or the processing of the accessed block is terminated.

[0059] Embodiments of the present invention using the above-described blockchain technology may be highly advantageous for a number of reasons: The integrity of data stored in at least one append-only storage is guaranteed. Blockchain technology ensures that in the event that any unauthorized person should manipulate a block, the cryptographic hash of the manipulated block will no longer be the same as the cryptographic hash of the original version of the block included in subsequent blocks.

[0060] In a further beneficial aspect, embodiments of the present invention allow the use of blockchain technology in the context of applications that include a large number of dynamically changing data objects (e.g., business object class instances that are dynamically instantiated in unpredictable ways and whose properties change over time). Existing blockchain applications require each block to represent a complete semantic unit or a complete transaction, and therefore are generally unable to cope with the dynamic and complex nature of data object instantiation and modification that occurs during the lifecycle of application-generated data objects. In contrast, embodiments of the present invention allow the use of blockchain technology not only for a limited set of predefined (database) transactions, but also for providing a tamper-proof archive of dynamic state changes of applications and external objects generated by the applications.

[0061] In a further beneficial aspect, the use of blockchain technology as described above ensures not only the integrity of the payload data, but also the integrity of the access control and data processing control instructions associated with the payload data: since the AC object and the RS object (if any) having the same object ID of the same external object belong to the same blockchain, it is impossible to separate the payload data from the RS object or AC object that specifies how to process the payload data and / or how to make the payload data available to various users. Thus, embodiments of the present invention allow the operator of an application to provide payload data generated by that particular application to a receiving entity in a manner that guarantees that the payload data, as well as the intact access control and data processing / reporting routines, cannot be manipulated without being noticed. For example, if one of a plurality of append-only stores including Δ objects, RS objects, and / or AC objects related to external objects generated by a particular application is stored in the form of a blockchain, wherein each Δ object, RS object, and / or AC object is a block interconnected to its subsequent block via a cryptographic hash, wherein optionally each block is encrypted with the same external object-specific encryption key, the receiving entity cannot manipulate the AC object and / or RS object to obtain more information than the receiving entity is entitled to see: the framework is configured to check whether any of the blocks has been manipulated after decryption of the blocks of the blockchain (if the blocks are provided in encrypted form) and before allowing a user to access information included in the append-only store and / or before generating a report. If the check reveals that a block of the blockchain has been manipulated, the framework will not allow the receiving entity to access the data in the Δ object stored in the append-only store, and / or will not generate a report.

[0062] Thus, a data structure (here: at least one blockchain) is provided, which includes payload data and access controls and / or data processing / reporting controls in a tamper-resistant monolithic block, which inherently ensures data integrity of the payload data and the control data, and which inherently ensures that if imported into a framework instance, any copy of the data structure will only reveal attribute information to one or more users, which attribute information will be revealed according to the AC / RS objects included therein.

[0063] Since each chunk in the append-only storage is preferably encrypted, only frameworks with the corresponding decryption key can access the contents of the append-only storage. Thus, only the same framework that created the append-only storage or a framework that has been entrusted with the required decryption key can decrypt the append-only data storage. Any manipulation of the chunks and therefore of the payload data and of the access rights and / or RS objects will be immediately recognized by the framework.

[0064] According to an embodiment, at least one append-only storage is a plurality of append-only storages. Each of the plurality of append-only storages represents a corresponding one of the external objects generated by the application and / or the framework. The framework is configured to selectively store a Δ object, an RS object, and / or an AC object including attribute change information, attribute processing information, and / or attribute access information about one of the external objects in one of the plurality of append-only storages representing an external object generated by an application. Therefore, each of the plurality of append-only storages may include an aggregate of attribute change information, attribute processing control information, and access control data that is required to ensure that any report or other output generated by the framework complies with data security and confidentiality requirements.

[0065] According to an embodiment, the framework is configured to store a sequence of data objects included in each of a plurality of append-only stores as a corresponding blockchain.

[0066] This means that each of the multiple append-only stores corresponds to a corresponding blockchain, and a sequence of Δ objects, AC objects, and / or RS objects stored consecutively on one or more data storage media underlying the append-only stores represents a sequence of blocks of the corresponding blockchain. Thus, each of the multiple append-only stores may include a totality of attribute change information, attribute processing control information, and access control data that is required to ensure that any report or other output generated by the framework complies with data security and confidentiality requirements, and that any manipulation of any element of a block will be identified by the framework and will enable the framework to prevent outputting manipulated reports in which the attribute change information as well as the data processing control data and the access control data are protected from manipulation.

[0067] According to an embodiment, the framework is interoperable with multiple different applications and is configured to create multiple blockchains for each application, whereby the totality of blockchains created for the same application in the multiple applications are interconnected via cryptographic hashes and form a tree structure of interconnected blocks. Thus, for n applications whose data objects are changed and corresponding RS objects and / or AC objects are saved by the framework, a corresponding blockchain tree is created, whereby the creation of new application-generated external objects leads to new branches in the blockchain tree.

[0068] In the following, various embodiments that specify how RS objects can be created, processed, used and / or stored will be described. If not explicitly indicated, AC objects can be created, processed, used and / or stored in the same manner as RS objects, the main difference between RS objects and AC objects being that RC objects have the functionality to specify one or more requirements about how the framework should handle one or more Δ objects before their contents are reported or otherwise disclosed, while AC objects have the functionality to specify to whom and under what conditions the framework should allow access to the information of these one or more Δ objects.

[0069] According to an embodiment, the framework and / or any other application that is allowed to access and process the data in the append-only storage must be programmed such that it is forced to analyze the requirements specified in the RS object and take these requirements into account when processing the Δ object. Thus, in case the requirements change, it is sufficient to store a new RS object specifying the new requirements in the append-only storage. The framework and / or other highly trusted programs that access the append-only storage will ensure that the data in the Δ object will be processed and the results of the processing will be output to one or more client systems such that the requirements in the RS object are met.

[0070] Thus, embodiments of the present invention may have the following advantages: Append-only storage may be used as a highly flexible, functionally extended "overlay interface" for other applications, whereby the interface not only provides access to data as a result of executing the application, but also includes one or more requirements as to how the data contained in the append-only storage must be processed before the data is output to any client. Thus, the data content and the corresponding requirements form an integrated data access layer that flexibly adapts to new requirements and is additionally particularly robust to any subsequent data manipulation.

[0071] According to an embodiment, the framework is configured to evaluate all RS objects stored in at least one append-only storage that are assigned to one or more external data objects of interest to determine which attributes of the external data objects of interest and / or how to report these attributes. Then, based on the evaluation results of the RS objects during the first traversal, the at least one append-only storage is traversed again to generate a report.

[0072] For example, the first RS object RS1 may be created and stored in an append-only storage on January 3, 2020. RS1 specifies that the attributes "first name", "last name", and "date of birth" of all patient-related Δ objects in the append-only storage need to be pseudonymized before exporting to the client system. The second RS object RS2 was created by the framework on January 17, 2020 and stored in the append-only storage. RS2 specifies that the attributes "first name" and "last name" (but not "date of birth") of all patient-related Δ objects in the append-only storage need to be pseudonymized before exporting to the client system. The framework, which is an access interface to Δ objects for one or more clients, can receive a client's request for medical data of one or more patients. In response to the request, the framework analyzes all RS objects to determine which of the requirements stored in the RS objects is valid for the time period of interest to the client. For example, the framework may determine that RS1 can be ignored because its requirements are overruled by the requirements in the most recent RS2. The framework will then process the Δ object according to the currently valid requirements specified in RS2 and return output that meets the requirements. The system formed by the combination of the application, the framework, and the append-only storage is robust against data manipulation attacks, because the append-only storage does not allow modification of already stored data objects, such as Δ objects or RS objects. At the same time, the system is highly flexible, because existing requirements can be easily overwritten simply by having the framework store one or more new RS objects whose requirements partially or completely overrule the requirements specified in other already stored RS objects.

[0073] According to an embodiment, the framework is instantiated on a computer system including a main memory. Execution of one or more framework functions includes at least a first sequential scan of at least one append-only storage to process RS objects and / or AC objects included therein, and at least a second sequential scan of at least one append-only storage to process Δ objects, thereby taking into account requirements specified in the RS objects (if any) and / or access control constraints and / or permissions specified in the AC objects (if any) already processed in the first sequential scan. The total size of the Δ objects and the RS objects and / or AC objects in at least one append-only storage exceeds the size of the main memory. According to some examples, at least one append-only storage includes multiple append-only storages, and the total size of the append-only storages exceeds the size of the main memory.

[0074] For example, the total size of at least one append-only storage may be greater than 10%, or greater than 100%, or greater than 1000% of the size of the main memory of the computer system hosting the framework. Typically, the main memory of the computer system may have less than 10 GBytes, while the data of at least one append-only storage may include more than 1 TByte of data.

[0075] Embodiments of the present invention may have the following advantages: Both application data and requirement specifications are stored in a manner that can be processed without consuming a large amount of memory. In prior art systems that use a database to process data, in the event that the amount of data to be processed and loaded into memory exceeds the size of the available memory, the system may start swapping. This may significantly reduce the performance of all software programs instantiated on the computer. Storing Δ objects and RS objects and / or AC objects in a memory that supports sequential scanning and processing of physically adjacent data objects may ensure that large amounts of data can be processed quickly even when memory resources are very limited.

[0076] According to an embodiment, the framework and the application share an object model that defines the types of external objects and the properties of the external object types. The object model defines how external objects are related to each other. Each external object is a data object instantiated outside of at least one append-only storage. The external objects include application-generated external objects and framework-generated external objects. Each framework-generated external object is a data object instantiated in the framework. The execution of one or more framework functions includes using the object model by one or more framework functions to create, modify and / or delete framework-generated external objects in the framework.

[0077] Embodiments of the present invention may have the following advantages: the business logic of an application and framework functions used as functional extensions of the application are seamlessly integrated because external objects created in the application and the framework are based on the same data model, and therefore the Δ objects that specify changes to these data objects are also based on the same object model.

[0078] For example, a programmer of the framework can define a set of objects, object attributes, object methods, and object relationships to be used as an object model for a specific task. For example, an object can represent a sensor or other component of a vehicle, and a task can be the generation and storage of a report of the internal state of sensor data and / or vehicle components. The object model can be defined by a system architect at the time of design of the framework, and can be instantiated as an integral part of the framework at the runtime of the framework. In addition, the object model can be stored in the form of a library (e.g., a Java class library) and used by the developer of the application at the time of design of the application to program the business logic of the application according to the object model. For example, the application can be a program for automatic or semi-automatic driving that takes into account sensor data and vehicle component status data provided by sensors and other components of the vehicle. For example, the object model can include classes, abstract classes, and / or abstract interfaces that can be used by the programmer of the application at the time of design of the application to implement the business logic of the application. For example, the programmer of the application can define classes and methods in an object-oriented programming language such as Java, which reuse, cover, and / or implement elements defined in the object model of the framework. Therefore, using a shared object model already at the time of design of an application can have the following advantages: ensuring that the business logic of the application and the framework functions provided by the framework as a functional extension of the application can be seamlessly integrated, because both are based on the same object model. Therefore, the Δ objects that define external object changes are based on the same object model, regardless of whether they are created by the framework in response to external object change events in the application (for example, when a sensor measures a new data value) or by the framework in response to external object change events in the framework (for example, when it is determined that the new measurement data exceeds a safety threshold and should trigger an alarm message or an entry in an error report).

[0079] According to an embodiment, the execution of one or more framework functions includes performing change operations on external objects generated by the framework during runtime of the framework. The change operations include creating, modifying and / or deleting one or more external objects generated by the framework in the framework. The execution of one or more framework functions also includes automatically creating a Δ object indicating a change in the attributes of at least one framework-generated external object caused by the change operation in response to any one change operation performed on the external object generated by the framework. The Δ object is created by the framework. The sequence of data objects sequentially stored in at least one append-only storage includes a mixture of a) Δ objects indicating changes to application-generated external objects, b) RS objects, and c) Δ objects indicating changes to framework-generated external objects. The RS object specifies requirements on how the framework must handle attribute information of one or more application-generated external objects and / or framework-generated external objects included in the Δ object.

[0080] According to an embodiment, the format of a delta object specifying changes to an application-generated external object is the same as the format of a delta object specifying changes to a framework-generated external object.

[0081] Embodiments of the present invention may have the following advantages: any change event to an external object is saved in the form of a Δ object in the append-only storage, regardless of whether the change occurs in the application or in the framework. Thus, the framework provides a functional extension for the application (and preferably also for one or more additional applications) that can be easily adapted by modifying the framework functions without modifying the source code of the application. This advantage may be particularly relevant in use case scenarios where the framework functions are used as functional extensions for a large number of applications. For example, a framework function for standardizing technical measurement data according to a specific standardization or calibration mode before the data is further processed and / or saved, a framework function for identifying, reporting and optionally blocking financial transactions with people who are included in a "blacklist" of suspected terrorists, etc. may not be implemented as part of the application but as part of the framework. In the case where multiple applications use a standardization or calibration mode (for example, in the context of an IoT industrial manufacturing process), the standardization or calibration mode can be easily modified by modifying the corresponding framework function. There is no need to modify the source code of the application. Similarly, in the event of a change in the content of a "blacklist" of suspected terrorists, or in the event of a change in the policy towards reporting and blocking financial transactions with persons mentioned in that list, it would be sufficient to modify the corresponding framework functions only once for the change to take effect for one or more applications that use the framework as a functionality extension.

[0082] According to an embodiment, the method includes providing an application, wherein the application is configured to solve at least one computing task. The at least one computing task includes a plurality of subtasks that are independent of demand and subtasks that are related to demand. When the application is designed, the application is implemented so that the source code of the application implements software instructions for solving subtasks that are independent of demand. The framework receives (e.g., automatically, semi-automatically or manually supplemented) at least one framework function specified by a user, wherein the at least one framework function implements software instructions for solving subtasks that are related to demand.

[0083] For example, a computing task may be the control of an industrial manufacturing process. Some subtasks may be demand-independent, meaning that the nature of the subtask is that any change in how the subtask is performed is unlikely or impossible. For example, some chemical processes require a given amount of educts that are processed within a very narrow range of process parameters (such as temperature or pressure). Any deviation from the educt composition and the values ​​of these process parameters will result in a dysfunctional or poorly-quality product. Therefore, subtasks that control the type of educt amount and subtasks that set required process parameters can be considered as demand-independent subtasks. In contrast, example computing tasks may include demand-related tasks, such as modifying the size of a product according to a customer's request, generating reports that meet data privacy requirements, data reliability requirements, or other requirements, etc. These subtasks are preferably not hard-coded in the application at design time. Instead, the framework is supplemented (at the time of design of the application or at an earlier or later moment) with one or more framework functions that implement demand-related subtasks. For example, but not necessarily, these one or more framework functions can be implemented in whole or in part in the form of user-editable rules or scripts. This may have the advantage that requirement-related subtasks may be modified easily and flexibly without having to recompile and / or redeploy the application.According to some embodiments, requirement-related subtasks implemented in the framework utilize a shared object model to instantiate framework-generated external objects during their execution.

[0084] According to an embodiment, the application is provided together with a plurality of additional applications, which are respectively configured to create external objects generated by the framework according to the object model of the framework, and are configured to notify the framework of any changes performed on one of the external objects generated by their applications. Each of the additional applications is configured to solve at least one computing task that is different from or the same as the computing task of the above-mentioned application. At least one computing task of each additional application includes a plurality of subtasks that are independent of demand and subtasks that are related to demand. When each additional application is designed, the additional application is implemented so that the source code of the additional application implements software instructions for solving subtasks that are independent of demand. The framework receives (e.g., automatically, semi-automatically or manually supplemented) at least one framework function specified by a user, wherein the at least one framework function implements software instructions for solving subtasks that are related to demand of one or more additional applications.

[0085] According to an embodiment, the application implements the core of the workflow of a specific computing task in the application (e.g., in the form of one or more demand-independent subtasks) (i.e., the business logic of a technical or medical task, or the business logic of an organizational, financial or other type of task), and implements additional functionality that is more frequently affected by demand changes than the core (demand-related subtasks) in the framework. There may be technical, organizational, legal and / or other reasons for demand changes. For example, additional functionality and corresponding demand-related subtasks that are likely to be affected by demand changes involve standardization, calibration, reporting, exporting and / or archiving of data processed and / or generated by the application. Tasks such as generating error reports for technical systems, standardizing sensor data for technical systems, and pseudonymizing or anonymizing sensitive data related to individuals that are exported are typical examples of additional functionality that is more frequently affected by demand changes than standard business workflow core functionality. Of course, the question of which functional aspects of a software program will be affected by frequent demand changes depends on the individual use case scenarios of the software system. The situation may be different for different use case scenarios (such as industrial production control using Internet of Things technology, management of sensitive patient data by a joint venture of multiple hospitals, smart home applications, or complex, heterogeneous software environments used by financial institutions or insurance companies).

[0086] According to an embodiment, the RS object specifies requirements according to a shared object model.

[0087] For example, an object model may specify a set of object types such as "patient", "blood analysis equipment", "DNA sequence analysis equipment", "disease", and "symptoms". Each object type may include one or more attributes. For example, the object type "patient" may have attributes such as "name", "address", "disease", "current symptoms", "treatment", "drug", "blood analysis results", and "sequencing results". RS objects can be specified so that each RS object created and stored by the framework refers only to the object types, attributes, and object relationships defined in the object model. This ensures that requirements match the grammatical and semantic structure of the object types defined in the object model.

[0088] Embodiments of the present invention may have the following advantages: Requirements are specified based on an object model in an object source agnostic but object model dependent manner. RS objects specify how the framework needs to process already stored Δ objects in order to generate output for the client. Since RS objects conform to a shared object model, it is ensured that the semantic and grammatical structure of the requirements matches the semantic and grammatical structure of the shared model.

[0089] According to an embodiment, one or more framework functions are rule-based or script-based functions. The method includes providing an interface through the framework, whereby the interface enables a user to edit a rule-based or script-based function. For example, the interface can be a GUI that enables a user to create and / or modify one or more framework functions without requiring programming skills. For example, a rule can have the form of a regular expression and / or can be represented and modified via an editable text box and graphical symbols of a GUI. This may have the advantage that the rule can also be easily adapted to the needs of being changed by a user who does not have programming skills.

[0090] According to some embodiments, script-based functions are specified using a scripting language such as Python, JavaScript, or Groovy.

[0091] According to an embodiment, the framework functions include framework functions that implement demand-related subtasks of the computing task to be solved by the application program.

[0092] Additionally, or alternatively, the framework functions may include functions providing reporting and / or data analysis functionality configured to process data generated by the application and stored in the at least one append-only storage in the form of delta objects.

[0093] In addition, or alternatively, the framework functions include functions that automatically and / or in response to receiving input from a user to create, modify, or delete requirements that will be used by one or more other framework functions to generate outputs. For example, the creation, modification, and / or deletion of requirements may involve creating and storing a new RS object that specifies one or more requirements that overrule existing requirements (if any) specified in a stored RS object. These requirements specification functions may be configured to receive requirements specifications from a user via a GUI of the framework, or to receive requirements specifications from a local or remote client via a local or remote requirements interface.

[0094] According to some embodiments, one or more framework functions may combine two or more of the above functions. According to an embodiment, one or more of the above framework functions utilize an object model (which is shared with one or more applications that interoperate with the framework and notify the framework of any changes to application-generated external objects) to create framework-generated external objects when executed. In response to a change to one of these framework-generated external objects, the framework creates and stores a Δ object.

[0095] According to an embodiment, the application program has no program function for storing an external object generated by the application or data returned by a function of the external object generated by the application in a non-volatile storage medium.

[0096] Additionally, or alternatively, the framework acts as a sole interface for the application to store application-generated external object data in the non-volatile storage medium.The framework uses only at least one append-only storage to store application-generated external object data in the form of delta objects.

[0097] Additionally, or alternatively, the framework acts as the sole interface for the application to return output to the client.

[0098] Additionally, or alternatively, the at least one append-only storage is configured to exclusively allow the framework to read data from and / or write data to the at least one append-only storage.

[0099] Embodiments including one or more of the above features may have the advantage of ensuring that the application does not output "non-compliant" results to any other application or user. The above features and / or system components ensure that the framework is the only available interface for accessing data generated by the application and stored in the append-only storage: the application itself may not include any data output interface, and may not allow the client to directly request data processing results. The task of storing the data generated by the application is completely delegated to the framework. This can also ensure that the software routines used to generate and store Δ objects, as well as the software routines used to read and process Δ objects and the software routines used to create and return output RS objects meet the requirements specified in the RS objects. Since the application is not used to save data, read data, and return data to the client, the programmer of the application does not have to worry about requirements related to how to store data and what type of data to store and how to output data to the client in a way that meets a set of requirements and what type of data can be output to the client in a way that meets a set of requirements. This task is centrally performed by the framework.

[0100] According to an embodiment, the computer-implemented method further comprises: receiving, by the framework, a requirement specification from a client; and in response to receiving the requirement specification, creating, by the framework, one of the RS objects. The created RS object specifies the received requirement. The created RS object is then stored in the append-only storage.

[0101] For example, the framework function may include one or more framework functions, which are responsible for responding to a demand request of a client and creating an RS object according to the demand request of the client.

[0102] According to an embodiment, the requirements specification (which may be provided, for example, within a request from a client and / or may be stored in one or more RS objects in an append-only storage) indicates one or more elements selected from the group consisting of:

[0103] a requirement specification regarding an output; for example, the requirement may specify one or more properties of one or more external object types whose changes or current states need to be saved; in addition, or alternatively, the requirement may specify a format of the output to be generated; in addition, or alternatively, the requirement may specify how to check, normalize, and / or aggregate data included in a Δ object related to one or more external objects of different object types in order to generate the output;

[0104] an ID of a predefined requirement about a Δ object stored in the framework; for example, the framework may include a set of predefined requirements and rules that specify how a Δ object is to be processed to generate an output, and the RS object may include only the ID of one of these predefined requirements, rather than the fully specified requirement;

[0105] the IDs of application-generated and / or framework-generated external objects whose data is to be included in or excluded from the output; preferably, each Δ object includes the object ID of the external object whose change triggered the creation of the Δ object; for example, the object ID may identify a specific person, such as a specific patient or customer, or a specific machine, product, sensor, etc.; the object ID in the requirements may be used to selectively ignore or hide (e.g., encrypt, anonymize, pseudonymize, or exclude) data related to attributes of that specific object when processing the Δ object to generate the output;

[0106] The attribute IDs of application-generated and / or framework-generated external objects whose data is to be included or excluded from the output;

[0107] an ID of a framework function or framework function subroutine to be used to compute an output based on the attribute information included in the Δ object, wherein the framework or subroutine ensures that the output meets the specified requirements;

[0108] specification of a criterion to be compared with the attribute information during output calculation, wherein a match of the criterion has an effect on the output calculation, wherein the criterion is in particular a numerical threshold, a blacklist of attribute values, a whitelist of attribute values, a mathematical expression or a regular expression; for example, a requirement may include an attribute-specific threshold and one or more external object type IDs, and the framework function may be configured to automatically generate an output in the form of a message or an alert in the event that a newly created Δ object indicates that one of said attributes of an instance of one of said external object types is above or below a threshold;

[0109] An indication of one or more time intervals during which the output must comply with certain requirements; for example, new data protection laws may be expressed in the form of requirements indicating that all data in Δ objects created and stored after the new law comes into effect must be hidden when generating the output; append-only storage may include many different RS objects with different requirements (these different RS objects have different or overlapping time intervals during which the corresponding requirements are valid) and / or many different RS objects having an impact on different external object types.

[0110] According to an embodiment, execution of one or more framework functions includes:

[0111] receiving, by the framework, a request to obtain a particular type of output from a client; for example, the request may be a request for a report, a request to analyze all or a subset of the Δ objects to solve a computational problem, such as for computing a medical diagnosis, for performing a computer simulation of a technical system, for reporting all financial transactions performed within a particular time interval and / or by a particular population, etc.; this step is optional; instead of receiving a request from a client, the framework may receive a trigger signal created internally by the framework or by a software program different from the client to receive the output;

[0112] In response to receiving the request (or receiving a trigger signal), traversing the at least one append-only storage for the first time by the framework, thereby selectively processing RS objects stored in the traversed at least one append-only storage to extract requirement specifications associated with the requested output type;

[0113] traversing the at least one append-only store a second time by the framework to extract attribute information from one or more delta objects stored in the traversed at least one append-only store, and processing the extracted attribute information according to the extracted requirement specification to compute output that complies with the extracted requirement specification; and

[0114] Return the output to the client.

[0115] This two-step approach to generating output data based on data stored in Δ objects can have the following advantages: the framework can ensure that the requirements specified in the RS objects are taken into account during the evaluation and processing of the Δ objects used to generate the output. Since all RS objects in the append-only storage are first analyzed, the framework is able to determine whether there are conflicts between the requirements specified in different RS objects, and resolve these conflicts if there are conflicts. For example, RS object RS1 may specify that for all patients in a specific state S1, attribute A1 of a specific object type "patient" must be pseudonymized, while the same attribute of patients in another state S2 does not have to be pseudonymized. Due to new laws on data protection in state S2, attribute A1 of patients in S2 also needs to be pseudonymized, and a new RS object RS2 including this requirement for patients in states S1 and S2 is stored in the append-only storage. Since RS2 has a shorter storage time than RS1, the framework according to some embodiments can resolve conflicts by ignoring all requirements specified in RS objects that are covered by other RS ​​objects with shorter storage dates. However, other methods of resolving requirement conflicts are also possible. For example, different RS objects may be assigned different priorities, and in the event of a conflict, the RS object with a higher priority overrides the requirements specified in the RS object with a lower priority.

[0116] Embodiments using the two-step approach may have the following advantages: A highly flexible and at the same time highly sophisticated way of specifying and taking into account requirements is provided: Adding new requirements or modifying existing requirements is very simple and only requires storing new RS objects in the append-only storage. The framework may use sophisticated schemes to resolve requirement conflicts, for example based on the time at which RS objects are stored and / or based on priority scores of RS objects and / or based on other criteria. In contrast to prior art approaches where requirements are hard-coded individually in the source code of each application, embodiments of the present invention may be more flexible in adding or modifying requirements that should take effect on one or more applications.

[0117] According to an embodiment, the at least one append-only storage is a plurality of append-only storages. The method further comprises:

[0118] Creating a corresponding data stream by the framework for each application-generated external object and / or each framework-generated external object; and

[0119] Each data stream is assigned a corresponding append-only storage by the framework.

[0120] According to an embodiment, sequentially storing a sequence of data objects in a plurality of append-only stores comprises:

[0121] selectively adding each delta object created in response to a change operation performed on one of the external objects to the data stream created for that external object; and

[0122] The storing of delta objects is performed such that all delta objects indicating changes to a particular one of the external objects are selectively stored in one of the append-only stores allocated to the data stream allocated to this particular external object.

[0123] Embodiments of the present invention may have the advantage of creating a corresponding data stream and append-only storage for each external object. This may speed up the processing of Δ objects in application scenarios where object-specific reporting and analysis is to be performed. For example, if the external object is a patient and if the output to be computed based on the patient-specific append-only stored Δ objects is a diagnosis or a prediction of a recommended treatment, then a sequential scan of the Δ objects to create the output may be performed more quickly than an implementation using a single append-only storage of Δ objects for all patients or all types and instances of external objects.

[0124] According to an embodiment, the method further includes creating, by the framework, one of the RS objects; identifying, by the framework, one or more external objects to which the requirements specified in the created RS object apply; and instantiating, by the framework, as many copies of the created RS object as the identified external objects. The storage of the RS object is performed such that, in each append-only storage to which one of the identified external objects is allocated via the data flow, a corresponding one of the copies of the RS object is stored.

[0125] According to a preferred embodiment, the framework is configured to evaluate one or more external objects that may be affected or may be affected by the requirements specified in the RS object when creating or storing a new RS object. The new RS object is then stored (possibly after creating several copies of the RS object) in an append-only storage specific to each external object, which is used to store the Δ objects of the external objects identified as being affected by the requirements in the new RS object. This ensures that each append-only storage includes not only the Δ objects of the specific external object, but also all RS objects that specify requirements related to the specific Δ object. For example, an append-only storage for selectively storing the Δ objects of the patient object "Tim Smith" may include many different RS objects that include requirements regarding patient data security, but typically does not include any RS objects that include requirements that apply only to the external object "Blood Analysis Equipment RS23973".

[0126] According to an embodiment, the method is performed on a computer system comprising a plurality of processing units. The method comprises automatically allocating data streams to different processing units to process the data streams in parallel.

[0127] Additionally, or alternatively, each of the plurality of append-only stores is included in a corresponding physical storage device, and storing of the data stream in the plurality of append-only stores is performed in parallel.

[0128] The embodiments of the present invention may have the following advantages: the storage, sequential reading and processing of Δ objects may be greatly accelerated.

[0129] According to an embodiment, at least one append-only storage includes Δ objects indicating external object changes of application-generated external objects of two or more different applications and / or framework-generated external objects that have been created or modified when executing a framework function as a functional extension of two or more applications (either sequentially or in parallel). Preferably, the Δ objects are stored so that they can be assigned to one of the two or more applications, the execution of which results in the creation of the Δ objects. Therefore, the framework includes a framework function configured as a functional extension of the two or more applications, and is configured to manage the storage of Δ objects, which indicate external object changes performed within the two applications, or external object changes performed in the framework as a result of executing the framework function as a functional extension of the two or more applications.

[0130] According to an embodiment, the method further comprises:

[0131] using the additional application to perform additional change operations on the additional application-generated external objects at runtime of the additional application, each additional application-generated external object being a data object instantiated within the additional application, the additional change operations comprising creating, modifying and / or deleting one or more additional application-generated external objects in the additional application, the additional application being configured to notify the framework of any of the additional change operations;

[0132] in response to any of the further change operations, automatically creating a further Δ object indicating a change in a property of at least one further application-generated external object caused by the further change operation, wherein the further Δ object is created by the framework;

[0133] storing, by the framework in at least one append-only storage, a sequence of further data objects sequentially, the sequence of further data objects comprising a mixture of further Δ objects and further RS ​​objects and / or further AC objects, each further RS ​​object being a data object specifying requirements on how the framework must process and output attribute information of one or more further application-generated external objects included in the Δ objects, each further AC object being a data object specifying access control constraints or privileges on attribute information of one or more further application-generated external objects included in the Δ objects, wherein the set of framework functions comprises at least one framework function that is a functional extension of the further application and is configured to, when called, process attribute information included in the one or more further Δ objects according to the requirements stored in the further RS ​​objects; and

[0134] Execute at least one framework function as a functional extension of another application to return another output, which is calculated as a function of attribute information in the Δ object, which conforms to requirements specified in another RS ​​object and / or which is returned to one or more users in accordance with access control constraints and / or privileges of the AC object.

[0135] Embodiments may have the following advantages: the functions of multiple applications that may be particularly affected by frequent changes in requirements may be centrally implemented within a framework, and the framework is also suitable for acting as a central storage layer responsible for storing, processing and / or outputting data generated by two or more applications in order to meet multiple requirements that may change frequently.

[0136] According to an embodiment, applications, frameworks, and further applications share the same object model that defines types of external objects, further external objects, properties of external object types, and properties of further external object types.

[0137] Additionally, or alternatively, one or more framework functions are functional extensions of the application and further applications.

[0138] In addition, or alternatively, one or more RS objects and other RS ​​objects are the same. For example, some RS objects may include requirements related to all applications configured to use the framework as functional extensions. Some other RS ​​objects in the RS object may include requirements related only to a subset of applications.

[0139] Additionally, or alternatively, one or more AC objects are identical to other AC objects. For example, some AC objects may include constraints that specific attributes and / or attribute change information of specific application-generated or framework-generated external objects should only be output to / accessible by users who have authenticated using biometric credentials, or should only be output when the changes occur within a specific time period or affect specific external objects. Thus, flexible, fine-grained access control can be provided for external objects shared by multiple different applications without having to modify the applications or modify user permissions multiple times for each application.

[0140] Therefore, embodiments of the present invention may provide systems and methods that can support multiple heterogeneous applications to comply with multiple heterogeneous requirements and / or access permissions in a fine-grained and flexible manner.

[0141] According to an embodiment, multiple change operations and creation and storage of delta objects are performed within an integration transaction. Each integration transaction includes one or more change operations performed within an application and at least creation and storage of delta objects triggered by the one or more change operations.

[0142] Embodiments may have the advantage of ensuring that append-only stored content is synchronized and consistent with the application.

[0143] According to an embodiment, one or more integration transactions respectively include at least creation and storage of one or more Δ objects, creation and storage of one or more RS objects and / or creation and storage of one or more AC objects.

[0144] Embodiments may have the following advantages: the append-only stored content includes not only the Δ objects created within a given integration transaction and the time interval covered by the transaction, but also all RS objects and / or AC objects created within the time interval. This can ensure that the data and the requirements specifying how to process the data and / or the access control data related to the information included in the Δ objects are synchronized. In the event of a failure to create and / or store a new RS object and / or a new AC object in the framework, the creation and storage of the Δ objects in the integration transaction that covers the failed RS object or AC object creation will also be stopped or undone.

[0145] According to a preferred embodiment, the framework and / or the append-only storage includes a cache for temporarily storing Δ objects / RS objects before the Δ objects and / RS objects are written to the append-only storage. Each integration transaction defines an integration transaction context, including any of the following events in the integration transaction context:

[0146] Failure to store a delta object in at least one append-only store within an integration transaction; and / or

[0147] Failure to store an RS object in at least one append-only store within an integration transaction; and / or

[0148] Failure to execute the framework's creation of RS objects within an integration transaction; and / or

[0149] Failure to execute the framework's creation of AC objects within an integration transaction; and / or

[0150] Failure to perform changes on application-generated external objects in the application within an integration transaction;

[0151] Causes the following actions:

[0152] Reversing all application-generated external object changes in the application program that have been executed in the integration transaction; and

[0153] delete all RS objects created by the framework in the integration transaction; and

[0154] Delete all Δ objects and RS objects that have been written to the cache in the integration transaction.

[0155] Embodiments of the present invention may have the following advantages: the contents of the append-only store are logically consistent with the state of external objects in one or more applications interoperable with the framework and include all RS objects that have been created in a particular transaction context.

[0156] According to an embodiment, the Δ object (and RS object and / or AC object, if any) stored in the cache is deleted from the cache after a successful commit event of a transaction and upon rollback of the transaction.

[0157] According to an embodiment, the application is configured to define the expected end of each integration transaction in the form of a commit-ready signal. For example, the commit-ready signal can be a closing curly brace indicating the end of a method, the execution start and end of which are programmed to correspond to the start and end of the integration transaction.

[0158] The method further includes:

[0159] ordering, by the framework, the Δ objects, RS objects, and / or AC objects created within different integration transactions according to a temporal order of commit ready signals of integration transactions including the corresponding Δ objects and RS objects; and

[0160] The storage of the sorted Δ objects and RS objects and / or AC objects is performed in at least one append-only storage such that:

[0161] Δ objects and RS objects and / or AC objects belonging to the same integration transaction are stored according to the time order in which they were created within the integration transaction; and

[0162] The Δ objects and RS objects and / or AC objects belonging to different integration transactions are stored according to the time sequence of commit ready signals included in the different integration transactions.

[0163] For example, an application may begin executing a function, thereby triggering the start of a new integration transaction. The opening of the function is communicated to the framework to enable the framework and the application to create an integration transaction context that spans the application, the framework, and the append-only store. During the execution of the function, an attribute A1 of an external object EO1 "Customer WillSmith" generated by the application changes at time t1. Then, at time t2, the same attribute A1 is changed a second time to a new attribute value. Then, at time t3, another attribute A2 of EO1 is changed to a new attribute value. Each external object change is communicated to the framework and causes the framework to create a Δ object indicating the change. Each Δ object may include an identifier of the attribute that was changed, the new attribute value, the time of the change, the ID of the extended object that includes the changed attribute, and the ID of the integration transaction in which the change occurred. The framework is configured to create and store Δ objects within the integration transaction indicating the changes performed within the application at times t1, t2, and t3. Preferably, the creation of the delta object is in the same time order as the changes to the external objects that occurred within the integration transaction, and the storage of the delta object to the append-only storage is in the same time order as the creation of the delta object. Then, the application's function is closed, whereby the closure of the function is transmitted to the framework as a commit-ready signal. The framework commits the integration transaction upon receiving the commit-ready signal. This means that in case of an error during modification of an external object in the application, during modification of an external object in the framework, during creation or storage of a delta object, all other actions performed within the same integration transaction will be undone.

[0164] Storing the Δ objects created in an integration transaction in the same chronological order as the external object changes that occurred in the application can have the following advantages, the state of a particular external object and / or the state of the entire application can be easily and very quickly reconstructed by sequentially traversing the Δ objects stored sequentially in the append-only storage. For example, the framework can be configured to create undo operations when sequentially traversing the append-only storage starting from the most recently stored Δ object, whereby each undo operation originates from one or more Δ objects and is suitable for undoing changes to the external objects specified by the Δ objects. According to another example, the framework can be configured to create restore operations when sequentially traversing the append-only storage starting from the earliest stored Δ object, whereby each restore operation originates from one or more Δ objects and is suitable for reapplying changes to the external objects specified by the Δ objects to the external objects that have not yet reflected the changes.

[0165] According to an embodiment, the external object generated by the application is a digital representation of a physical object, and the application is an Internet of Things application. For example, the object generated by the application can represent a physical object, such as a machine, a machine part, a sensor, a vehicle, a computer, a network device, a natural person or a legal person (such as a patient, a customer or a company), etc. In addition, or alternatively, the external object generated by the application is a business object of the application. The business object can represent a physical object, or can represent a virtual object, for example, an intermediate result for performing a data processing task.

[0166] In another aspect, the present invention relates to a computer-implemented method for data access control. The method comprises:

[0167] Provide at least one append-only storage;

[0168] Providing a framework; in particular, the framework may be software, such as a software program or a software module;

[0169] performing, using the application at runtime of the application, change operations on application-generated external objects, each application-generated external object being a data object instantiated within the application, the change operations comprising creating, modifying and / or deleting one or more application-generated external objects in the application, the application being configured to notify the framework of any of the change operations;

[0170] In response to any of the change operations, automatically creating a delta object indicating a change in a property of at least one application-generated external object caused by the change operation, wherein the delta object is created by the framework;

[0171] storing, by the framework, in at least one append-only storage, a sequence of data objects, the sequence of data objects comprising a mixture of Δ objects and AC objects, each AC object being a data object specifying access control data (particularly specifying access constraints and / or access privileges) with respect to attribute information of one or more application-generated external objects included in the Δ objects, wherein the framework comprises a set of framework functions (220), one or more of which are access control functions configured to control access of one or more users to attribute information included in the Δ objects in accordance with the access control data stored in the AC objects;

[0172] One or more access control framework functions are executed to control access of one or more users to attribute information in the Δ object based on the AC object.

[0173] In a further aspect, the invention relates to a computer program product comprising computer executable instructions that, when executed by a processor, cause the processor to perform method steps performed by the framework. According to some embodiments, the computer program product further comprises at least one append-only storage and / or computer executable instructions that, when executed by the processor, cause the processor to perform method steps performed by one or more applications that interoperate with the framework to propagate external object changes to the framework, as described herein with respect to embodiments of the invention.

[0174] In a further aspect, the present invention relates to a computer program and / or a computer program product comprising computer executable instructions for performing the method of data processing control and / or data access control according to any one of the embodiments described herein.

[0175] In a further aspect, the invention relates to a computer system including a framework. According to some embodiments, the computer system further comprises at least one append-only storage and / or one or more applications interoperating with the framework to propagate external object changes to the framework, as described herein with respect to embodiments of the invention.

[0176] In an additional aspect, the invention relates to a computer system comprising at least one append-only storage and a framework operably coupled to at least one application.

[0177] The application is configured to perform change operations on application-generated external objects during runtime of the application. Each application-generated external object is a data object instantiated in the application. The change operations include creating, modifying and / or deleting one or more application-generated external objects in the application. The application is configured to notify the framework of any of the change operations.

[0178] The framework is configured to:

[0179] In response to any of the change operations, automatically creating a delta object indicating a change in a property of at least one application-generated external object caused by the change operation;

[0180] sequentially storing in at least one append-only storage a sequence of data objects, the sequence of data objects comprising a mixture of Δ objects and RS objects; each RS object being a data object that specifies requirements on how a framework must process and output attribute information of one or more application-generated external objects included in the Δ objects; the framework comprising a set of framework functions, each framework function being a functional extension of an application program and configured to process attribute information included in one or more Δ objects according to the requirements stored in the RS objects when called; and

[0181] One or more skeleton functions are executed to return output computed as a function of the attribute information in the Δ object that conforms to the requirements specified in the RS object.

[0182] According to an embodiment, the computer system further comprises at least one application.

[0183] In another aspect, the present invention relates to a computer system comprising:

[0184] At least one append-only storage;

[0185] a framework operably coupled to at least one application;

[0186] wherein the application is configured to perform change operations on application-generated external objects during runtime of the application, each application-generated external object being a data object instantiated within the application, the change operations comprising creating, modifying and / or deleting one or more application-generated external objects in the application, and the application is configured to notify the framework of any one of the change operations;

[0187] The framework is configured as:

[0188] In response to any of the change operations, automatically creating a delta object indicating a change in a property of at least one application-generated external object caused by the change operation;

[0189] sequentially storing in at least one append-only storage a sequence of data objects, the sequence of data objects comprising a mixture of Δ objects and AC objects, each AC object being a data object specifying access control data (particularly specifying access constraints and / or access privileges) with respect to attribute information of one or more application-generated external objects included in the Δ objects, wherein the framework comprises a set of framework functions (220), one or more of which are access control functions configured to control access of one or more users to attribute information included in the Δ objects according to the access control data stored in the AC objects;

[0190] One or more access control framework functions are executed to control access of one or more users to attribute information in the Δ object based on the AC object.

[0191] In another aspect, the present invention relates to a data structure comprising a sequence of data objects. The sequence of data objects comprises a mixture of Δ objects and RS objects and / or AC objects. Each Δ object indicates a change in the properties of at least one application-internal data object of an application (e.g., an "application-generated external object" described herein). Each RS object is a data object that specifies requirements on how the framework must process and output property information of one or more application-internal data objects included in the Δ object. Each AC object is a data object that specifies which user the framework allows or denies access to a Δ object, which includes change information of a specific data object in the application-internal data object. The sequence of data objects is stored as at least one blockchain, wherein each Δ object and each RS object and / or AC object represents a block.

[0192] The data structure thus provides a tamper-proof monolithic unit of payload data, data processing control data and / or access control data, whereby any manipulation of the payload data as well as the control data and the temporal order of data objects in the data structure can be immediately detected.

[0193] In a further aspect, the invention relates to a transitory or non-transitory storage medium comprising a data structure.

[0194] According to an embodiment, the data structure is an append-only storage or a group of append-only storages.

[0195] According to an embodiment, the framework is a software program that provides a unique access layer through which one or more users can retrieve information about attribute values ​​and value changes of application-internal data objects of an application, whereby the framework is configured to process information output to the user according to requirements in the RS object, and / or is configured to provide information according to access control data specified in the AC object.

[0196] According to an embodiment, the data structure comprises at least one further blockchain comprising a mix of further Δ objects, further AC objects and / or further RS ​​objects, wherein each further Δ object indicates a change in a property of at least one application-internal data object of a further application.

[0197] For example, the data structure can be used as a tamper-proof archive and / or as a tamper-proof data basis for generating reports, whereby the reports comply with the requirements stored as part of the data basis and / or disclose information only to selected users or user groups according to access control data as part of the data basis.

[0198] As used herein, "computer system" refers to a machine or set of machines that can be instructed to automatically perform a sequence of arithmetic or logical operations via computer programming. Modern computers have the ability to follow a general set of operations referred to as "programs", "software programs" or "software applications". These programs enable computers to perform a variety of tasks. According to some embodiments, a computer system includes hardware (particularly one or more CPUs and memory), an operating system (main software), and additional software programs and / or peripherals. A computer system may also be a group of computers connected and working together, particularly a computer network or a computer cluster, such as a cloud computer system. Therefore, as used herein, "computer system" may refer to a monolithic standard computer system, such as a single server computer, or a computer network, such as a cloud computer system. In other words, one or more computerized devices, computer systems, controllers or processors may be programmed and / or configured to operate as explained herein to perform different embodiments of the present invention.

[0199] As used herein, a "blockchain" is a list of records, called blocks, linked using cryptography. Each block includes a cryptographic hash of the previous block, as well as additional data, such as property change information in the case of a Δ object, a requirement specification in the case of an RS object, or access control data in the case of an AC object.

[0200] As used herein, a "cryptographic hash" is a mathematical algorithm that maps data of arbitrary size (often referred to as a "message") to a fixed-size array of bits (a "hash value," "hash," or "message digest"). It is a one-way function, i.e., a function that is not practically invertible. According to an embodiment, the only way to find the message that produces a given hash is to attempt a brute-force search of possible inputs to see if they produce a match.

[0201] As used herein, a "requirement" is a requirement specification or one or more standards that a software function and / or data set must meet. For example, a requirement may represent a technical, organizational, and / or legal requirement, or a mixture thereof. For example, a requirement may specify one or more criteria that the results of a data analysis must meet before they are output to a client. A requirement may specify a technical threshold and may be used by a software program (e.g., a framework) to continuously compare dynamically modified property values ​​to the thresholds, thereby triggering a reaction if the new property value exceeds or falls below the threshold.

[0202] As used herein, a "data object" is a data object in a software application. A data object may be, for example, an external object or a RS object or a Delta object or any other type of data structure that includes data.

[0203] According to a preferred embodiment, an external object is an instance of a class written in an object-oriented programming language (e.g., Java). For example, an external object can be a Java bean. An external object can include one or more variables (also referred to as "properties" or "attributes") and respective data values. In some embodiments, at least some of the external objects of an application and / or framework are text-based data objects, such as XML objects or JSON objects.

[0204] Some external objects may include only one or more attributes and may be used to maintain a set of instance variables and / or associations with other external objects, thereby weaving an object network representing object relationships. Other external objects may additionally or exclusively include one or more methods (also referred to as "functions") for manipulating the attribute values ​​of other external objects and / or for performing any other type of data processing tasks, such as for monitoring or controlling industrial production workflows, for aggregating data included in multiple other external objects, for selecting one or more external objects that meet specific criteria, for creating new external objects, and / or for deleting external objects. Typically, the creation of a new external object is implemented as the creation of a new instance of a class, while the deletion of an existing external object is implemented as the deletion of an instance of a class.

[0205] For example, an external object "car_237428348" is an instance of the "car" class, which includes variables such as "color", "registration date", "make", "type", "fuel consumption", etc., and it can maintain a 1-n association with its owner (a collection of "person" instances). In addition, it can include getter and setter methods that enable other external objects to read and manipulate the variable values ​​currently assigned to the variables of the external object "car_237428348".

[0206] According to some embodiments, only class templates and external objects representing objects of an object model shared with the framework are considered external objects. Data objects used for purely application-internal data processing steps that do not correspond to objects in the shared object model are not considered to represent external objects whose changes trigger the creation of delta objects in the framework. In other words, according to some embodiments, only application-generated and framework-generated external objects specified in the shared object model trigger the creation of delta objects when they are changed.

[0207] "Class" as used herein is an extensible program code template that is used to create data objects, provide initial values ​​for states (member variables) and behavior implementation methods (member functions or methods). In many programming languages, the class name is used as the name of the class (the template itself), the name of the default constructor of the class (the subroutine that creates the object), and the type of object generated by instantiating the class; these different concepts are easily confused. When an object is created by the constructor of a class, the generated object is called an instance of the class, and the member variables specific to the object are called instance variables, in contrast to class variables shared across classes. In some programming languages, classes can only be declared at compile time, and cannot be declared at runtime of an application. In other languages, classes can be declared at runtime of an application and their structure modified.

[0208] As used herein, an "application" or "application software" is software designed to perform a set of coordinated functions, tasks, or activities for the benefit of one or more users and / or for the benefit of an organization (e.g., a company). Examples of applications include a word processor, a spreadsheet, an accounting application, a web browser, an email client, a media player, a file viewer, an aviation flight simulator, or a maintenance or control program for a manufacturing process. According to an embodiment, the application is not a database management program (DBMS), and in particular is not a relational DBMS or any SQL-based DBMS that utilizes table-based rather than data object-based data organization principles.

[0209] According to a preferred embodiment, the application is a complex application, for example, an application written in an object-oriented programming language such as Java, and the complex application includes thousands or even millions of data objects (referred to as external objects generated by the application). External objects dynamically interact with each other, are instantiated, modified and deleted during the runtime of the software application, thereby representing and controlling important workflows and services implemented in the application software. For example, the application can be an enterprise application software (EAS). The term EAS refers to a collection of computer programs that have complex applications, tools for modeling how the entire organization works, and development tools for building unique applications for the organization. EAS is intended to solve enterprise-wide problems and is intended to improve the productivity and efficiency of the enterprise by providing technical control logic support functions. EAS is computer software for meeting the needs of organizations rather than individual users. Such organizations include enterprises such as mining, manufacturing, agriculture, energy and service industries, and governments. For example, an application can be an EAS configured to monitor or control one or more industrial production processes, for example, in the context of the Internet of Things.

[0210] According to an embodiment, an application is a software program configured to display, manipulate and store a large amount of usually complex data and to support and / or automate industrial production processes or other processes with the data. The application can perform manufacturing functions and / or many other functions, such as order processing, procurement, production scheduling, customer information management, energy management and accounting. It is usually hosted on a server and usually provides synchronous services to a large number of users through a computer network. For example, the application can be an enterprise resource planning (ERP) system, EAS or customer relationship management (CRM) software. "Business logic" or "domain logic" used herein is a part of the program that encodes the real-world domain rules that determine how to create, store and change data. It is contrasted with the rest of the software that may be involved in managing databases or displaying user interfaces, system infrastructure or generally connecting the various parts of the program at a lower level of detail.

[0211] As used herein, a "data store" is a repository for storing and managing a collection of data. A data store may be a data repository in a memory, or more preferably, a non-volatile persistent data repository. A data store may be a database, i.e., a collection of data managed by a database management system (DBMS), or may be a simpler type of storage, such as a file, a directory, a directory service, or the like. For example, a DBMS may be a DBMS configured to manage a relational database, an object-oriented database, a NoSQL database, a key-value database, a wide column store, or the like. According to a preferred embodiment, the data store for storing Δ objects is an append-only storage, such as a stream database managed by a stream management application (such as Apache Kafka), or another type of storage that does not allow changes to already stored data values.

[0212] As used herein, an "object model" is a data structure that defines a collection of objects, object attributes, and object relationships using object-oriented techniques. It supports the creation of an architectural software or system model before development or programming. Typically, an object model is part of the object-oriented programming (OOP) lifecycle. An "object-oriented domain model" can be a specification of the static structure of classes and objects, their associations, and (optionally) their behavior.

[0213] As used herein, "append-only storage" is an immutable database and only allows new entries to be stored, but does not allow existing entries to be modified or deleted. Append-only storage prohibits editing or deleting entries already stored in the database. According to an embodiment, "append-only storage" stores data sequentially in adjacent blocks of one or more storage media, thereby enabling fast data retrieval via sequential reads.

[0214] Append-only storage can be implemented based on many different types of databases. For example, some traditional relational databases support an append-only mode of operation. According to a preferred embodiment, the append-only data store is a streaming database. A streaming database is a database in which data is stored continuously and allows the definition of permanent queries (also called "continuous queries"), which notify clients registered for the query as long as the data stored in the streaming database matches the query. If such a continuous query only checks a single record, it can be implemented by checking each record as it arrives. This is very efficient because only the incoming records need to be scanned. For example, Apache Kafka can be used as a streaming database.

[0215] According to some embodiments, the append-only storage is a streaming database, where a streaming database is a database in which write and / or read access is controlled by software called a "streaming application" (i.e., software that stores data in the append-only storage in the form of data streams and allows continuous queries to be defined). According to preferred embodiments, the append-only storage meets some or all of the following criteria: sequential consistency and reliability, guaranteed delivery and transactional consistency, "exactly once" semantics, security, scalability, and fault tolerance.

[0216] As used herein, an "RS object" (or "requirement specification object") is a data object that includes specifications for one or more requirements. The requirements are specified in a format that is interpretable by the framework and enables the framework to extract one or more requirements. For example, the extraction of the requirements may enable the framework to process framework-generated and / or application-generated external objects according to the requirements for generating and storing a sequence of Δ objects that meet the requirements, and / or may enable the framework to process Δ objects read from at least one append-only storage so that output that meets the requirements is returned to the client. For example, an RS object may include specifications for a time period during which the requirements must be enforced, specifications for one or more clients to which corresponding output that meets the requirements needs to be generated, thresholds of external object attribute values ​​whose violation triggers the execution of a specific framework function, and the like. According to an embodiment, the framework is configured to output the information included in the Δ object according to the requirements specified in the RS object, and prohibits outputting the information in any other manner or format.

[0217] As used herein, an "AC object" (or "access control object") is a data object that includes a specification of access control related constraints and / or permissions. The constraints and / or permissions are specified in a format interpretable by the framework. The framework is preferably configured to control access to a Δ object in at least one append-only store based on the permissions and constraints stored in the AC object in the at least one append-only store.

[0218] For example, an AC object may specify which of multiple registered users will be authorized to access a Δ object related to a particular external object, may specify changes to which of multiple attributes the user will be allowed to access, may specify a time period in the life cycle of the external object during which these changes should be accessible, and / or may specify other requirements that a user must meet in order to be allowed to access information stored in the Δ object.

[0219] The "framework function" used in this article is a function implemented by the software provided by the framework. According to a preferred embodiment, the framework includes multiple framework functions of one or more different types. For example, the first framework function in the framework function can be a functional extension of the program logic of one or more applications. According to some embodiments, the and / or other framework functions are implemented as output framework functions, which are configured to process Δ objects and RS objects to create and return outputs based on the data included in the Δ object and in accordance with the requirements specified in the RS object. In addition, or alternatively, the framework function may include an RS definition framework function that enables a user (e.g., via the GUI of the framework) and / or enables one or more remote clients (e.g., via an RS definition request) to trigger the creation and storage of new RS objects that specify new requirements.

[0220] As used herein, an "external object" is a data object that is instantiated outside ("external") of at least one append-only store. This means that the external object is not created by the append-only store, but is created by another software program (such as a framework or application). An "external object" may also be referred to as a "business object" or "data store external object". An "external object" may represent any type of entity, such as a natural or legal person, a machine, a product, a consumable, a vehicle, etc.

[0221] As used herein, a "framework-generated external object" is a data object instantiated in a framework, ie, a data object instantiated in a runtime object context created by the framework during runtime of the framework.

[0222] As used herein, an "application-generated external object" is a data object instantiated in an application, ie, a data object instantiated in a runtime object context created by the application at runtime of the application.

[0223] As used herein, a "client" may be a software program, a hardware unit, or a user. For example, a client may be a client program or a client device. A client may be a local client hosted on the same computer system as the framework, or may be a remote client configured to send requests to the framework via a network connection (e.g., the Internet).

[0224] As used herein, a "change operation" is any operation performed by and / or within a software program that creates a new data object (e.g., instantiates a class that serves as a template for a new data object instance), and / or modifies an existing data object (e.g., changes the value of a data object attribute), and / or deletes an existing data object, and / or creates, modifies, or deletes a class to be used as a template for a data object. A change operation may be performed within an application program, and may create or change or delete an application-generated external object or a class that serves as a template for creating an application-generated external object. In some embodiments, a change operation may also be performed on a framework-generated external object within a framework.

[0225] According to an embodiment, one of the change operations that triggers the creation of one or more delta objects is a modification of the class structure of a class included in the application and / or provided via a library, whereby the library includes class files that can be used as templates for instantiating external objects corresponding to data objects of the shared object model. Changes in the class structure automatically trigger the propagation of these structural changes to all instances of the class in the application, whereby each external object structure update performed during the propagation may also be a change operation that triggers the creation of a corresponding delta object.

[0226] As used herein, a "transaction" is an atomic change in the state of data. A transaction is a collection of one or more data processing operations performed as a separate, indivisible unit of work. Each transaction must succeed or fail as a complete unit. It can never be completed only partially. According to an embodiment, the framework may include a hardware or software-based transaction-oriented controller that manages and orchestrates the start and commit events of multiple transactions whose transaction contexts include at least an application, a framework, and an append-only store.

[0227] As used herein, the "commit ready signal" of an integration transaction is a signal indicating an event that all change operations to be performed by the application within the integration transaction have been performed but the integration transaction has not yet been committed. This means that in the commit ready event, the Δ object reflecting the data change needs to be stored in the append-only storage, and optionally in order to commit the integration transaction. The framework is configured to ensure that the integration transaction is committed only after all Δ objects created during the integration transaction are successfully stored in the append-only storage. Therefore, the "commit ready signal" is a signal that notifies the framework that the Δ objects created in a particular integration transaction can and should be stored in the append-only storage in order to allow the integration transaction to commit.

[0228] As used herein, an "integrated transaction" is a transaction that guarantees atomicity in a "global transaction" executed between two or more software components. For example, these two components may include an application and a framework that perform a change operation. An "integrated transaction" may also be referred to as a "cross-application transaction," whereby any software used to store data in a data store may also be considered an "application." For example, an integrated transaction may be implemented according to the X / Open XA standard (short for "extended architecture"), which is a specification published by X / Open in 1991 for distributed transaction processing (DTP). To ensure integrity, XA uses two-phase commit (2PC) to ensure that all changes to a transaction are either effective (committed) or not effective (rollback), i.e., atomicity. XA describes the interface between a global transaction manager and a specific application.

[0229] According to an embodiment, software that creates a delta object uses XA to create an integrated transaction scenario by instantiating an XA transaction manager using a library or a separate service. The transaction manager tracks the participants in the transaction (i.e., the various data stores written by the framework, i.e., append-only stores) and works with them to perform a two-phase commit. In other words, the XA transaction manager's interaction with the application and the server is separate. XA maintains a log of its commit or rollback decisions, which can be used to recover in the event of a system outage.

[0230] An "integration transaction" is a transaction according to the ACID standard. For example, an integration transaction may include a change operation performed within an application and a storage operation performed within a framework storing a delta object in an append-only store. According to some embodiments, the integration transaction is implemented based on a two-phase commit protocol. According to other embodiments, other protocols may be used to ensure that all operations performed in the application, in the framework, and optionally in the append-only store, performed in the same integration transaction are performed according to the "all or nothing principle": either they are all successfully executed (commit event), or they are not executed or rolled back (failure / rollback event).

[0231] As used herein, the "ACID" standard (atomicity, consistency, isolation, durability) is a set of transactional properties that are intended to guarantee validity even in the presence of errors, power failures, and the like. A sequence of operations that satisfy the ACID properties, performed in one or more different applications (e.g., changes to data objects in an application and storage operations performed by one or more software programs that maintain a data store) is called a transaction. Thus, all operations included in a transaction represent a single logical operation on the data. For example, creating a new data object, assigning new attribute values ​​to various attributes of the new data object, and storing each Δ object representing one of the changes to the data object can be performed within a single transaction, referred to herein as an "integrated transaction," because the transaction includes operations performed in two or more different software programs.

[0232] As used herein, a "Δ object" is a piece of data used to store changes in one or more external objects. A Δ object can be a data object created as an instance of a class specified in an object-oriented programming language, but can also have any other data format, such as an XML or JSON file. Preferably, the Δ object includes metadata indicating various aspects of the change event (e.g., the ID of the external object that was created, deleted or modified, a timestamp indicating the time when the change operation that caused the creation of the Δ object was applied to the external object in the application, the ID of the application that performed the change operation on the external object, and the values ​​of any changed variables after the change). Optionally, the Δ object may also include the values ​​of any changed variables before the change. Preferably, the Δ object does not have any external object variable values ​​that have not been modified by the change operation.

[0233] As used herein, a "timestamp" is a character sequence or coded information that identifies when some event was recorded by a computer, typically giving a date and time of day, sometimes accurate to a fraction of a second. The time at which the computer recorded the event can be used as an indication of the time of the event itself, particularly when the event occurred within the computer itself, e.g., the event indicates a change of state of an external object instantiated on the computer. For example, a timestamp may be specified according to the ISO 8601 standard.

[0234] As used herein, a "selected time" is a freely selectable time, typically a combination of a date and optionally an indication of a specific hour, minute, and / or second. For example, the selection may be performed by a user, a software program, a hardware device, etc. The selected time is not limited to any particularity of the application, framework, or Δ object described herein for embodiments of the invention.

[0235] As used herein, a "framework" is software, such as a software program or a part thereof. In particular, a framework can be a general, reusable software program or a part thereof that provides specific functionality to facilitate the development of a software application. A software framework can include support programs, compilers, code libraries, one or more object models, functions, tool sets, and / or application programming interfaces (APIs) that combine all the different components together to enable the development and maintenance of a project or system. According to an embodiment, the framework includes at least some program logic (e.g., software programs or modules) that interoperate with any application developed using the framework (or with the aid of a library including class templates according to an object model) during the runtime of the application. The framework is configured to create a Δ object for storing the Δ object in an append-only storage, and is preferably also used to create and maintain an integrated transaction scenario that covers external object changes in the application and write operations performed in the append-only storage.

[0236] According to an embodiment, the framework also includes interface methods implemented by one or more classes of the framework. Therefore, an external object that performs a change operation will implicitly call and trigger the execution of some program code specified in the framework, such as code for creating a Δ object and / or for creating and submitting an integration transaction. According to an embodiment, the framework is also configured to determine whether the integration transaction has been successfully completed and whether the integration transaction should be terminated with a commit or rollback event.

[0237] As used herein, a "stream application" is software configured to store data in a stream database in the form of one or more streams, whereby the stream application supports continuous database queries for data stream operations. According to a preferred embodiment, the stream application is configured to allow other applications to take advantage of the parallel storage of data on many different physical data stores. Typically, the bottleneck of data storage tasks is disk access performance, not CPU or memory capacity. Therefore, software applications that allow parallel write (and read) operations to many independent physical data stores managed in the form of a single logical "append-only storage" may have particularly high performance advantages. Stream applications can enable these applications to use multiple computing units, such as floating point units on a graphics processing unit or a field programmable gate array (FPGA), without explicitly managing the allocation, synchronization or communication between these units. According to an embodiment of the present invention, a data stream is a stream of Δ objects received from a framework that has created a Δ object.

[0238] Streaming applications according to embodiments of the present invention are configured to provide optimal local on-chip memory reuse to minimize bandwidth losses considered external memory interactions when processing data streams. Streaming applications can use unified streams, where one kernel function applies to all elements in the stream. Because kernel and stream abstractions expose data dependencies, compiler tools can fully automate and optimize on-chip management tasks.

[0239] According to an embodiment, the framework is implemented as a streaming application and / or is programmed such that it utilizes a separate streaming application to store the delta objects and the RS objects in at least one append-only storage.

[0240] According to an embodiment, the framework and / or the stream application used by the framework for storing delta objects is adapted to use programming language features (e.g., Java, Scala, or Go) to obtain optimal throughput of the processed data stream. For example, the compiler of the programming language used to write the framework and the application is used to optimize memory access and kernel functions.

[0241] The stream application can be, for example, Apache Kafka. Apache Kafka is an open source stream processing software platform written in Scala and Java, developed by LinkedIn and donated to the Apache Software Foundation. Apache Kafka is a unified, high-throughput, low-latency platform for processing real-time data feeds. Its storage layer is essentially a "massively scalable publish / subscribe message queue" designed as a distributed transaction log, making it very valuable for enterprise infrastructure to process streaming data. In addition, Kafka connects to external systems (for data import / export) via Kafka Connect and provides a Java stream processing library Kafka Streams. Apache Kafka allows users to subscribe to it and publish data to any number of real-time applications.

[0242] According to an embodiment, a stream application is configured to store data objects, such as key-value messages, from any number of processes called producers. The stream application can divide the data into different "partitions" within different "topics". Within a partition, the data objects in the stream are strictly ordered by their offset (the position of the message within the partition) and are indexed and stored together with a timestamp. Other processes called "clients" can read data objects from the partition. For stream processing, the stream application can provide an API (e.g., StreamsAPI in the case of Kafka) that allows writing Java applications (e.g., frameworks) that consume data from the stream application and write the results back to the stream application. For example, a framework that creates Δ objects can act as a producer that provides a stream of Δ objects to a stream application, and also act as a client that receives a sequence of Δ objects obtained by sequentially scanning and traversing the append-only storage by the stream application, such as to use the read Δ objects to perform computing tasks (e.g., perform data analysis, generate reports, generate complete or partial data exports) and / or reconstruct the state of the application.

[0243] As used herein, a "stream" or "data stream" refers to an unbounded, continuously updated set of data, where unbounded means "of unknown or infinite size". According to some embodiments, a stream consists of one or more stream partitions, where a stream partition is an ordered, replicable, and fault-tolerant sequence of immutable data records (e.g., Δ objects), where data records are defined as key-value pairs. For example, Apache Kafka can be used to receive one or more Δ object streams from a framework and store the one or more streams in one or more append-only stores managed by Apache Kafka.

[0244] According to some embodiments, the framework or the stream application used by the framework for storing Δ objects includes a "window function". A "window function" as used herein is a function supported by a certain stream application that allows data records ("events") (e.g., Δ objects) to be grouped, sharing a specific key for stateful operations, such as aggregation or connection into a so-called window. Track windows by record key. According to an embodiment, the stream application is configured to use a window function on the record key "transaction ID" and / or "external object ID" to group Δ objects based on the transaction context of the Δ object and / or based on the external object whose change triggered the creation of the Δ object, and store the Δ objects in group order. The window function implements a timeline including event data and enables the stream application or another application to selectively perform various operations on events within the window.

[0245] According to an embodiment, the stream application used by the framework and / or the framework for storing Δ objects is a queuing system. The "queuing system" or "message queuing system" used in this article is a software program configured to be able to receive high-frequency messages in parallel. Preferably, the queuing system according to an embodiment of the present invention is also suitable for storing batches of messages (e.g., Δ objects) of the queue in parallel in multiple different physical data stores (e.g., append-only storage), so that each message and / or message batch of the queue has a clear message identifier, allowing the original sequence of messages and / or message tags of the queue to be reconstructed from multiple different physical data stores. Preferably, the queuing system is suitable for registering multiple users to extract messages or a batch of messages from the queue. Each Δ object can represent a message stored in the queue. The queue management system is preferably configured to support transactions when pushing messages to the queue, thereby ensuring that the required actions (e.g., storing Δ objects in the queue) are guaranteed.

[0246] "Interface method" used herein is the definition of the method that can be implemented by a class and an instance of the class.Interface method is not specified in the code of the interface class, but is specified in the code of the class that implements the interface.For example, all or at least some methods and functions of the framework accessed by the application can be implemented as an interface class, and the interface method is implemented by the class of the framework that the application cannot directly access.Interface method provides the definition of the signature of a set of methods without specifying their complete implementation methods.Interface method can be included in the interface class, and this interface class can also define the type that can be used to declare the type of variable or parameter and the type of the return value of the method.For example, interface method can be provided to the developer of the application as a part of a library (such as Java class library) when the application is designed.Providing interface method to the developer of the application via the library can enable the developer to implement the application, so that the object model explicitly or implicitly specified in the library is used as the basis for defining the external objects generated by at least some applications.

[0247] The embodiments and examples described herein should be understood as illustrative examples of the present invention. Other embodiments of the present invention are contemplated. Although the present invention describes specific combinations and distributions of software programs and computer systems by way of example, it should be understood that any feature described with respect to any one embodiment may be used alone or in combination with other features described, and may also be used in combination with one or more features of any other embodiment, or with any combination of any other embodiment, as long as these features are not mutually exclusive.

[0248] Therefore, some embodiments of the present application are directed to computer systems.Other embodiments of the present application include corresponding computer-implemented methods and software programs to perform any of the method embodiment steps and operations summarized above and disclosed in detail below.

[0249] As will be appreciated by those skilled in the art, aspects of the present invention may be embodied as devices, methods, computer programs or computer program products. In addition, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable media having computer executable code embodied therein. A computer program includes computer executable code or "program instructions". Any combination of one or more computer readable media may be utilized.

[0250] Any software program described herein may be implemented as a single software application or a distributed multi-module software application. One or more software programs described herein may be carried by one or more carriers. A carrier may be, for example, a signal, a communication channel, a non-transient medium, or a computer-readable medium. A computer-readable medium may be: a magnetic tape; an optical disk, such as a CD or DVD; a hard disk; an electronic memory; or any other suitable data storage medium. The electronic memory may be a ROM, a RAM, a flash memory, or any other suitable electronic memory device (whether volatile or non-volatile).

[0251] Each of the different features, techniques, configurations, etc. discussed herein may be performed independently or in combination, and may be performed in a processing combination (such as in a client / server configuration) via a single software program.

[0252] It should be understood that the computer system and / or computer implemented method embodiments described herein may be implemented strictly as a software program or application, software and hardware, or solely as hardware (such as within a processor or within an operating system or within a software application).

[0253] The operations of the flowcharts are described with reference to the systems / devices shown in the block diagrams. However, it should be understood that the operations of the flowcharts may be performed by embodiments other than the systems and devices discussed with reference to the block diagrams, and that embodiments discussed with reference to the systems / devices may perform operations different from those discussed with reference to the flowcharts.

[0254] In view of the various arrangements of the embodiments described herein, this detailed description is for illustration only and should not be considered as limiting the scope of the invention. Therefore, the present invention claims all such modifications that may fall within the scope of the following claims and their equivalents. Therefore, the description and drawings should be considered illustrative rather than restrictive. BRIEF DESCRIPTION OF THE DRAWINGS

[0255] In the following embodiments of the present invention, purely by way of example, are explained in more detail with reference to the accompanying drawings, in which:

[0256] Figure 1 is a flow chart of a method for data processing control using RS objects and / or AC objects;

[0257] Figure 2 It is a block diagram of a computer system that is configured to ensure that the output of an application meets the requirements;

[0258] Figure 3 is a block diagram of a computer system that is configured to ensure that the output of multiple applications meets requirements;

[0259] FIG4 is a block diagram illustrating in greater detail components of a computer system configured to provide data processing control;

[0260] Figure 5 is a block diagram of a computer system coupled to a plurality of clients;

[0261] Figure 6 shows the data contents of an append-only store;

[0262] Figure 7 A process of reconstructing the state of an application based on an undo (UNDO) operation originating from a Δ object is shown;

[0263] Figure 8 A process for reconstructing the state of an application based on a restore (REDO) operation from a delta object is shown;

[0264] Fig. 9 The various submodules and functions of the framework are shown;

[0265] Fig.10 The data contents of various types of Δ objects are shown;

[0266] Fig.11 shows the creation of a Δ object in the framework;

[0267] Fig. 12A illustrates transaction-based storage of Δ objects and RS objects in a single append-only store; and

[0268] Fig. 12B Transaction-based storage of Δ objects and RS objects in multiple data object-specific append-only stores is shown. DETAILED DESCRIPTION

[0269] Figure 1 is a flow chart of a method for data processing control, the method comprising ensuring compliance with application requirements through RS objects and / or comprising applying access control through AC objects. Figure 2 2 is a block diagram of a computer system 200 configured to ensure that the output 230 of an application 226 conforms to a set of requirements that can be flexibly adjusted and extended at any time and can be effective for properties of external objects that have changed at arbitrary time intervals in the past. The system 200 of some embodiments also provides access control, with respect to which a user can access property change information of a specific property of an external object generated by a specific framework or generated by an application.

[0270] In the following, reference will be made to Figure 2 The method of claim 1 is described in detail with reference to the system shown in FIG. However, the method of claim 1 may also be implemented in a computer system according to other embodiments (e.g., Figure 3 The method may be particularly useful in situations where only limited memory resources are available and where large demands must be placed on large amounts of data.

[0271] In the following, embodiments are described for use in the context of controlling an industrial production process. However, embodiments of the present invention may also be used in a variety of different use case scenarios, such as IoT applications, smart home applications, supporting doctors in diagnosing and treating patients, controlling financial transactions, controlling data confidentiality in complex organizations, etc.

[0272] For example, the system 200 can be used to control the production of injection molded parts such as dowels, sealing caps, or housings. Various containers and machines for performing an automated injection molding process may include sensors for weight, temperature, viscosity, and other parameters of polymer blocks and their components before they are mixed together. Different types of injection molded products may have different requirements in terms of product quality (stability, uniformity, bubble-free, color, etc.), and even when the same mold is used to produce the same product for many different buyers, different buyers may have different requirements in terms of product quality. Therefore, in the case of using the same mold and the same production pipeline to generate a large number of products for different buyers with different quality requirements, the requirements for the control of the production process and threshold parameters must be changed frequently according to the order situation. Therefore, the ability to flexibly modify the requirements for the production process and product parameters is the key to being able to flexibly serve different customers with different quality requirements. For example, if high quality and optical uniformity of the product are required, the threshold value of the maximum number of acceptable bubbles may be lower than the same type of product with standard quality requirements. In addition, different polymers may have different viscosities or hardening times, so the same number of bubbles in a complete polymer block may have a greater impact on the optical properties of the surface of the injection molded product, depending on the type of polymer used, because some polymers may slow down the migration of bubbles to the surface before the polymer block hardens. Therefore, the requirements and thresholds may vary according to several parameters (such as the polymer material used), which may also change frequently. For example, requirements such as the maximum number of bubbles per cubic centimeter of polymer block are stored in the form of a data object referred to as an "RS object" in this article. In the case of exceeding the threshold during the production process of the injection molded product, it may be desirable to generate an alarm message by the production process monitoring application. The output should be forwarded to the production control application, which automatically takes appropriate actions to modify the production process. Only when it is really necessary should the alarm message be output and / or the alarm message should cause the production control application to take appropriate actions, and the necessary situation is: a given number of bubbles may be suitable for certain types of materials, customers and / or desired product quality levels, but not for other situations. Due to the fact that materials, customers, and required quality levels may change frequently in unforeseen ways, specifying these requirements in the source code of the production monitoring program regarding how and when to generate alarm message outputs would prohibit flexible modification of the requirements because the source code would have to be recompiled every time the requirements were slightly modified and / or every time production of a product for a customer with different quality requirements was started. Embodiments of the present invention provide a solution to this problem.

[0273] In a first step 102, at least one append-only store 224, 322 is provided. For example, the at least one append-only store may be a stream database maintained by a stream application such as Apache Kafka. Preferably, multiple append-only stores are provided, preferably located on different storage devices, for enabling parallel access to different append-only stores.

[0274] Next in step 103, a framework 210 is provided. The framework can be a software program including an object model 222 and a set of framework functions 220. The framework also includes a module for generating and managing RS objects, which includes requirements for various product or process parameters and thresholds. The module can be implemented in the form of one or more framework functions 222. The computer system 200 can be a single computer hosting the framework and at least one only append storage, and can also be one or more applications that interoperate with the framework. More preferably, the computer system 200 is a distributed computer system including multiple subsystems, which are connected to each other via a network connection (e.g., an intranet connection or an Internet connection). In this case, the framework, at least one only append storage and application 226 can be hosted on different subsystems. The object model 222 defines the structure, attributes and / or relationships of data objects referred to herein as "external objects". For example, the framework can be implemented in Java, and the external object can be a Java class instance, so that the class structure, the attributes and methods of the class are defined by the object model. For example, the framework can include a set of predefined classes and interfaces that implicitly specify the object model. By providing these classes and interfaces in the form of a software library, the object model can be shared with other software programs.

[0275] Next, in step 104, the method includes using an application 226 to perform change operations 206, 208 on application-generated external objects 202, 204, 304 at runtime of the application. For example, the application may be a program for monitoring the production process of a series of injection molded products at a given quality level. Each application-generated external object is a data object instantiated within the application 226. The application-generated external objects may represent various sensors, machines, machine parts, containers, segregates, and products of the manufacturing process, and optionally also entities such as suppliers, customers, cost calculation objects, or product quality indicator objects. The interaction of these external objects and the change of attribute values ​​represent and / or track the product processing workflow steps monitored by the application 226. The change operations 206, 208 include creating, modifying, and / or deleting one or more application-generated external objects in the application. For example, transferring a polymer block from one container to another container may correspond to changing the "state" attribute value of the extended object representing the other container from "empty" to "full".

[0276] The application is configured to notify the framework of any change operation. For example, the developer of the application may have used a library that includes the classes and interfaces of the framework, and can use this library to define classes used as templates for instantiating EOS generated by the application when designing the application. This may have other beneficial effects of the application sharing the object model with the framework. Programming the application using the library can allow the class representing the EO of another container to be programmed so that it implements the interface class provided by the framework. Modifications to the "state" attribute of the "container" EO class instance are automatically transmitted to the framework without the programmer explicitly implementing the propagation of such change operations from the application to the framework. Therefore, by using classes and interfaces provided by the framework and shared with the framework (for example, via a software library), the development of applications that interoperate with the framework and automatically transmit EO changes to the framework can be greatly facilitated.

[0277] In response to any of the change operations 206, 208, the framework 210 automatically creates delta objects 216, 218, 310 in step 106. Each delta object indicates a change in the property of at least one of the application-generated external objects caused by the change operation. For example, a delta object is created in response to changing the "state" property of an application-generated EO representing another container from "empty" to "full".

[0278] Next, in step 108, the framework stores the sequence of data objects sequentially in at least one append-only storage. The sequence of data objects includes a mixture of Δ objects 211, 212, 214, 310, 312, 404, 406 and RS objects 216, 218, 314, 316, 318, 320. The mixed sequence of objects corresponds to the time sequence of creation of Δ objects and RS objects. In some embodiments that support integration transactions, the framework is configured to a) sort the data objects according to the time sequence of the commit ready signal of each integration transaction, and b) sort the data objects according to the creation time sequence of the data objects created in the context of a given integration transaction. Each RS object is a data object that specifies requirements on how the framework must process and output attribute information of one or more application-generated external objects included in the Δ object. The creation of RS objects is preferably independent of the creation of Δ objects. For example, although the creation of a Δ object is triggered by a change operation performed on an application-generated EO, and optionally also by a change operation performed on a framework-generated EO, the creation of an RS object can be performed in response to a request from a local or remote client or in response to a user action via a GUI to create or modify an existing RS object.

[0279] Figure 2It is shown that the framework can use the interface 236 of the application program to store the sequence of RS objects 218, 216 and Δ objects 214, 212, 211 in at least one append-only storage. Preferably, the append-only storage is configured to prohibit all software programs other than the framework 210 and the software program that is optionally used by the framework to store data objects from accessing its data. For example, the framework can use a stream application to store data objects in the append-only storage. In this case, the stream application can also be allowed to access the append-only storage. Therefore, the append-only storage and the entire computer system 200 can ensure that only data that meets the requirements in the RS object is saved in the append-only storage and / or can ensure that only data output originating from data that meets the requirements in the RS object in the append-only storage is returned.

[0280] The framework includes a set of framework functions 220. One or more framework functions are functional extensions of the application and are configured to process attribute information included in one or more Δ objects according to requirements stored in the RS object when called. For example, a first framework function in the framework functions can analyze each Δ object that has been created by the framework to determine whether the Δ object includes confidential data that should not be stored in the append-only storage at all.

[0281] For example, one of the RS objects may specify that the name of a customer who has ordered a set of injection molded products should not be stored at all, or should be stored only in a pseudonymized or encrypted form. One of the framework functions is configured to analyze each Δ object as it is created to determine whether the Δ object includes sensitive customer-related data that needs to be removed or pseudonymized or otherwise protected before being stored in the append-only storage. If so, the framework function may perform the necessary data processing steps to modify the Δ object before it is stored.

[0282] Whenever a Δ object is created for a specific type of EO, the framework may call another one of the framework functions. For example, one of the framework functions may be responsible for storing the temperature measured in the mold during an injection molding process in a specific unit preferred by the customer to whom the injection molded products and the corresponding production agreements will be provided. For example, if the customer who has ordered the currently manufactured product is an American company, the measured temperature may have to be specified in degrees Fahrenheit °F. If the customer is a German company, the temperature may have to be specified in degrees Celsius ℃. The requirement for a temperature unit that is valid for the currently produced goods may be specified in one of the RS objects, which may be modified whenever the preferred temperature unit of the currently served customer changes. Other framework functions evaluate this "temperature unit requirement" RS object before the Δ object indicating the temperature change is stored in the append-only storage.

[0283] It should be noted that the above-described framework functions are examples of framework functions that are called in response to the creation of a Δ object to ensure that the Δ object meets the requirements before being stored. In addition, or alternatively, the framework function may include one or more framework functions that are called in response to a user or client's request to obtain an output, whereby the output is the result of analyzing one or more Δ objects in at least one append-only storage. For example, the framework may include an interface for receiving a request from a client to generate a report indicating several parameter values ​​measured during the production of a particular product. In response to the request, the framework may be configured to call a framework function that first analyzes the RS object in the append-only storage to determine the temperature unit used to generate the production report for the requesting client. If the RS object indicates that the client needs to provide a temperature in degrees Fahrenheit, the framework function normalizes all temperature values ​​originating from the associated Δ object to degrees Fahrenheit. If the RS object indicates that the client needs to provide a temperature in degrees Celsius, the framework function normalizes all temperature values ​​originating from the associated Δ object to degrees Celsius.

[0284] Due to the task of implementing a "normal" production monitoring workflow in an application, ensuring that the data generated by this monitoring workflow is stored and processed for reporting purposes by a framework function that takes into account requirements specified in the form of RS objects, embodiments of the present invention can allow for flexible changes in requirements simply by storing additional RS objects that overrule existing requirements in append-only storage. In cases where it is also necessary to modify some program functions that evaluate requirements in RS objects, it is sufficient to modify the framework functions that can be used by multiple different applications. For example, the standardization of temperature units can be used not only by an application for monitoring the production of injection molded products, but also by an application for monitoring the production of polymer extrusion products. Therefore, embodiments of the system can support modified and extended requirements in a more flexible way.

[0285] In addition to or in lieu of the creation and storage of RS objects, the framework may be configured to create and store AC objects. For example, some AC objects may specify that only specific users or user groups are allowed to access change information of specific attributes of specific external objects. Therefore, additional access constraints may be applied, such as restrictions on the time period during which attribute changes occur, restrictions on the time during which users are allowed to access attribute change information, and the like. Access constraints are also stored in AC objects. According to some embodiments, the framework is configured so that it considers the access control data specified in the AC object stored later to overrule the access control data stored in the earlier stored ("older") AC object. Therefore, after traversing at least one append-only storage once, the framework knows the youngest AC object associated with the corresponding Δ object, and can control access to one or more users accordingly. Access control may mean that the framework generates specific types of reports for different users in different ways. For example, some AC objects may specify that some users with higher access rights receive reports that include more (sensitive) attribute change information than other users.

[0286] Next, in step 110, the framework executes one or more framework functions for returning outputs. The outputs may be returned to a user and / or a client application or client system. For example, a client application may be a software program for controlling a production process according to some process parameter values ​​and / or alarms specified in the outputs. The client application may also be an archive application for storing manufacturing agreements for ordering goods. The outputs 230 are calculated by the framework as a function of the attribute information in the Δ object, whereby during the calculation of the outputs, the framework functions that have calculated the outputs take into account the requirements specified in the RS object.

[0287] Output 230 can be considered as a functional extension output of application 226, because the output is derived from the Δ object and therefore from the data generated as a result of executing application 226. The output is a functional extension output because the data in the output is not the same as the data generated in the application. Instead, the data in the output has been modified by the framework functions as a functional extension of the application, because these functions process the application data provided in the form of the Δ object in such a way that the output conforms to some requirements, such as one or more expected measurement parameter units, alarms thrown depending on the current effective threshold, and the need to hide certain attribute values ​​in pseudonymization or other ways.

[0288] According to some embodiments, the framework function includes or comprises an access control function configured to analyze access control data specified in the AC object and configured to grant or deny access to attribute change information in the Δ object to one or more users based on the AC object. Access control may include generating one or more reports, the contents of which depend on the user receiving the report and / or the access control data in the AC object.

[0289] Figure 3 is a block diagram of a computer system 300 configured to implement data processing control. For example, the system 300 can be configured to ensure that the output of multiple applications meets requirements. The system 300 includes another application 302 that shares the same object model 222 or at least a portion of the object model 222 with the framework 210 and the application 226. For example, the application 226 can be a program for monitoring the production of injection molded products, and the application 302 can be a program for monitoring the production of extruded products. Both programs can benefit from using a software library including external object templates (e.g., Java class files) to represent entities such as polymers, machines, machine parts, sensors, segregates, products, etc.

[0290] During normal operation of the application 226, a plurality of application-generated external objects 304 are instantiated, modified, and deleted within the application 226. The software functions 234 that create, modify, and / or delete the objects 304 are data object change operations that are automatically communicated to the framework 210. Preferably, the automatic propagation of external object changes is implicitly implemented in the source code of the application 226 by utilizing object interdependencies and features of the programming language, such as inheritance and / or event listeners, and by utilizing class templates provided in the form of software libraries. Thus, the developer of the application 226 does not have to explicitly implement the propagation of changes to the application-generated external objects 304 to the framework. In response to being notified of a change to an application-generated external object 304, the framework creates a Δ object 310 that indicates the changed attribute or attribute value and indicates context information, such as the external object whose attribute was changed, the identifier of the application whose external object was changed, the integration transaction in which the change occurred, the previous attribute value, and / or the new attribute value.

[0291] During normal operation of the application 302, a plurality of application-generated external objects 306 are instantiated, modified, and deleted within the application 302. The software functions 308 that create, modify, and / or delete the objects 306 are data object change operations that are automatically communicated to the framework 210. Automatic propagation of external object changes is preferably implemented implicitly in the source code of the application 302 by the developer of the application 302 utilizing object interdependencies and features of the programming language, such as inheritance and / or event listeners, and by utilizing class templates provided in the form of software libraries. Thus, the developer of the application 302 does not have to explicitly implement propagation of changes to the application-generated external objects 306 to the framework. In response to being notified of a change to an application-generated external object 306, the framework creates a delta object 312 that indicates the changed attribute or attribute value and indicates context information, such as the external object whose attribute was changed, an identifier of the application whose external object was changed, the integration transaction in which the change occurred, the previous attribute value, and / or the new attribute value.

[0292] The framework 210 may include modules and / or interfaces 227 for creating and / or modifying RS objects 218, 216, 314, 316, 318, 320, which respectively specify one or more requirements and requirement context information, such as the type of external object and / or attributes affected by the requirement, maximum or minimum thresholds used as criteria within the requirement, an indication of a time period for which the requirement is valid, an indication of one or more clients for which the requirement is valid, an indication of one or more output types for which the requirement is valid (e.g., a report ID), and the like.

[0293] The framework is configured to sequentially store a mix of data objects including data objects 310 , 312 and RS objects in one or more append-only stores 224 , 322 .

[0294] Depending on the embodiment, different schemes for storing RS objects in append-only storage may be used.

[0295] According to some embodiments ( Figure 3 ), all RS objects are stored in each append-only storage. This means that for each append-only storage used by the framework to store Δ objects of one or more applications, a corresponding copy of each RS object is created.

[0296] According to other embodiments, the framework 210 is configured to analyze each created RS object before storing it to determine whether the requirements specified in the RS object are related or potentially related to the data stored in any of the append-only stores. The RS object or RS object copies are then selectively stored in those append-only stores that include the data required to comply with the requirements specified in the RS object. For example, if the append-only store is a Δ object used to specifically store a single external object, and if the RS object includes requirements that are not applicable to the type of external object to which the single external object belongs, then there is no need to store the RS object in the append-only store. For example, if the single external object represents a "polymer container with container ID 57657", and if the requirement involves a requirement to encrypt the name of a customer, then there is no need to store the customer-specific privacy requirements in the append-only store used to store the data objects of the polymer container.

[0297] According to other embodiments, some RS objects include requirements for one or more external objects applicable to two or more different applications, whereby the Δ objects in the different applications are stored in different append-only stores 224, 322. Figure 3 In the example shown, RS objects 218, 216, and 314 apply to data objects of application 226 and data objects of application 302. Therefore, these RS objects are stored in both at least one append-only storage 224 for storing Δ objects of application 226 and at least one append-only storage 322 for storing Δ objects 312 of application 302. RS object 316 is only related to the Δ objects of application 226, so RS object 316 is selectively stored in append-only storage 224. RS object 320 is only related to the Δ objects of application 302, so RS object 320 is selectively stored in append-only storage 322.

[0298] The framework 210 may include one or more first framework functions for generating output 230 that meets the requirements based on the Δ objects stored in at least one append-only storage 224. The framework may also include one or more second framework functions for generating output 340 that meets the requirements based on the Δ objects stored in at least one append-only storage 322. The first framework function and the second framework function may be different framework functions, the same framework function, or may be a mixture of them. This means that some framework functions for providing application-specific outputs (e.g., reports or analysis residencies) and / or some other framework functions for reporting data of two or more different applications and / or analysis functions applicable to data of two or more different applications may be defined.

[0299] Figure 4A and Figure 4B The combined block diagram shows components of a computer system 300 configured to implement data processing control. For example, the system 300 can be configured to ensure compliance with requirements and / or access control, thereby Figure 3 Some components of the system shown in Figure 4A and Figure 4B is shown in more detail in .

[0300] If already targeted Figure 3 As explained, performing a change operation 234, 308 on an application-generated external object 304, 306 automatically triggers the creation of a delta object 310, 312 in the framework, the delta object 310, 312 indicating the exported external object change. Thus, at least some of the application-generated external objects of two or more different applications conform to the shared object model 222.

[0301] According to a preferred embodiment, one or more framework functions 220 executed by the framework on the Δ object to generate output that meets the requirements before and / or after the Δ object is stored in the append-only storage also utilize the shared object model 222 to create, modify and / or delete external objects generated by the framework during their execution.

[0302] For example, the first framework function 402 may be executed to compute a desired output for the first application 226. During its execution, the first framework function 402 creates, modifies, and / or deletes one or more framework-generated external objects 408. Any of these change operations performed on one of the framework-based external objects 402 automatically triggers the creation of a delta object 404 indicating the change derived by the change operation. The delta object 404 created in response to a change to the framework-generated external object 408 is processed by the framework in the same manner as the delta object 310 created by the framework in response to a data change operation performed on the application-generated external object 304, and is saved to at least one append-only storage.

[0303] The second framework function 402' may be executed to compute a desired output for the second application 302. During its execution, the second framework function 402' creates, modifies, and / or deletes one or more framework-generated external objects 410. Any of these change operations performed on one of the framework-based external objects 410 automatically triggers the creation of a delta object 406 indicating the change derived by the change operation. The delta object 406 created in response to a change to the framework-generated external object 410 is processed by the framework in the same manner as a delta object 312 created by the framework in response to a data change operation performed on an application-generated external object 306, and is saved to at least one append-only store.

[0304] The first frame function and the second frame function may be different instances of the same frame function, or may be different frame functions.

[0305] An object model 222 is shared between a framework and two or more applications, and Δ objects are created during execution of one or more framework functions in the same manner as during execution of application internal functions, with the advantage that the generated Δ objects do not reveal whether they are created within the framework or within an application. Therefore, any analysis of the Δ objects stored in at least one append-only store is not affected by the question of whether a particular data change operation on an external object that conforms to the shared data model is performed within the application or within the framework. Therefore, one or more applications can be functionally extended in a sophisticated manner simply by supplementing the framework with additional framework functions. Supplementing the framework will potentially extend the functionality of multiple applications without having to recompile any application and without affecting existing analysis framework functions because the structure of the Δ objects stored in at least one append-only store is not affected by the functional extension as long as the shared data model does not change.

[0306] According to some embodiments, module 227 is configured to create and store AC objects in addition to or as an alternative to RS objects.

[0307] Figure 4C A further append-only storage 225 is shown that also includes some AC objects 221, 229. The Δ objects, RS objects and AC objects are interconnected via cryptographic hashes 331, thereby forming a blockchain. According to some embodiments, at least one append-only storage includes m different append-only storages, which are used to store Δ objects-RS objects and AC objects, respectively, which are derived from or related to a single external object in an application-based or framework-based external object (e.g., a specific natural or legal person, a specific machine, or any other object).

[0308] According to some embodiments, each block is preferably encrypted using an encryption key created by the framework specifically for a single external object among application-based or framework-based external objects, e.g., for a specific natural or legal person, for a specific machine, or any other object. Thus, the payload data as well as the access control data and the on-demand control data are protected as a single consistent data unit, both from manipulation and from accidental disclosure.

[0309] Figure 5 is a block diagram of a computer system 300 according to another embodiment of the present invention. The system 300 includes a framework communicatively coupled to a plurality of clients 504 (eg, remote client applications and / or remote client devices).

[0310] According to a preferred embodiment, the applications 226, 302 are configured not to directly save any internally created or processed data, respectively. Preferably, the applications 226, 302 also do not have any interface that allows clients to directly interact with and retrieve data from the applications 226, 302. Instead, the framework acts as the only means and communication channel for the applications 226, 302 to save and output data. In addition, preferably, each of at least one append-only storage 224, 322 is configured to prohibit any application from accessing its data content, except for the framework 210 and optionally except for additional programs, such as stream applications that can be used by the framework to store Δ objects and RS objects in the append-only storage. Therefore, the framework 210 acts as the only data persistence layer for the application, and further acts as the only data access layer for one or more clients 504 that require data output of the application.

[0311] The framework includes a client interface 502 configured to receive data requests from one or more clients locally or via a network.

[0312] For example, client 504 may send a first request 506 to the interface for obtaining a pseudonymized aggregate production agreement for a set of injection molded products for a particular customer. The framework is configured to identify one or more applications that have generated relevant data, identify one or more append-only stores that include relevant data in the form of Δ objects, and identify one or more RS objects that specify requirements applicable to the request of client 504. The framework is configured to process the Δ objects and RS objects that have been identified as relevant to client 504, and calculate output that meets all requirements that must be considered with respect to client 504 and / or with respect to other technical, organizational, and / or legal environments. Output 230 is returned to client 504.

[0313] Similarly, the above or another client 504 can send a second request 508 to the interface 502 for obtaining a pseudonymized aggregate production agreement for a set of extruded products for a specific customer. The framework is configured to identify one or more applications that have generated relevant data, identify one or more append-only stores of relevant data in the form of Δ objects, and identify one or more RS objects that specify requirements applicable to the client's second request. The framework is configured to process the Δ objects and RS objects that have been identified as relevant to the client's second request, and calculate output that meets all requirements that must be considered regarding the client's second request and / or regarding the technical, organizational and / or legal environment. The output 340 is returned to the client 504.

[0314] For example, identification of related append-only storage, delta data objects, and RS objects may be performed by one or more framework functions 220 as needed in response to receiving the requests 506 , 508 .

[0315] Since the framework is configured to ensure that the data object to be stored and / or the output to be returned conforms to all requirements relevant in the case of the current data request 506, 508 before storing the Δ object in at least one append-only storage and / or before returning the output calculated from the stored Δ object, the system architecture according to an embodiment of the present invention can ensure that all applications integrated by the framework always (indirectly via at least one append-only storage and the framework acting as a data access layer) return reports and other forms of output that fully conform to the requirements to any requesting client. However, the system can flexibly adapt to new requirements and be customized for different clients and use case scenarios.

[0316] According to some embodiments, the computer system includes a blockchain module 503 configured to store a sequence of Δ objects, RS objects, and / or AS objects in each of one or more append-only stores in the form of a blockchain. Optionally, the module 503 encrypts each block to be stored in one of the append-only stores using an encryption key, which is preferably specific to one of the external objects whose data is to be stored in the append-only store. The framework is configured to perform an integrity check of the blockchain before the framework grants access to the attribute change information included therein.

[0317] Figure 6The data content of the append-only storage 224 is shown. The append-only storage can be part of a single physical data storage device that includes multiple data storage areas 602-610 for storing Δ objects 611, 613-616 or RS objects 612, respectively. A sequence of data objects 611-616 is stored on the append-only storage 224 so that the temporal order of physical write operations corresponds to and is reflected by the sequence of adjacent storage areas 602-610 to which the data objects 611-616 are written. The sequence is maintained by the append-only storage. For example, the framework can use an existing streaming program such as Apache Kafka to store Δ objects and RS objects in a streaming database maintained by the streaming program. This means that the physical storage location of a particular data object does not change over time (e.g., due to storage optimization, defragmentation, and / or swap operations performed by an operating system or another program). For example, data objects 611, 612 belong to a first integration transaction T33, while data objects 613-616 belong to a second integration transaction T46. Δ object 611 has the earliest timestamp of all data objects of transaction T33, which is 00:21 on March 21, 2019. Transaction T33 was prepared to commit before transaction T46, so data objects 611, 612 were written to the append-only storage before data objects 613-616 of transaction T46, even though the timestamp of Δ object 613 is earlier than the timestamp of RS object 612. Figure 6 In the illustrated embodiment, the time order in which data objects are physically stored in the append-only storage is represented by the time arrow below, which means that the further to the left the time arrow is, the earlier the data object is written to the append-only storage.

[0318] Storing Δ objects and RS objects in adjacent physical storage areas according to the order of write operations may be advantageous because the read / write heads of one or more physical storage devices constituting the append-only storage 224 can very quickly traverse and read the data objects sequentially in the original order of the data object writing process (here: from left to right) or in the reverse order (here: from right to left) because the read / write heads do not have to "jump" to distant storage locations as indicated by pointers or other types of links.

[0319] For example, according to an embodiment, a sequence of data objects (e.g., Δ objects and RS objects) is stored in an append-only storage such that subsequent data records are written to adjacent storage areas and such that the time sequence of writing the data records is reflected in the sequence of adjacent storage areas including the corresponding data objects. Thus, it is ensured that the order of the data objects originally stored in the append-only storage is maintained even after a long period of time and after various storage management routines that the operating system may perform. Examples of append-only storage are volatile and / or non-volatile data stores managed by various streaming applications and / or queuing systems such as LogDevice, Apache Ignite, Hazelcast, Apache Geode, Infinispan, ehcash, Terracotta, and Apache Kafka.

[0320] Figure 7 The process of reconstructing the state of an application based on a first reconstruction method including generating an undo operation originating from a Δ object is shown. Reconstructing the original or modified state of an external object generated by an application or some of its applications is just an example of a computing task that generates an output based on application data, whereby the output must meet one or more (frequently changing) requirements. For example, Figure 7 The task solved by the illustrated process may be the task of generating output 732 in the form of a set of application-generated external objects whose composition, correlations, and attribute values ​​reflect the state of the application-generated external objects at a selected time, whereby output 732 needs to comply with a number of requirements stored in the form of RS objects in append-only storage, which requirements indicate that some external object IDs and attributes need to be hidden in output 732 in order to comply with data protection requirements. For example, hiding may be performed by pseudonymization, encryption, or anonymization of individual attribute values ​​or external objects in output 732.

[0321] For example, the framework may receive a request to obtain a pseudonymized version of patient data stored in an append-only storage, whereby the pseudonymized version of the patient data should reflect the state of the patient data at any selected time referred to herein as a "selected time". For example, a user or client may send a command or request 734 indicating a selected time 726 in the past. Receiving the selected time 726 may trigger a process of computing an output that needs to meet all currently valid requirements before returning the output to the user or client. The time at which the selected time is received and / or the time at which the reconstruction process begins is referred to as the "current time" 728.

[0322] exist Figure 7In the example shown, reconstruction of a pseudonymized version of an application's external objects at a selected time (i.e., computation of a conforming output based on the application's data stored in append-only storage) is performed in at least two steps:

[0323] In a first step, the framework traverses the append-only storage to read and evaluate all requirements specified in the RS objects included in the append-only storage. It may be that not all requirements are applicable to the task of reconstructing the pseudonymized version of the EO state at the selected time, and / or a complex RS object analysis must be performed to resolve conflicting and overlapping requirements of different RS objects. At the end of this process, the framework knows which requirements must be considered when performing the above-mentioned computation tasks.

[0324] In the next step, at time 728, the framework traverses the data objects in the append-only storage a second time starting from the current version of the external object (EO). For example, each Δ object may include an object type identifier, enabling the framework to identify the instantiated external object based on the object type identifier and the object model 222. The Δ object includes the new attribute values ​​of the EO after the change, so the framework can easily reconstruct the attribute values ​​of the EO at the current time 728 by traversing the Δ objects in the append-only storage and assigning the attribute values ​​to the attributes of the instantiated EO until all attributes are assigned values. When the framework parses the Δ object to extract the attribute values ​​and assign the attribute values ​​to the corresponding EO attributes, the framework checks whether the currently processed attribute and / or EO type needs to be hidden. In this case, the framework generates a modified attribute value that meets the requirement and assigns the modified attribute value to the corresponding attribute of the currently processed EO. For example, a person's name can be replaced by a pseudonym, or can be encrypted.

[0325] Append-only storage 224 includes multiple Δ objects 750-778. The earlier the Δ objects are stored in the append-only storage, the further to the left they appear in box 224. The later the Δ objects are stored in the append-only storage, the further to the right they appear in box 224. The transaction boundary is represented by a vertical dotted line bounded by black circles at both ends. The order of physical storage operations for storing Δ objects in storage 224 is completed according to the timing of the commit ready events of each transaction TR41-TR45. For example, all Δ objects created in transaction TR41 are first written to the append-only storage 224, then all Δ objects 456-462 created in transaction TR42 are written to the append-only storage 224, then all Δ objects 464-468 ​​created in transaction TR43 are written to the append-only storage 224, and so on. The number of Δ objects per transaction can vary. It is also possible that each Δ object corresponds to its own transaction. The boundaries of a transaction may be stored explicitly, for example in the form of a special "start transaction object" and a "commit transaction object" that include the ID of the respective started or committed transaction. Alternatively or additionally, the boundaries of a transaction may also be stored implicitly, for example in the form of a transaction ID that is included in each Δ object (and optionally also in each RS object) and represents the transaction in which the Δ object was created.

[0326] The framework is configured to identify a Δ object 756 in the append-only store that belongs to the most recently committed integration transaction TR44 and is, in addition, the most recently stored Δ object of all Δ objects 770-776 within the integration transaction TR44. Δ objects that are already stored in the append-only store but have been created in an integration transaction that has not yet been committed are not traversed but are ignored because it is not currently known whether the transaction will be successfully committed, or whether the Δ object will be deleted in the event of a transaction failure.

[0327] For example, each Δ object may include an integrated transaction ID in which each Δ object was created and saved. All Δ objects belonging to the same transaction are stored in adjacent storage areas in the append-only storage. Therefore, by sequentially scanning and processing the Δ objects in the append-only storage, the problem of when a particular transaction is committed and when a new transaction is started can be quickly and automatically determined. A transaction boundary is crossed where one transaction is committed when the transaction ID of the currently processed Δ object is different from the transaction ID of the previously processed Δ object. It should be noted that the timestamps of the Δ objects are strictly chronologically ordered only within the transaction boundary. This is because according to the preferred embodiment, the Δ objects are stored as transaction-based Δ object batches, whereby the Δ object batches are sorted according to the chronological order of events when the integration transaction is ready to commit (the completion of the storage of the Δ object can then represent the actual commit event of the integration transaction). Therefore, the chronological order of the timestamps of the Δ objects in the append-only storage originating from many different transactions may not necessarily be the same as the chronological order of the timestamps of all created Δ objects.

[0328] Then, starting with the identified Δ object 776, the framework sequentially traverses the Δ objects in the append-only storage until the downstream terminating Δ object 756 is reached. The downstream terminating Δ object is one of the Δ objects belonging to a TR42 of the integration transaction that is first committed after the selected time 426, and is one of the Δ objects that are first stored in the append-only storage after the selected time, and the traversal includes the downstream terminating Δ object. During the traversal, the framework parses the traversed Δ objects to extract the attribute values ​​of the previous EO and calculate the results to be output. For example, according to the described embodiment, the output to be generated can be a population of EOs that reflects its state at the selected time. This can be obtained by extracting the undo operations from the Δ object and by immediately applying these undo operations to the EO representing the most recent state (starting from the state when the transaction TR44 was committed). Therefore, the framework is able to re-establish the attribute values ​​in the copy of the corresponding EO in the original or modified form to calculate the output that meets the requirements.

[0329] According to an embodiment, each traversed Δ object includes an indication (e.g., an identifier) ​​of one of the external objects of the application that was changed and whose change is represented by the Δ object, and includes one or more properties modified by the change. For each of the one or more properties, the property values ​​before the change event and after the change event are specified in the Δ object.

[0330] In the case where the change operation reflected by the Δ object changes the class used as a template for instantiating data objects in an application rather than an already instantiated external object, the Δ object according to an embodiment of the present invention includes the class ID of the changed class and indicates the structure of the class before and after the change, so that the states of the changed aspects of the class before and after the change can all be derived from the Δ object.

[0331] according to Figure 7 In the illustrated embodiment, the framework is configured to parse each Δ object and create one or more "undo operations" that are respectively configured to undo the changes reflected by the parsed Δ object. In some cases, the undo operation will not specify a completely accurate undo operation if this would result in the generation of a reconstructed EO that does not meet one or more requirements identified in the first step. For example, in the case where a person's name is changed (e.g., due to marriage), and in the case where the output of the person's name must be prevented in order to ensure data privacy, the undo operation will not reconstruct the original name of the person before marriage, but rather reconstruct a pseudonymized version of the name.

[0332] During a sequential traversal of the Δ objects in the append-only store 224, a stream of undo operations is created and automatically applied to the current copy of the EO of the application in its current state 730. Therefore, because the Δ objects can be processed and loaded into memory sequentially, modified and compliant versions 732 of some or all of the EOs are created in a very fast and memory-efficient manner. All data created during and as a result of executing the application does not need to be loaded into memory at once in order to parse the application. Instead, the framework performs a two-step approach that includes first identifying the relevant requirements specified in the RS objects in a first append-only store traversal, and then traversing the append-only store a second time, thereby sequentially processing the Δ objects so as to create output that complies with these requirements identified in the first sequential scan.

[0333] This can significantly increase the speed of computing the desired output 732 while consuming only a very small amount of memory, since the loading of large files into memory and the resulting swapping operations are avoided. A modified and desired copy of some or all of the EO is returned as output 732 to the client that has submitted the command 734, whereby the output represents the state of the EO at the selected time 726, and the output does not contain any data that needs to be kept confidential.

[0334] The described method for generating output that meets requirements based on application data may be advantageous because this method is not only highly flexible in terms of the number and type of output requirements, but is also much faster and consumes less memory than many existing methods for generating output based on application data. This is because due to the way the data is stored in append-only storage, the processing of the application data can be performed in a strictly sequential and transactionally preserved manner. Undo operations can be extracted and immediately performed on the current EO copy 732, while the Δ objects stored in a sequence of adjacent physical storage areas are processed sequentially in a transactional context that ensures data consistency. There is no need for the read / write head of the physical data storage device to jump to different, spaced-apart storage areas to collect all the information required to calculate the output 732.

[0335] It should also be noted that, according to an embodiment, the described manner of reconstructing the state of an EO at a selected time in modified or unmodified form not only ensures requirement compliance, but also ensures minimal memory consumption and transactional consistency.

[0336] For example, traversing the append-only storage from right to left by the read / write head includes first reading and parsing Δ object 776 and creating a first undo operation, reading and parsing Δ object 774 and creating a second undo operation, then reading and parsing Δ object 772 and creating a third undo operation, and so on until reaching Δ object 770. The undo operations created for the Δ object of TR44 are bound to the first undo transaction and executed together on data representing the current state of a set of EOs (e.g., an OLTP database). The first undo transaction is executed by the framework according to ACID principles. Then, the Δ object of transaction TR43 is parsed to create three undo operations to be bound to the second undo transaction.

[0337] As used herein, an "UNDO operation" is a command or function created based on the EO change information stored in a Δ object, and if applied to any data entity (e.g., a data object or class or database record) representing an EO whose changes are reflected in the Δ object, undoes these changes in the data entity. The data 730 used as a basis for applying the undo operation may be, for example, an EO of a copy of an application reflecting the state of the application at the current time. Alternatively, the data 730 may be an OLTP database including a table with data records representing the state of the application at the current time. Likewise, the data 732 resulting from the application of the undo operation may be a copy of the application or an OLTP database reflecting the state of the application at a selected time.

[0338] For example, the framework can be configured to create and execute an undo command like this:

[0339] Sequentially read all delta objects associated with a specific integration transaction (trx0–1) whose changes are undone from the append-only store;

[0340] Open a refactoring transaction on the data foundation 730;

[0341] For each read delta object for this particular, "saved" integration transaction:

[0342] Extract the object Id from the Δ object,

[0343] retrieving one of the data records (e.g., an XML document, a JSON document, a table, or a table row) in a data foundation 730, the data foundation 730 including the extracted object id,

[0344] Identify the delta object type of the retrieved delta object (changePropertyDeltaObject, addAssociationObjectDeltaObject, etc.);

[0345] The reconstruction transaction is committed and completed; therefore, data foundation 730 has the precise state of (trx0-1); and

[0346] Repeat the above steps for all delta objects created and stored within the integration transaction (trx0–2) until the start timestamp of (trx0–x) is less than or equal to the selected time.

[0347] Since Δ objects and RS objects (not corresponding to restore or undo operations) are stored in the storage area in strict sequence and their positions do not change during the storage period, the read / write head can read out and immediately process all the information required for the original or on-demand reconstruction (also called "restore") of the application state very quickly by performing a sequential scan of the physical storage medium.

[0348] Embodiments of the present invention may allow data changes stored in 5000 integrated transactions to be traversed and processed in only 1 second on a computer system with standard hardware equipment. This is because the reconstruction is based on the sequential scanning of adjacent physical storage areas and the immediate application of information obtained by linearly scanning one or more storage devices. According to a preferred embodiment, the data obtained during the scanning process has been organized in the form of transactions, and the "boundaries" (start and commit events) of the transactions correspond to the integrated transactions that were originally used to apply and save the Δ object changes. For example, the "boundaries" of the integrated transaction may be derived from the transaction ID of the traversed Δ object. Therefore, the undo / recovery operations obtained during the scanning process may be immediately performed on the corresponding data basis in a transaction-based manner, thereby ensuring that the state of the data basis is reconstructed in a consistent manner according to the ACID standard.

[0349] Figure 8 The process of reconstructing the state of the application based on the recovery operation from the Δ objects 850-880 is shown. This process is similar to Figure 7 The process shown is different in that the traversal starts from the oldest stored Δ object 850. During the traversal of the Δ objects, recovery operations representing the changes indicated in the traversed Δ objects are created and immediately applied to data 832 reflecting the original (or previous) state of the EO of the application. The data 832 can be (for example) a copy of the application or an OLTP database representing the state at a previous time (which can be called a backup time). By applying the recovery operations to the data 832 until a selected time 826 is reached, the state of the EO at the selected time can be reconstructed, whereby the state and the attribute values ​​associated with the state can be modified to conform to the requirements specified in the RS object.

[0350] The "REDO operation" used in this article is a command or function created based on the external object change information stored in the Δ object, which, if applied to any data entity (for example, a data object or class or database record) representing EO (the changes to which are reflected in the Δ object), reapplies those changes to the data entity.

[0351] Fig. 9 Various sub-modules and functions of a framework according to an embodiment of the present invention are shown.

[0352] The framework may include an interface for receiving requests from one or more clients for reports, analysis results, or other forms of output computed based on application data from one or more different applications.No client has direct access to only the storage area or any application's appends.

[0353] The framework shares an object model 222 with one or more applications that have created data to be analyzed and returned. The framework also includes a plurality of framework functions 220.

[0354] For example, the framework functions may include framework functions 902, which are functional extensions of the business logic of one or more applications. For example, the framework functions 902 may be configured to perform tasks such as value standardization, value calibration, data aggregation, reporting, unit conversion, currency conversion, generation of technical or security alerts, logging, encryption, information hiding, pseudonymization, etc. At least some of the framework functions 902 are configured to calculate outputs, such as one or more standardized values, calibrated values, aggregated results, alerts, reports, log files, encrypted or pseudonymized reports or analysis results, etc.

[0355] Additionally, or alternatively, the framework functions may include one or more framework functions 904 configured to perform complex analysis, such as complex statistical analysis. For example, the analysis may involve calculation of medical diagnoses, calculation of recommended treatment options, simulation of complex technical systems, aggregate prices, etc. At least some of the framework functions 904 are configured to calculate outputs, such as complex analysis results.

[0356] In addition, or alternatively, the framework function may include one or more framework functions 906, which are configured to create and / or modify RS objects and / or to enable a user or client to create and / or modify existing RS objects. For example, the framework function 906 can implement a graphical user interface (GUI) displayed on a screen of the computer system 200, 300, and the computer system 200, 300 enables a user to modify existing requirements and / or create new requirements via the GUI. Preferably, the GUI is configured to enable a user to create or modify requirements without applying any programming skills. The framework function 906 stores the newly created or modified requirements in the form of one or more RS objects in at least one append-only storage.

[0357] In addition, or alternatively, the framework functions include one or more framework functions 908 that are configured to enable one or more remote clients to create and / or modify one or more requirements. For example, a client interface for receiving data requests from one or more clients may further include an interface for receiving requirement requests. The requirement request specifies one or more requirements and preferably also specifies the requirement context (attributes, extended object types, applications that should comply with the requirements, and / or time). In response to receiving the requirement request, the framework function 908 creates one or more RS objects and stores them in at least one append-only storage.

[0358] According to an embodiment, one or more framework functions of one or more of the above subgroups 902, 904 are configured to identify in a first step all RS objects in at least one append-only storage, all RS objects being related to a current task of storing a new Δ object in the append-only storage or a current task of calculating and outputting based on an already stored Δ object. This step may include resolving conflicts between two or more different RS objects stored in the append-only storage at different times.

[0359] Then, in a second step, the one or more Δ objects to be stored are evaluated according to all requirements identified as relevant in the first step and modified if necessary so that they comply with the relevant requirements. Likewise, where the current task is to compute an output (e.g., automatically or in response to a client's request for data), all data objects used as the data basis for computing the output are evaluated according to all requirements identified as relevant in the first step and modified if necessary so that the computed output complies with the relevant requirements.

[0360] Furthermore, according to an embodiment of the present invention, the framework includes a module 910 for managing integration transactions, a module 912 for creating and storing Δ objects, and / or a GUI 914 that enables a user to create and / or modify RS objects.

[0361] Fig.10 The data content of the Delta objects of five different types 1002 - 1010 of Delta objects are shown according to an embodiment of the present invention.

[0362] The framework for creating Δ objects includes a set of predefined templates for each of a number of supported Δ object types. For example, a template can be a combination of a Java interface method and a Java class file that implements the interface method, and can be used to create a Δ object that includes property values ​​defined for the template. Fig.10 In the example embodiment shown, the framework includes a template for a “createObjectDeltaObject” Δ object type 1002, a template for a “deleteObjectDeltaObject” Δ object type 1004, a template for a “changePropertyDeltaObject” Δ object type 1006, a template for an “addObjectAssociationDeltaObject” Δ object type 1008, and a template for a “removeObjectAssociationDeltaObject” Δ object type 1010.

[0363] According to an embodiment, any creation of a new external object in the application 226 triggers the creation of a new Δ object of type 1002 by the framework.

[0364] Each delta object of type 1002 includes an indication of its type ("createObjectDeltaObject"), which may also reflect the type of change operation performed in the application that triggered the creation of the delta object. In addition, each delta object of type 1002 includes a timestamp indicating the time when the new external object was created in the application, a transaction ID indicating the integration transaction in which the change operation occurred and in which the delta object was created, an object type indicating the type of external object created (e.g., "customer"), and a unique identifier (object ID) of the new external object created (here: a new instance of the class "customer").

[0365] Each delta object of type 1004 includes an indication of its type ("deleteObjectDeltaObject"), which also reflects the type of change operation performed in the application that triggered the creation of the delta object. Each delta object of type 1004 includes the information already described for delta object type 1002, namely, timestamp, transaction ID, object type, and object ID. In addition, each delta object of type 1004 includes a list of properties and associations and corresponding data values ​​representing the latest state of the data object and its associations at the time of being deleted ("P&A List").

[0366] Each delta object of type 1006 includes an indication of its type ("changePropertyDeltaObject"), which reflects the type of change operation performed in the application that triggered the creation of the delta object. Each delta object of type 1006 includes the information already described for delta object type 1002, namely, timestamp, transaction ID, object type, and object ID. In addition, each delta object of type 1006 includes an identifier of the property whose change triggered the creation of the delta object, and includes the new value assigned to the property at the time of the change.

[0367] Each delta object of type 1008 includes an indication of its type ("addObjectAssociationDeltaObject"), which reflects the type of change operation performed in the application that triggered the creation of the delta object (here: adding an association between two external objects to one of the two external objects). Each delta object of type 1008 includes the information already described for delta object type 1002, namely the timestamp, transaction ID, object type and object ID of the data object to which the association is assigned. In addition, each delta object of type 1008 includes the identifier or name of the association added to the data object and the identifiers of other data objects that are linked to the above data object by adding the association.

[0368] According to an embodiment, a data object in an association of a particular association type (IndexedAssociation) has a particular position in the list of associated objects, for example, at position 5. This is represented by "AddedObjectIdPosition." Additional association types and their changes may also be stored as delta objects.

[0369] Each delta object of type 1010 includes an indication of its type ("removeObjectFromAssociationDeltaObject"), which reflects the type of change operation performed in the application that triggered the creation of the delta object (here: removing a data object from an association between two data objects). Each delta object of type 1010 includes the information already described for delta object type 1002, namely timestamp, transaction ID, object type and object ID of the data object from which the association was removed. In addition, each delta object of type 1010 includes an identifier or name of the association that was removed and identifiers of other data objects that were linked to the above data object through the removed association.

[0370] Other embodiments of the invention may support fewer or additional delta object types, or support delta object types with slightly different data content, and include corresponding sets of templates. In any case, each template should specify the information needed to enable a program that reads and parses a delta object (e.g., framework 210) to create undo or redo operations that re-execute or undo the data object changes specified in the delta object. For example, in some embodiments, a changePropertyDeltaObject instance may include, in addition to the new property values, the property values ​​of the data object before the change operation took effect.

[0371] According to some embodiments, the set of Δ object types supported by the framework further includes Δ object types for creating new classes, for deleting existing classes and / or for modifying the structure of existing classes (e.g., adding new properties to existing classes) and / or for removing properties of existing classes.

[0372] For example, a delta object of type "changeObjectDeltaObject" may be created in response to a command "customer.name().set("test");" executed by a data object of an application. The execution of the method "set("test")" results in a call to an abstract interface method "changeObjectDeltaObject" 1006 provided by the framework. The interface method for creating a new delta object of type 1006 may be, for example:

[0373]

[0374] Whenever an external object in the application sets the data value of another external object, the interface method createChangePropertyDeltaObject can be automatically called. The interface method can be implemented by one or more classes (not shown) provided by the framework.

[0375] Fig.11 The creation of a Δ object by a framework 210 implemented in some embodiments of the invention is shown.

[0376] The properties of external objects in the application 226 are not implemented in the form of primitive data types such as strings, integers, floating point numbers, Boolean values, etc., but in the form of generic data objects and corresponding classes (hereinafter referred to as "Properties") that are functionally linked to the framework 210. For example, the framework may include a class "Properties" and may be used as a class library during the development and programming of the application 226. Therefore, according to an embodiment, all properties of all data objects of the application 226 are instances of the class "Properties" or inherit some features and / or functions provided by the abstract class "Properties", and thus the class "Properties" is provided by the framework 210.

[0377] This feature can be very advantageous because any property changes within the application 226 are automatically communicated to the framework 210, which is responsible for instantiating a new Δ object instance based on the corresponding type of change operation and for specifying in the new Δ object which property of the external object was modified and the new property value of the external object (at least for all types of change operations involving modifying the type and / or value of a property (also called a "property"). Since any new property is an instance of a property class provided by the framework, the framework inherently "knows" when a property value of an external object is changed in the application.

[0378] These features relieve the programmer of the burden of ensuring that every external object change in the application is properly propagated and in append-only storage, since any property change operation must be and is fully automatically associated with the creation of a new instance of the property class in the framework, thereby automatically triggering data processing routines within the framework associated with the creation of a corresponding Δ object within the framework.

[0379] Furthermore, these features relieve the programmer of the burden of ensuring that any relevant external object changes are explicitly covered in reporting routines, since the Δ objects automatically created by the framework in response to any change operation involving the creation of a new attribute class instance implicitly represent the most fine-grained change log one can think of. The append-only store can be used as an automatically generated complete log or report that can be evaluated by an analysis program developed for any analysis problem that may be of interest to the operator of the application.

[0380] Programmers are also largely relieved of the burden of considering many technical, organizational and / or legal requirements, which may change frequently, because the task of maintaining the Δ objects and / or any output returned to the client based on the Δ objects conforms to a large and changing set of requirements is delegated to the framework and framework functions.

[0381] In summary, the framework can provide a great advantage in that the programmer using the framework when creating an application does not have to worry about and does not have to write explicit routines or modules to ensure that all changes to data objects and / or associations and / or classes within the application are fully saved and / or fully meet multiple current or future requirements at runtime. The programmer only needs to ensure that the operations that cause changes to external objects, associations and / or classes in the application use the classes and / or interfaces provided by the framework, thereby automatically notifying the framework of any changes to external objects, external object associations or classes in the application, so that the corresponding Δ objects can be automatically created and saved in only append-only storage in a manner that meets the requirements. This greatly promotes and accelerates the development of applications, and improves the quality and reliability of programs and the quality and reliability of the way in which applications are saved, because the preservation of changes in the application is inherently and fully automatically implemented by simply utilizing the various classes and functions provided by the framework. The task of ensuring that any program output meets a large number of frequently changing requirements is also assigned to the framework and framework functions.

[0382] In other words, use of the framework 210 according to embodiments of the present invention provides for industrialization and automation of large portions of the software development process, thereby greatly facilitating the quality, reliability, requirements compliance, and completeness of preservation and reporting of the state of an application.

[0383] Hereinafter, specific examples will be described to show how a programmer can use framework 210 at design time of application 226 to automatically propagate external object or class changes in application 226 to framework 210 that occur while application 226 is running.

[0384] Latest method feature changes

[0385] An existing method for modifying object properties ("attributes") of a Java class instance of class "ExampleClassic" is implemented as follows:

[0386]

[0387] In the example given above, the creation of a new ExampleClassic instance and the access to one of its properties (attributes) (here: name) are performed by the following method call: ExampleClassic exampleClassicInstance = new ExampleClassic();

[0388] exampleClassicInstance.setFirstName("Peter");

[0389] Framework-based approach to feature changes

[0390] In contrast, according to an embodiment of the present invention, modification of object properties of a Java class instance of the class "ExampleNew" will be implemented based on a generic attribute class instance rather than an atomic property string value, as shown below:

[0391]

[0392] In the examples given above, the ExampleNeu interface and the classes implementing the ExampleClassic instance may be included in and provided by the application, while the property classes are provided by the framework.

[0393] According to an embodiment, the property class provided by the framework includes a "set" method that is called whenever a new instance of the property class is created and assigned to a property instance in the application. The call to the "set" method of the property class instance triggers the creation of a Δ object.

[0394] According to an embodiment, any change operation that creates, modifies and / or deletes one of the external objects in the application automatically triggers the framework to create a Δ object, so that the external objects of the application (or at least external objects that implement serializability (Serializable) or are otherwise marked as "transient") include attributes (also called "variables" or "properties") in the form of class instances of at least one class provided by the framework. The at least one class provided by the framework is called, for example, a "property" class. The property class provided by the framework includes a "set" method, which is called each time a new instance of the property class is created and assigned to a property instance in the application. The call to the "set" method of the property class instance causes the framework to create a Δ object.

[0395] According to an embodiment, at least one property of at least one external object indicates an association (also referred to as a "relationship") between two external objects. By representing external object associations in the form of external object properties, embodiments of the present invention may allow external object associations and external object association changes to be saved in the form of Δ objects.

[0396] According to an embodiment, the "set" method of the framework's property class is signed using the certification authority's signing key. The digital signature is associated with the certification authority's certificate. The signature of the set method can allow verification of the integrity of the method and ensure that the code has not been altered or corrupted since it was signed. This can help users and other software determine whether the framework can be trusted.

[0397] For example, access to one of its attributes (properties) (here: name) of any external object that is an instance of the ExampleNew implementation class can be performed by the following method call: ExampleNew exampleNewInstance = uow.create(ExampleNeu.class);

[0398] exampleNeuInstance.firstName().set("Peter");

[0399] Thus, uow is an object provided by the framework responsible for creating and managing a single integration transaction. The call to the setter method of the characteristic class in the application (here: firstName().set("Peter")) fully automatically triggers the creation of a delta object of type changeObjectDeltaObject in the framework.

[0400] Representing class attributes as instances of generic class "traits" provided by the framework has the following advantages:

[0401] The source code should be more compact;

[0402] Since the properties (attributes) of external objects implement the class "Properties", and all method calls for changing properties run via the class "Properties" of the framework 210, every change in the value of a property can be recognized very easily and completely automatically by the framework and used to create a Δ object; in the traditional model, properties are manipulated directly with setter methods, without another program / framework being able to interfere with this process (no time-consuming "tricks"). This technical difficulty is avoided by implementing object properties as instances of the framework's generic "Properties" class;

[0403] Features, and in particular their dynamic behavior, can be easily extended at any time, for example, by test methods like "notNull" or complex test protocols or by complex evaluation routines for reporting purposes, without having to change the source code of the application. It is sufficient to extend the source code of the framework by corresponding functions. Thus, highly complex software can be supplemented during operation by checking and reporting functions at a fine-grained level (i.e. at the property level) without having to change or recompile the source code. A change in a single class or a few classes in the framework is sufficient and such a change immediately has global validity for all applications developed based on the framework.

[0404] exist Fig.11In the example shown, the application 226 at runtime includes an external object 926, an instance of the car class, whose attribute values ​​928, 930, 932 indicate that the color of the car is cherry red, the registration year is 2012, and that the car is owned by a person named "Smith". The attributes of the car instance can be modified by other external objects by executing the following method calls specified in the source code 942 (EO1.setOwner("Lee"); and EO1.setColor("green")), for example, the external object 938 is an instance of the class "person" and represents a person with fleet manager capabilities (attribute 940).

[0405] For each of the plurality of predefined data change events, the framework includes a corresponding template class (e.g., interface class) and / or an interface method for creating a Δ object. For example, the framework may include one or more general interface classes 950, and the one or more general interface classes 950 include one or more general interface methods 952-964, respectively, and the one or more general interface methods 952-964 are used to create a new external object 926, modify the properties of an existing external object, delete an existing external object, delete a class at runtime of an application, create a class at runtime of an application, and modify the structure of a class at runtime of an application.

[0406] When an external object 938 executes a method call EO1.setOwner("Lee"), a new instance of the class "Property" provided by the framework is created. The call to the "setOwner" function provides information about the call to EO7938, the time of the call, the new value of the property ("Lee"), and the property to be changed to the framework ("owner"). The framework not only creates a new instance of the "Property" class required by the application to change the owner property of EO1, the framework also creates a new instance of the change property class using the abstract changeProperty interface 956 provided by the framework, or creates a new class instance. This new class instance is filled with contextual information about the property change (which property was changed, when the change was made, the external object that caused the change, the new property value, etc.) and is used as a new Δ object 972.

[0407] The external object 938 may also call the method EO1.setColor("green"). This call triggers the creation of a property instance for the new color "green" and creates a new Δ object 970 in the framework.

[0408] According to an embodiment, one or more external objects of the application are text-based external objects. The text-based external object used in this article is an external object defined in a text-based format (such as XML or JSON), and the external object does not represent a class instance of a class written in an object-oriented language. For example, the application can be Java, and many external objects whose changes are saved by the framework can be Java class instances. Some external objects are XML text objects or JSON text objects. In order to save text-based external objects, the following method can be used: Example New example New Instance = uow.create ({ <text-object> <object-id> 82328368< / object-id> <car-name> Tesla383< / car-name> <year-of-reg> 2018< / year-of-reg> < / text-object>});

[0409] Therefore, although preferably all external objects of the application are instances of classes written in an object-oriented programming language, some embodiments of the present invention can also be implemented based on non-object-oriented programming languages ​​and / or based on external objects provided in the form of text-based objects.

[0410] Fig. 12A The management of integrated transactions in the interoperation between the framework 120 and the application 226 is shown. Fig. 12A In the illustrated embodiment, the Δ objects and RS objects are stored in a single append-only storage.

[0411] exist Fig. 12A In the illustrated embodiment, the framework generates, manages, and closes integration transactions after a commit event, whereby operations executed within the application act as triggers to begin and / or terminate integration transactions. Delta objects created within an integration transaction are stored in a single append-only store according to the chronological order of the commit ready events of the integration transactions in which they were created, as well as their respective timestamps.

[0412] For example, the framework 210 may implement a function that can receive one or more method calls as arguments. Each call to the function by an external object of the application triggers the creation of an integration transaction, the existence of which is tied to the execution of the called function. The method call provided as an argument is a change operation (e.g., create a new external object, modify the properties of an existing external object, delete an existing external object, create a class, delete a class, modify a class).

[0413] This may be advantageous because when the function returns, the transaction context of the integrated transaction created by the framework when calling the function is automatically closed (by committing or undoing actions). Therefore, it is impossible for the programmer to forget to explicitly close the integrated transaction. In addition, since one or more change operations performed within the integrated transaction are provided as arguments to the function, it is implicitly ensured that each change operation is performed within the integrated transaction. As long as the programmer of the application program specifically specifies any changes to data objects or classes as arguments to the function, it is ensured that no change operations can be performed outside the integrated transaction. This can ensure the transactional consistency of each single change operation, as well as the complete persistence of any changes in the append-only storage. The programmer does not need to explicitly open or close the transaction context, nor does it need to explicitly assign the change operation to a specific integrated transaction. It is only necessary to provide the change operation as an argument to the interface function.

[0414] For example, a function adapted to receive one or more change operations as arguments may be a function of a functional interface. In Java, the function may be a so-called Λ function, whereby each call of the Λ function is executed in a corresponding integrated transaction.

[0415] The application or a data object included therein can call the framework's Λ function for the first time, thereby triggering the framework to generate the first integration transaction T1. After the transaction context T1 has been opened, the A1 attribute of the external object Car 673 is changed in the application, and then the A2 attribute of the same external object is changed. Then, another attribute A4 in the external object Car 866 is changed, and finally the attribute A5 of the external object Car 673 is changed. Fig. 12A , the changes made to the external objects in the transaction context of the application T1 are represented by the first row 1250. The call of the Λ function within the closing application represents a trigger event, which triggers the commit event of the integrated transaction T1 represented by the concentric double circles within the frame.

[0416] In addition, the application may call another Λ function of the framework, thereby triggering the generation of a second integration transaction T2, the transaction context of which is represented by row 1252. After the transaction context T2 has been opened, the A1 property of the external object car 556 is changed in the application, and subsequently the A2 property of the external object car 445 is changed. Closing the call to another Λ function within the application represents a triggering event that triggers the commit event of the integration transaction T2.

[0417] Furthermore, the application may call a further Λ function of the framework, thereby triggering the generation of a third integration transaction T3, the transaction context of which is represented by row 1254. After the transaction context T3 has been opened, the external object car 673 is deleted in the application, and the further Λ function is closed, thereby triggering a commit event of the integration transaction T3.

[0418] According to an embodiment, the framework can manage various different integration transactions of the same application at the same time. One integration transaction can be started while another integration transaction is not yet completed. The framework ensures that there are no conflicts and that two transactions do not manipulate the same external object at the same time. The framework will only commit the transaction when all delta objects created in the transaction are successfully stored in the append-only storage (not shown here).

[0419] The events shown on row 1256 are listed in the chronological order of the corresponding data object changes and the timestamps of the Δ objects created respectively. Each change of a data object corresponds to an external object change event EV, which in turn triggers the creation of a Δ object, which in turn includes an identifier of the integrated transaction in which the Δ object is created. However, the sequence in which the Δ objects are created in the framework does not necessarily correspond to the chronological order of the physical storage of the Δ objects in the append-only storage. Instead, the framework is configured to perform the storage of the Δ objects according to the order of the commit-ready events of the Δ objects, so that the timestamps of the Δ objects stored in the append-only storage 224 are strictly sorted in chronological order only within a specific transaction context. This is shown in the append-only storage 224: since the commit-ready event of transaction T2 occurs earlier than the commit-ready event of transaction T1, the corresponding Δ objects EV2 and EV4 of transaction T2 are also stored before the Δ objects EV1, EV3, EV5, EV6 of transaction T1, although the transaction context of T1 starts earlier than the transaction context of T2. The temporal order of expected commit events originates from and is determined by the source code of the application, where individual Λ functions are called in one or more different threads, whereby within a thread, a new transaction context may be opened only after an open Λ function call is completed.

[0420] According to an embodiment, the RS object is created in the context of one of the integration transactions and is stored in at least one append-only storage at a location within the Δ object that corresponds to the time when the RS object and the Δ object were created. For example, after the Δ object is created for car445, the RS object is created in a frame within transaction T2. ​​Therefore, the RS object is stored in the append-only storage together with the Δ object created within transaction T2 and after the Δ object DeltO4car445 is stored. Similarly, before the Δ object Delt07car673 is created, the RS object is created in a frame within transaction T3. Therefore, the RS object is stored in the append-only storage together with the Δ object created within transaction T3 and before the Δ object DeltO7car673 is stored.

[0421] Fig. 12B Transaction-based storage of Δ objects and RS objects in multiple data object-specific append-only stores according to another embodiment is shown. Δ objects created within an integration transaction are stored in multiple append-only stores 1220, 1222, 1224, 1226. Each external object of the application corresponds to a corresponding one of the append-only stores. All changes performed on an external object in the application are stored in the form of a Δ object stream in an append-only store assigned to the corresponding external object. For example, all external object changes of the external object "Car 673" are stored by the framework in the append-only store 1220 as a Δ object stream 1230. All external object changes of the external object "Car 556" are stored by the framework in the append-only store 1222 as a stream 1232 of Δ objects. All external object changes of the external object "Car 866" are stored by the framework in the append-only store 1224 as a stream 1234 of Δ objects. All external object changes of the external object "Car 4456" Δ object stream 1236 are stored by the framework in the append-only store 1226. The framework is configured to cache and distribute newly created delta objects across different streams and append-only stores, such that a delta object describing a change to a particular external object is selectively stored in a particular append-only store among a plurality of append-only stores. Thus, for example, each external object may be an instance of a class used as a template for creating the external object, or may be the class itself. The external objects of an application may include class instances and individual classes, where a class may be, for example, a class file in accordance with the Java programming language.

[0422] In the described embodiment, some RS objects created in the framework are related to all types of external objects and are therefore stored in each append-only store in the form of a corresponding RS object copy.

[0423] For example, a copy of the RS object created in integration transaction T3 is stored in each append-only storage. In addition, a copy of the RS object created in integration transaction T2 is stored in the corresponding position in each append-only storage. In addition, some RS objects can be determined to be only related to the Δ object related to the change of a specific external object (not shown). In this case, the framework can selectively store the RS object in one of the append-only storages, which only receives the Δ object of the specific external object.

[0424] from Fig. 12A and Fig. 12B It can be inferred from the comparison of that, according to different Δ object distribution modes, the same external object changes and transaction sequences can be stored in one or more append-only stores. In both modes, the transaction context is preserved, for example, in the form of a transaction ID included in the Δ object. Due to the improved scalability, Fig. 12B The embodiment shown in is preferred. According to an embodiment, the framework may store delta objects in one or more append-only stores directly or via an additional program (eg, a streaming application such as Apache Kafka).

[0425] According to some embodiments, the application 226 is written in the object-oriented programming language Java, and the framework 210 includes a plurality of interface methods in the form of Java Λ functions (also referred to as "Λ expressions").

[0426] Λ functions were added in Java 8. Λ functions basically represent instances of functional interfaces (interfaces with a single abstract method are called functional interfaces. Example is java.lang.Runnable). Λ expressions implement a unique abstract functionality and hence implement functional interfaces. Λ functions are able to treat functionality as method arguments or code as data. They can be created without belonging to any class. Λ functions can be passed around like objects and executed on demand. Λ expressions basically represent instances of functional interfaces (interfaces with a single abstract method, example is java.lang.Runnable). Λ expressions implement a unique abstract functionality and hence implement functional interfaces.

[0427] However, other embodiments of the present invention may be implemented using other programming languages. A skilled programmer may also implement the examples and embodiments described herein in other programming languages, in particular in other object-oriented programming languages, based on the programming language Java.

[0428] The call "("add_data", (uow)->{"}" (so called Λ function in Java) opens the transaction context of the integration transaction. This call can be made by the data object of the application, but the called Λ function itself is preferably provided as part of the framework 210. The term "uow" here represents the name of a single integration transaction that receives the data, in this case a "unit of work". In some embodiments, the name and / or ID of the transaction can be provided as an argument to the method call.

[0429] Use the method call "uow.create(Customer.class);" to create a customer object in the integration transaction uow.

[0430] The expression "customer.name().set("test");" sets the customer's property name to "test" and creates a property object internally in the framework. The property object has a "set" method that includes the new name "test" and includes the identifier of the integration transaction uow, or is otherwise assigned to the integration transaction uow.

[0431] When the Λ function is retained (terminated), the integration transaction uow is automatically closed and committed by the framework and, in case of errors, all changes are discarded.

[0432] The Λ function (which provides the uow transaction context) is implemented by the framework 210. When the uow transaction is closed / ready to commit, the framework calls the abstract driver interface of the append-only storage and opens a Δ subtransaction. In the context of the Δ subtransaction, the Δ object stream created in the integrated transaction uow is transferred to the append-only storage and saved therein. If the storage in the append-only storage is successful, the Δ subtransaction commits. Optionally, the framework can open other subtransactions, for example, for storing Δ objects in addition to another data store (e.g., an OLTP data store or a backup append-only storage). If all of the updates are executed successfully, the subtransaction commits and closes.

[0433] If all subtransactions of the integrated transaction defined by the Λ function commit successfully, an OK is returned to the application, the integrated transaction commits, and the changes in the application become visible to other external objects in the application. If an error occurs, the framework triggers a rollback in the application, the append-only storage, and all other data stores used, for example, by other subtransactions for storing other copies of the Δ object. However, if an error occurs, all data that led to the termination is still available. This greatly improves the traceability of error events.

[0434] In the source code example provided below, the "repository" is the framework service that is configured to control the creation, maintenance, commit, and rollback of an integration transaction and all subtransactions. The name "uow" / "UnitOfWork" is an identifier for a specific integration transaction.

[0435]

[0436] Using "unitOfWork.create", a new object of the client class is created. In addition, the framework automatically creates a Δ object of type "createObject" in the background.

[0437] For example, a Delta object of type "createObjectDeltaObject" is created with attributes such as timestamp, class (in the example: Customer.class) and / or object ID, e.g. Fig.10 An instance of the createObjectDeltaobject 1002 template shown in . The command "customer.name().set("test");" results in the creation of a delta object of type "changePropertyDeltaObject" that includes a timestamp, an object ID, a property ID, and a new property value.

[0438] The command "customer.name().set("test");" results in the creation of a Delta object of type "changePropertyDeltaObject", e.g. Fig.10 An instance of the changePropertyDeltaObject1006 template is shown in .

[0439]

[0440]

[0441] Reference Number List

[0442] 101-110 Step 200 Computer System

[0443] 201 Processor 202 External object generated by application 204 External object generated by application

[0444] 206 Change Operation

[0445] 207 Change Operation

[0446] 208 Change Operation

[0447] 210 Frame

[0448] 211 Δ Object

[0449] 212 Δ Object

[0450] 214 ΔObject

[0451] 216 RS object

[0452] 218 RS object

[0453] 220 Framework Functions

[0454] 221 AC Object

[0455] 222 Object Model

[0456] 224 Append-only storage

[0457] 226 Application Program AP1

[0458] 227 RS Object Generator

[0459] 229 AC Object

[0460] 230 AP1 meets the demand output

[0461] 234 Application Functions

[0462] 236 Framework Interface

[0463] 300 Computer Systems

[0464] 302 Application AP2

[0465] 304 External object generated by the application of AP1

[0466] 306 External objects generated by the application of AP2

[0467] 308 AP2 application function

[0468] 310 Δ object used for change operation in AP1

[0469] 312 Δ object used for change operation in AP2

[0470] 314 RS object

[0471] 316 RS object

[0472] 318 RS object

[0473] 320 RS object

[0474] 331 Cryptographic Hash

[0475] 340 AP2 meets the demand output

[0476] 402 Framework Function

[0477] 404 Δ object used for frame change operations

[0478] 406 Δ object used for change operations in the framework 408 External object generated by the framework

[0479] 410 Framework generated external object

[0480] 412 Δ Object

[0481] 414 ΔObject

[0482] 416 Framework-generated external object

[0483] 418 Framework-generated external objects

[0484] 502 Client Interface

[0485] 503 Blockchain Module

[0486] 504 Client

[0487] 506 Data request from AP1

[0488] 508 AP2 data request

[0489] 602-610 Append only adjacent storage area 611 Δ object in storage

[0490] 612 RS objects

[0491] 613-616 Δ Object

[0492] 726 Selected time

[0493] 728 Current time

[0494] 730 External object with current state

[0495] 732 External object with reconstructed previous state

[0496] 734 Commands with selected time

[0497] 750-778 Δ Object

[0498] 902-908 Framework Functions

[0499] 910 Module for managing integration transactions

[0500] 912 Module for creating and storing Δ objects

[0501] 914 GUI

[0502] 916 Module for reconstructing the state of external objects

[0503] 1002-1010 Different types of Δ objects

[0504] 926 Data object "EO1"

[0505] 928-930 EO1's attribute values

[0506] 934-936 EO1 Method

[0507] 938 Data Object E07

[0508] 940 B07 attribute values

[0509] 942 E07 Method

[0510] 944 Change Operation

[0511] 946 Change Operation

[0512] 950 Collection of interface methods

[0513] 952-964 Interface methods implemented by EO methods

[0514] 970 Δ Object

[0515] 972 Δ objects

[0516] 1250-1254 represent the transaction context lines respectively

[0517] 1256 Rows representing timestamps of data change events

[0518] 1220-1226 Append storage only

[0519] 1230-1236 Δ object flow

Claims

1. A computer-implemented method for data processing control, the method comprising: providing (102) at least one append-only storage (224, 322); providing (103) a framework (210); using (104) an application (226) to perform change operations (206, 208) on application-generated external objects (202, 204, 304) at runtime of the application, each application-generated external object being a data object instantiated within the application, the change operations (206, 208) comprising creating, modifying and / or deleting one or more of the application-generated external objects in the application, the application being configured to notify the framework of any of the change operations, the application (226) not being a database manager; in response to any of the change operations (206, 208), automatically creating (106) a Δ object (216, 218, 310) indicating a change in a property of at least one of the application-generated external objects caused by the change operation, wherein the Δ object is created by the framework (210); storing (108) by the framework a sequence of data objects in the at least one append-only store, the sequence of data objects comprising a mixture of the Δ objects (211, 212, 214, 310, 312, 404, 406) and requirement specification (RS) objects (216, 218, 314, 316, 318, 320), each RS object being a data object that specifies requirements regarding how the framework must process and output attribute information of one or more of the application-generated external objects included in the Δ objects, wherein the framework comprises a set of framework functions (220), wherein one or more of the framework functions are functional extensions of the application and are configured to, when called, process attribute information included in one or more of the Δ objects according to the requirements stored in the RS objects; One or more of the skeleton functions are executed (110) to return an output (230) computed as a function of the attribute information in the Delta object, the output (230) conforming to requirements specified in the RS object.

2. The computer-implemented method of claim 1 , wherein: The sequence of data objects includes a mixture of the Δ objects (211, 212, 214, 310, 312, 404, 406), the RS objects (216, 218, 314, 316, 318, 320) and access control objects - AC objects (221, 229), each AC object being a data object that specifies which user the framework allows or denies access to the Δ object, the Δ object including change information of a specific one of the external objects generated by the application, the method further comprising: receiving, by the framework, a request from a user to access property information of at least one of the external objects generated by the application; In response to receiving the request, traversing, by the framework, the at least one append-only store to process AC objects, the AC objects comprising access control data regarding the at least one application-generated external object; and The framework permits or denies, based on the access control data in the processed AC object, the user to access the attribute information included in the Δ object of the external object generated by the at least one application; or A report is outputted by the framework, the report selectively including attribute information included in the Δ object of the external object generated by the at least one application, which attribute information can be disclosed to the user according to the access control data in the processed AC object.

3. A computer-implemented method according to any one of the preceding claims, wherein: Storing the data object by the framework includes: identifying, by the framework, for each of the Δ objects to be stored, one of the application-generated external objects whose attribute change information is included in the Δ object; and / or The framework identifies, for each of the RS objects to be stored, one of the external objects generated by the application controlled by the RS object, whose attribute information is processed; and / or identifying, by the framework, for each of the one or more AC objects to be stored, its attribute information accessing one of the external objects generated by the application controlled by the AC object; selectively identifying, by the framework, one of a plurality of encryption keys for the identified application-generated external object, the identified encryption key being specifically assigned to the application-generated external object; The identified Delta object, RS object and / or AC object is encrypted using the identified encryption key, wherein the Delta object, RS object and / or AC object is stored in the at least one append-only storage in an encrypted form.

4. The computer-implemented method of claim 1 , wherein: The framework is a software program operably coupled to the application, the method further comprising: When a new application-generated external object among the application-generated external objects is instantiated in the application, the application sends a notification of the new application-generated external object to the framework, the notification including an object ID of the application-generated external object; In response to receiving the notification, automatically creating, by the framework, a symmetric or asymmetric encryption key pair specific to an application-generated external object whose object ID is indicated in the notification; and An encryption key pair is stored by the framework in association with an object ID of an external object generated by the application, wherein the storing is preferably performed such that the framework, but not other software programs or users, has access to a key for decrypting a data object in the at least one append-only storage.

5. The computer-implemented method of claim 2, wherein: The framework is configured to store the sequence of data objects as at least one blockchain, whereby each of the Δ objects, each of the RS objects and / or each of the AC objects represents a block, wherein the method further comprises: checking, by the framework, upon accessing any one of the blocks in the append-only storage, whether a cryptographic hash (331) of the block is included in a subsequent block in the blockchain; If the cryptographic hash is included in the subsequent block, processing the accessed block; and Otherwise, an alarm is output and / or the processing of the accessed block is terminated.

6. The method according to claim 2, wherein: The at least one append-only storage is a plurality of append-only storages, each of the plurality of append-only storages representing a corresponding one of the external objects generated by the application and / or the external objects generated by the framework, and the framework is configured to use each of the append-only storages to selectively store a Δ object, an RS object and / or an AC object including attribute change information, attribute processing information and / or attribute access information about one of the external objects in one of the plurality of append-only storages representing the one external object.

7. The method according to claim 5 or 6, wherein: The framework is configured to store the sequence of data objects included in each of the plurality of append-only stores as a corresponding blockchain.

8. The computer-implemented method of claim 1, in, The framework and the application share an object model (222), the object model (222) defining types of external objects (304, 306, 416, 418) and properties of the types of external objects; wherein the object model defines how the external objects are related to each other, each external object being a data object instantiated outside of the at least one append-only storage, the external objects comprising external objects (304, 306) generated by the application and external objects (408, 410) generated by the framework, each framework-generated external object being a data object instantiated in the framework; Wherein executing (110) one or more of the framework functions includes using the object model (222) by one or more of the framework functions to create, modify and / or delete framework-generated external objects in the framework.

9. The computer-implemented method of claim 1, in, The framework is instantiated on a computer system including a main memory; wherein executing (110) one or more of the framework functions comprises sequentially scanning the at least one append-only storage at least a first time to process the RS objects and / or processing the AC objects, and sequentially scanning the at least one append-only storage at least a second time to process the Δ objects, thereby taking into account requirements specified in the RS objects processed in the first sequential scan and / or access rights or constraints included in the AC objects; Wherein, a total size of the Δ objects and RS objects and / or AC objects in the at least one append-only storage exceeds a size of the main memory.

10. The computer-implemented method of claim 1, in, The application program has no program functionality for storing in a non-volatile storage medium an external object generated by the application or data returned by a function of an external object generated by the application; and / or wherein the framework acts as a sole interface for the application to store application-generated external object data in a non-volatile storage medium, wherein the framework uses only the at least one append-only storage to store application-generated external object data in the form of a Δ object; and / or wherein the framework acts as the sole interface for the application to return output (230, 340) to the client; and / or Wherein, the at least one append-only storage is configured to exclusively allow the framework (210) to read data from and / or write data to the at least one append-only storage.

11. The computer-implemented method of claim 1 , further comprising: Receiving, by the framework, a requirement specification from a client (504); as well as In response to receiving the requirement specification, one of the RS objects is created by the framework, the created RS object specifying the received requirement.

12. The computer-implemented method of claim 1, executing one or more of the framework functions comprising: Receiving, by the framework, a request (506, 508) for obtaining a particular type of output from a client (504); In response to receiving the request, traversing, by the framework, the at least one append-only storage for the first time, thereby selectively processing RS objects stored in the traversed at least one append-only storage to extract requirement specifications associated with the requested output type; traversing the at least one append-only storage a second time by the framework to extract attribute information from one or more of the delta objects stored in the traversed at least one append-only storage, and processing the extracted attribute information according to the extracted requirement specification to calculate an output that complies with the extracted requirement specification; as well as The output is returned to the client.

13. The computer-implemented method of claim 1, wherein: The at least one append-only storage is a plurality of append-only storages, and the method further comprises: Creating, by the framework, a corresponding data stream for each of the external objects generated by the application and / or each of the external objects generated by the framework; and Each of the data streams is allocated a corresponding one of the append-only stores by the framework.

14. The computer-implemented method of claim 13, wherein: Sequentially storing the sequence of data objects in the plurality of append-only stores comprises: selectively adding each delta object created in response to a change operation performed on one of the external objects to a data stream created for that external object; and The storing of the delta objects is performed such that all delta objects indicating changes to a particular one of the external objects are selectively stored in one of the append-only stores allocated to a data stream allocated to the particular external object.

15. A computer-implemented method according to any one of the preceding claims 13-14, in, The method is performed on a computer system comprising a plurality of processing units, wherein the method comprises automatically allocating the data streams to different ones of the processing units to process the data streams in parallel; and / or Each of the plurality of append-only stores is included in a corresponding physical storage device, wherein storing of the data stream in the plurality of append-only stores is performed in parallel.

16. The computer-implemented method of claim 1, further comprising: performing, using (104) another application (302) at runtime of the other application, another change operation on another application-generated external objects (306), each another application-generated external object being a data object instantiated within the other application, the another change operation comprising creating, modifying and / or deleting one or more of the another application-generated external objects in the other application, the other application being configured to notify the framework of any of the another change operations; responsive to any of the further change operations, automatically creating (106) a further Δ object (312) indicating a change in a property of at least one of the further application-generated external objects caused by the further change operation, wherein the further Δ object is created by the framework (210); storing (108) by the framework in the at least one append-only storage a sequence of additional data objects, the sequence of additional data objects comprising a mixture of additional Δ objects (312) and additional RS objects (318, 320) and / or additional AC objects, each additional RS object being a data object specifying requirements on how the framework must process and output attribute information of one or more of the additional application-generated external objects included in the Δ object, each additional AC object being a data object specifying access control constraints or privileges on attribute information of one or more of the additional application-generated external objects included in the Δ object, wherein the set of framework functions (220) comprises at least one framework function that is a functional extension of the additional application and is configured to, when called, process attribute information included in one or more of the additional Δ objects according to the requirements stored in the additional RS objects; and Executing (110) at least one framework function as a functional extension of the further application to return a further output (340), the further output being calculated as a function of the attribute information in the Δ object, the further output conforming to requirements specified in the further RS ​​object and / or the output being returned to one or more users in accordance with access control constraints and / or privileges of the AC object.

17. The computer-implemented method of claim 2, wherein: The plurality of change operations and the creation and storage of the Δ object are performed within an integration transaction, each integration transaction comprising: one or more change operations of the plurality of change operations; and creation and storage of said Δ object triggered at least by said one or more change operations; One or more of the integrated transactions respectively include at least the creation and storage of one or more of the Δ objects, the creation and storage of one or more of the RS objects, and / or the creation and storage of one or more of the AC objects.

18. A computer system comprising: at least one append-only storage (224, 322); A framework (210) operatively coupled to at least one application (226), wherein the application is configured to perform change operations (206, 208) on application-generated external objects (202, 204, 304) at runtime of the application, each application-generated external object being a data object instantiated within the application, the change operations (206, 208) comprising creating, modifying and / or deleting one or more of the application-generated external objects in the application, the application being configured to notify the framework of any of the change operations, the application (226) not being a database management program; Wherein, the framework is configured to: In response to any of the change operations (206, 208), automatically creating (106) a Δ object (216, 218, 310) indicating a change in a property of at least one of the external objects generated by the application caused by the change operation; sequentially storing (108) a sequence of data objects in the at least one append-only storage, the sequence of data objects stored in the at least one append-only storage comprising a mixture of Δ objects (211, 212, 214, 310, 312, 404, 406) and requirement specification (RS) objects (216, 218, 314, 316, 318, 320), each RS object being a data object that specifies requirements regarding how the framework must process and output attribute information of one or more of the application-generated external objects included in the Δ objects, wherein the framework comprises a set of framework functions (220), wherein one or more of the framework functions are functional extensions of the application and are configured to, when called, process attribute information of one or more of the Δ objects according to the requirements stored in the RS objects; One or more of the skeleton functions are executed (110) to return an output (230) computed as a function of the attribute information in the Delta object, the output (230) conforming to requirements specified in the RS object.

19. A computer program product comprising computer executable instructions, the executable instructions being configured to cause a processor executing the computer executable instructions to perform a method comprising the following steps: an instantiation framework (210), the framework operatively coupled to at least one append-only storage (224, 322) and at least one application (226), the at least one application (226) not being a database management program, wherein the application is configured to perform change operations (206, 208) on application-generated external objects (202, 204, 304) at runtime of the application, each application-generated external object being a data object instantiated within the application, the change operations (206, 208) comprising creating, modifying and / or deleting one or more of the application-generated external objects in the application, the application being configured to notify the framework of any of the change operations; Use the framework to: In response to any of the change operations (206, 208), automatically creating (106) a Δ object (216, 218, 310) indicating a change in a property of at least one of the external objects generated by the application caused by the change operation; storing (108) sequentially in the at least one append-only storage a sequence of data objects, the sequence of data objects comprising a mixture of Δ objects (211, 212, 214, 310, 312, 404, 406) and requirement specification (RS) objects (216, 218, 314, 316, 318, 320), each RS object being a data object that specifies requirements regarding how the framework must process and output attribute information of one or more of the application-generated external objects included in the Δ object, wherein the framework comprises a set of framework functions (220), wherein one or more of the framework functions are functional extensions of the application and are configured to, when called, process attribute information included in one or more of the Δ objects according to the requirements stored in the RS object; One or more of the skeleton functions are executed (110) to return an output (230) computed as a function of the attribute information in the Delta object, the output (230) conforming to requirements specified in the RS object.

Images