Local-Cloud Interface for Synchronous-Asynchronous Data Conversion
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing local server systems for processing protected data face challenges such as scalability constraints, maintenance overhead, geographic limitations, data protection compliance, security vulnerabilities, and latency issues, necessitating a more efficient and secure data processing solution.
Innovation Solution
A method and interface module for interfacing synchronous batch-driven applications on a local server with asynchronous event-driven applications on a cloud computing environment, utilizing conversion modules to transform data formats and enable communication between the two systems, leveraging the cloud's robust security and scalability for protected data processing.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If data processing is centralised on local servers, then data security and control are improved, but scalability and maintenance efficiency deteriorate
Solution Approach 1:
The patent segments the data processing system into local server components (for secure data hosting and batch processing) and cloud computing components (for event-driven processing and scalability). This allows the system to leverage both the security benefits of local servers and the scalability benefits of cloud computing without requiring complete centralisation or decentralisation.
Solution Approach 2:
The patent introduces an interface module as an intermediary between the local server and cloud computing environment. This module enables secure communication and data exchange, allowing the system to maintain data security on local servers while still benefiting from cloud scalability through controlled interaction.
2Reliability
If all data processing occurs on local servers, then data security is improved, but processing efficiency and resource utilization deteriorate
Solution Approach 1:
The patent divides processing tasks into two categories: batch-driven synchronous processing that remains on local servers for secure data handling, and event-driven asynchronous processing that moves to cloud computing for efficient resource utilization. This segmentation allows each type of processing to occur in its most appropriate environment.
Solution Approach 2:
The patent extracts event-driven processing tasks from the local server environment and places them in the cloud computing environment. This extraction allows non-critical, event-driven tasks to benefit from cloud scalability and processing power while critical data remains secured on local servers.
3Stability of the object's composition
If synchronous batch-driven processing is used on local servers, then data consistency is improved, but response time and latency deteriorate
Solution Approach 1:
The patent introduces dynamic processing modes by implementing both synchronous batch-driven processing (for consistency-critical operations) and asynchronous event-driven processing (for time-sensitive operations). The system can dynamically select the appropriate processing mode based on the specific task requirements, thereby optimizing both consistency and response time.
Solution Approach 2:
The patent employs periodic batch processing for synchronous operations, where data is processed in scheduled intervals rather than requiring immediate real-time processing for all operations. This periodic approach maintains data consistency while reducing the latency burden on critical path operations.
4Reliability
If legacy mainframe systems are used for batch processing, then system reliability is improved, but adaptability to modern event-driven architectures deteriorates
Solution Approach 1:
The patent introduces an interface module as an intermediary layer between legacy mainframe systems and modern cloud-based event-driven applications. This module handles protocol translation, data format conversion, and communication bridging, allowing reliable legacy systems to interact with modern architectures without requiring replacement or direct integration.
Solution Approach 2:
The interface module is designed with universal functionality to handle multiple communication protocols, data formats, and interaction patterns. This multi-functionality allows it to serve as a bridge between diverse systems including legacy mainframes, local servers, and cloud computing environments, thereby improving architectural compatibility across the entire system.
Data Source
Figure 1
Figure 2
Figure 3A~3B
AI summary
There is provided a computer-implemented method of interfacing one or more synchronous batch-driven applications running on a local server with one or more asynchronous event-driven applications running on a cloud computing environment. The method comprises first transformation steps and second transformation steps. The first transformation steps comprise receiving an event-driven message from a first asynchronous event-driven application, the event-driven message having a first data format type; transforming the event-driven message into a second data format type for a first synchronous batch-driven application; and transmitting the transformed event-driven message to the first synchronous batch-driven application. The second transformation steps comprise receiving a batch-driven message from a second synchronous batch-driven application, the batch-driven application having the second data format type; transforming the batch-driven message into the first data format type for a second asynchronous event-driven application; and transmitting the transformed batch-driven message to the second asynchronous event-driven application.