Data-Centric Integration Modeling for Application Systems
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional application integration modeling is control-flow-centric, underspecifying data flow and being deficient for data-intensive integrations, which limits the clarity and efficiency of integration processes.
Innovation Solution
The implementation of data-centric integration modeling using a Logic Integration Language (LiLa) that defines integration logic in a declarative manner, allowing for the generation of logical and physical model graphs, and the creation of executable runtime codes, enabling optimized data flow and control flow management.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If conventional control-flow-centric modeling is used for application integration, then the control flow can be defined using EIP Icon Notations, but the data flow becomes underspecified and the modeling is deficient for data-intensive integrations
Solution Approach 1:
The patent segments the integration modeling into two distinct graph types: control-flow graph (CFG) for control flow definition and data-flow graph (DFG) for data flow specification. This segmentation allows each graph to specialize in its respective domain, with CFG handling EIP Icon Notations and DFG handling data-intensive integration details, thereby resolving the contradiction between ease of control flow operation and completeness of data flow specification
Solution Approach 2:
The patent adds a new dimension to integration modeling by introducing data-flow graphs as a complementary view to the traditional control-flow graphs. This dimensional expansion allows the system to simultaneously represent both control flow (temporal dimension) and data flow (structural dimension), preventing information loss in data-intensive scenarios while maintaining control flow definition capabilities
2Loss of information
If data-centric integration modeling is implemented with logical and physical model graphs, then data flow clarity and optimization are improved, but the device complexity increases due to multiple graph transformations
Solution Approach 1:
The patent applies preliminary action by performing logical model graph optimization before physical model graph generation. The logical model graph captures the ideal data flow and control flow relationships without runtime constraints, allowing optimizations to be applied in advance. This preliminary optimization reduces the complexity of subsequent physical model generation while maintaining data flow clarity
Solution Approach 2:
The patent extracts the optimization logic from the physical model generation process and applies it separately to the logical model graph. By taking out the optimization step as an independent phase, the system can apply complex optimizations without increasing the complexity of the physical model transformation, as the optimizations are already embedded in the logical model before physical instantiation
3Device complexity
If conventional integration modeling is used, then the modeling process is simpler, but the processing efficiency and resource utilization are reduced for data-intensive integrations
Solution Approach 1:
The patent changes the fundamental parameters of integration modeling by shifting from control-flow-centric to data-centric modeling. This parameter change enables the system to optimize for data-intensive integrations by representing data flow explicitly in the data-flow graph, thereby improving processing efficiency and resource utilization while accepting increased modeling complexity as a necessary trade-off
Data Source
AI summary
The present disclosure describes methods, systems, and computer program products for data-centric integration modeling in an application integration system. One computer-implemented method includes receiving, by operation of an integration system, a logic integration program comprising a plurality of logic integration patterns that are defined in a data-centric logic integration language; generating a logical model graph based on the logic integration program, the logical model graph being runtime-independent; converting the logical model graph into a physical model graph, the physical model graph being runtime-specific; and generating logic integration runtime codes executable by the integration system based on the physical model graph.