Proxy Container for Synchronous API Execution

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Synchronous APIs often block callers due to system slowdowns and uncontrolled third-party APIs, leading to performance issues and difficulties in handling long-running tasks without adequate timeout parameters.

Innovation Solution

Executing synchronous APIs within a proxy container, allowing the caller to proceed with other processing while the proxy waits for the API result, with monitoring and timeout mechanisms to manage the proxy's execution.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If synchronous APIs are used to ensure simple communication and integration between applications, then ease of operation is improved, but productivity deteriorates due to blocking behavior that prevents the caller from proceeding with other processing

Engineering Contradiction:
Improveease of operationVSAvoidproductivity
Core Design Contradiction:
Ease of operationVSProductivity

Solution Approach 1:

The patent segments the synchronous API execution from the caller application by introducing a proxy application. The caller application makes the synchronous API call to the proxy, which then executes the API call separately. This segmentation allows the caller to continue processing without being blocked, while the proxy handles the blocking operation independently.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The proxy application serves as an intermediary between the caller application and the target application. It receives synchronous API calls from the caller, executes them, and returns results without blocking the caller. This intermediary pattern resolves the contradiction by mediating the blocking behavior away from the caller while maintaining the simplicity of synchronous API usage.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Ease of operation

If synchronous APIs are used to maintain simple programming models, then ease of operation is improved, but loss of time increases due to indefinite waiting for third-party API results

Engineering Contradiction:
Improveease of operationVSAvoidloss of time
Core Design Contradiction:
Ease of operationVSLoss of time

Solution Approach 1:

The proxy application is pre-configured with timeout parameters and monitoring mechanisms before executing synchronous API calls. This preliminary setup allows the system to automatically terminate waiting after a specified duration, preventing indefinite time loss while maintaining the simple synchronous API interface for callers.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The proxy application implements feedback mechanisms through monitoring and timeout parameters that provide control over the execution of synchronous API calls. The system can monitor the proxy's execution and terminate it based on predefined time limits, creating a feedback loop that prevents excessive waiting time while preserving the ease of synchronous API usage.

Inventive Principle:
Principle #23Feedback

3Ease of operation

If synchronous APIs are used to ensure straightforward error handling, then ease of operation is improved, but reliability deteriorates when third-party APIs block callers due to system slowdowns or unexpected data sizes

Engineering Contradiction:
Improveease of operationVSAvoidreliability
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The proxy application acts as a protective intermediary that isolates the caller application from reliability issues in third-party APIs. The proxy handles blocking, timeouts, and errors independently, preventing these issues from propagating to the caller and compromising system reliability, while the caller continues to use simple synchronous API calls.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system implements beforehand cushioning by configuring timeout parameters and monitoring mechanisms in advance within the proxy application. These pre-established safeguards cushion against potential reliability issues such as system slowdowns or unexpected data sizes from third-party APIs, preventing them from causing indefinite blocking or failures in the caller application.

Inventive Principle:
Principle #11Beforehand cushioning (Prior cushioning)

Data Source

PatentUS9032425B1System and method to boost application performance by using a proxy for executing synchronous application programming interface calls
Publication Date: 2015.05.12 VMWARE INC
  • US9032425B1 patent drawing
  • US9032425B1 patent drawing
  • US9032425B1 patent drawing

AI summary

Techniques are described for utilizing synchronous APIs which normally block callers until a result is returned. In particular, the techniques described herein enable an application or other programming construct to boost performance by executing synchronous APIs (e.g., long running time APIs) within a proxy container rather than executing the synchronous APIs in the context of the application itself. Since the proxy is a separate process or thread, the caller application is thereby released from waiting for the synchronous API call and may proceed with other processing instead of waiting for the synchronous API to return. The application may then monitor the proxy to determine whether a result has been received, such as by periodically polling the proxy.