Dynamic Object Mapping for Decoupled Data Sharing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing software systems face challenges when sharing data between processes of different formats, leading to functional issues and requiring significant effort and error-prone adjustments when data format changes occur, especially in strongly coupled processes.
Innovation Solution
The technique allows for the dynamic mapping of custom object types to a standard object type, enabling data retrieval and storage in corresponding fields, decoupling processes and allowing for independent modifications without requiring changes to other processes, using an API to create instances and manage data sources and mappings.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If processes are strongly coupled to share data, then data sharing is achieved, but process maintainability deteriorates when data format changes occur
Solution Approach 1:
A data format converter is introduced as an intermediary component between the first process and the second process. The converter receives data in the first format, transforms it to the second format, and delivers it to the second process. This mediator isolates the strong coupling between processes, allowing each to maintain its own data format independently while still enabling effective data sharing.
Solution Approach 2:
The data sharing functionality is segmented into separate components: the first process, the data format converter, and the second process. Each component operates independently with its own data format, connected through well-defined interfaces. This segmentation allows individual processes to be modified or replaced without affecting others, significantly improving maintainability.
2Adaptability or versatility
If data format changes are handled by modifying conversion processes, then data compatibility is maintained, but development effort and errors increase
Solution Approach 1:
The data format converter is designed as a dynamic component that automatically adapts to format changes in either the first or second process. When a process changes its data format, the converter can be reconfigured or updated to accommodate the new format without requiring changes to the other process. This dynamic adaptability maintains compatibility while reducing the complexity of managing multiple conversion scenarios.
Solution Approach 2:
The converter's behavior is controlled by configurable parameters that define the input and output data formats. Instead of hardcoding conversion logic, the system uses parameter-based configuration that allows easy adjustment when data formats change. This approach maintains adaptability while simplifying the converter's internal structure and reducing development effort.
3Ease of operation
If processes use the same data format, then data sharing is simplified, but system flexibility deteriorates when format changes are needed
Solution Approach 1:
The data format converter serves as a flexible intermediary that enables processes with different data formats to communicate seamlessly. Each process can continue using its own native format without compromise, while the converter handles the translation overhead, maintaining both simplicity of operation and flexibility for format changes.
Solution Approach 2:
The data format converter is designed as a universal component that can handle multiple data formats as input and output. Rather than requiring separate conversion processes for each format combination, a single multi-functional converter can accommodate various formats through configuration, providing both simplicity in usage and flexibility in adaptation.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Techniques and solutions are provided for facilitating the use of a standard (or "specific") object type with different custom (or "arbitrary") object types. One or more custom object types can be mapped to a standard object type. When a custom object type is mapped to standard object type, and a request is received to generate an instance of the standard object type corresponding to an instance of the custom object type, data sources associated with the custom object type can be identified. All or a portion of fields (or other examples of variables) of the data sources can be mapped to fields of the standard object type. An instance of the standard object type is created and linked to the instance of the custom object type. Data from the data sources can be retrieved and stored in corresponding fields of the instance of the standard object type.