Dynamic Schema Mapping for Microservice Interoperability

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional methods for handling schema differences between microservices are manual, cumbersome, and inefficient, leading to reduced inter-compatibility and requiring developers to account for compatibility constraints during schema development.

Innovation Solution

A dynamic schema mapping system that monitors network traffic to train mapping models using unsupervised and semi-supervised approaches, generating a probability distribution tensor to probabilistically map schemas from one microservice to another, making the system schema-agnostic and allowing for automatic compatibility adjustments.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If manual API standardization is used to handle schema differences, then inter-compatibility between microservices is achieved, but the process becomes cumbersome and inefficient

Engineering Contradiction:
Improveinter-compatibilityVSAvoidschema mapping efficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The system performs self-service by automatically monitoring network traffic between microservices and generating schema mappings without human intervention. The mapping models are trained on observed traffic patterns and autonomously create and update schema translations, eliminating the need for manual API standardization while maintaining reliability.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The manual mechanical process of API standardization is replaced with an automated machine learning system. The mapping models use unsupervised and semi-supervised learning algorithms to automatically analyze network traffic and generate schema mappings, substituting human effort with computational intelligence.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

2Reliability

If manual schema mapping is performed, then known schema differences are addressed, but the solution remains rigid and cannot automatically generalize to new microservices

Engineering Contradiction:
Improveschema compatibilityVSAvoidgeneralization to new microservices
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The schema mapping system is dynamic rather than static. The mapping models are continuously trained on new network traffic data, allowing them to adapt to new microservices and schema variations automatically. This dynamic learning process enables the system to generalize to new services without manual reconfiguration.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system incorporates feedback loops where network traffic is continuously monitored and used to retrain and refine the mapping models. This feedback mechanism allows the system to learn from actual usage patterns and improve its generalization capability to new microservices over time.

Inventive Principle:
Principle #23Feedback

3Reliability

If developers account for compatibility constraints during schema development, then inter-compatibility is ensured, but the development process becomes more complex and time-consuming

Engineering Contradiction:
Improveschema compatibilityVSAvoiddevelopment complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The mapping models serve as an intermediary layer between microservices with different schemas. Developers can define schemas independently without worrying about compatibility constraints, as the automated mapping system translates between different schema formats, thereby reducing development complexity while ensuring compatibility.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The compatibility constraint management is extracted from the schema development process itself and handled separately by the automated mapping system. This separation allows developers to focus on schema design without the burden of ensuring inter-compatibility, as the mapping models automatically handle the compatibility layer.

Inventive Principle:
Principle #2Taking out (Extraction)

4Reliability

If conventional manual methods are used for schema mapping, then the process is controllable, but it requires significant manual intervention and is inefficient

Engineering Contradiction:
Improvemapping accuracyVSAvoidautomatic schema translation
Core Design Contradiction:
ReliabilityVSExtent of automation

Solution Approach 1:

The system performs self-service by automatically monitoring network traffic between microservices and generating schema mappings without human intervention. The mapping models are trained on observed traffic patterns and autonomously create and update schema translations, eliminating the need for manual API standardization while maintaining reliability.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The manual mechanical process of API standardization is replaced with an automated machine learning system. The mapping models use unsupervised and semi-supervised learning algorithms to automatically analyze network traffic and generate schema mappings, substituting human effort with computational intelligence.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

Data Source

PatentUS20230419139A1Dynamic schema mapping between microservices
Publication Date: 2023.12.28 INTUIT INC
  • US20230419139A1 patent drawing
  • US20230419139A1 patent drawing
  • US20230419139A1 patent drawing

AI summary

Disclosed dynamic schema mapping systems and methods monitor network traffic between different microservices and train mapping models based on the monitored network traffic using unsupervised training. This training of the mapping models generates a probability distribution tensor that shows the probabilistic associations of different key-value pairs of the schemas of different microservices. The trained mapping models are used to map a schema from a source microservice to another schema at a destination microservice. Should the translated schema be incompatible with the destination microservice, a semi-supervised approach is taken to make the translated schema compatible. The trained models may be reinforced (e.g., the probability distribution tensor may be updated) as more network traffic is collected and analyzed. The dynamic mapping therefore allows a system to be schema-agnostic, and developers may be able to define application interfaces or interaction schemas without the necessity of accounting for compatibility constraint between the different schemas.