Microservices Mediation Engine for IDE Interoperability

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Application developers face challenges in sharing and collaborating low-code/no-code development experiences, design outputs, and associated libraries across different Integrated Development Environments (IDEs) due to the lack of abstraction and interoperability, requiring rewriting of hardware microservices for different programming languages and IDEs.

Innovation Solution

A microservices mediation engine (MME) is introduced to manage and translate Developer Experience (DX) intent into hardware microservices, allowing access and deployment across various IDEs without language dependencies, enabling interoperability and design interchangeability.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If base code is developed in a specific IDE environment with programming language dependency, then the code can be executed in that IDE, but it must be rewritten in another language if a new owner unfamiliar with the first IDE environment wishes to adopt it

Engineering Contradiction:
ImproveIDE environment compatibilityVSAvoidcode rewriting requirement
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces an abstraction layer that acts as an intermediary between the hardware microservice and the IDE environment. This abstraction layer enables the hardware microservice to be accessed through different IDEs without requiring code rewriting, as the abstraction layer handles the translation and adaptation to different IDE-specific programming languages and environments.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent creates a universal interface that allows a single hardware microservice implementation to be accessed from multiple different IDE environments. The abstraction layer provides multi-functionality by supporting various IDEs (such as VS Code, Eclipse, IntelliJ) and programming languages simultaneously, eliminating the need for separate code versions for each IDE.

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Ease of operation

If hardware microservices are tightly coupled to programming language and IDE environment, then development in that specific environment is straightforward, but accessibility and eligibility of hardware microservices across different IDEs is reduced

Engineering Contradiction:
Improvedevelopment simplicityVSAvoidIDE accessibility
Core Design Contradiction:
Ease of operationVSAdaptability or versatility

Solution Approach 1:

The patent segments the hardware microservice system into distinct layers: the hardware microservice implementation layer and the IDE access layer. The abstraction layer separates these concerns, allowing the hardware microservice to be developed once while supporting multiple IDEs through the segmented architecture. This segmentation maintains development simplicity while improving IDE accessibility.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The abstraction layer serves as an intermediary that decouples the hardware microservice from direct IDE dependencies. It provides a standardized interface that different IDEs can connect to through their respective plugins or integrations, maintaining ease of operation for developers in their preferred IDE while expanding accessibility to multiple IDE environments.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Reliability

If each IDE maintains its own catalog or structure of libraries for its unique coding environment, then the IDE provides optimized support for its specific programming language, but there is no abstraction solution where different conceptual representation of software can be instantaneously simulated or rapidly configured

Engineering Contradiction:
ImproveIDE-specific optimizationVSAvoidsoftware configuration speed
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent implements preliminary action by pre-configuring the abstraction layer with support for multiple IDE environments and programming languages. This allows developers to rapidly configure and switch between different IDE conceptual representations without starting from scratch, as the abstraction layer already has the necessary mappings and integrations in place for instantaneously simulating different software environments.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The abstraction layer enables parameter changes by allowing dynamic switching between different IDE configurations and programming language mappings. When a developer changes their preferred IDE or programming language, the abstraction layer adjusts the relevant parameters and mappings automatically, maintaining reliable IDE-specific optimization while enabling rapid reconfiguration without manual intervention.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS20240281220A2A Concept for Orchestration of Microservices
Publication Date: 2024.08.22 ALTERA CORP
  • US20240281220A2 patent drawing
  • US20240281220A2 patent drawing
  • US20240281220A2 patent drawing

AI summary

An apparatus is provided. The apparatus comprises interface circuitry, machine-readable instructions and processing circuitry to execute the machine-readable instructions. The machine-readable instruction may be stored on a storage device. The machine-readable instructions is to receive, from an interface apparatus, user data indicative of a hardware microservice requested by a user. Further, it is to receive, from a database, microservice data indicative of a plurality of hardware microservices. Further, it is to determine a hardware microservice based on the plurality of hardware microservices and the requested hardware microservice of the user.