Interceptor Hub for Service API Compatibility

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Service-consuming applications often become incompatible with services due to changes in the service's API or protocol, leading to unexpected behavior or failure when trying to call the service.

Innovation Solution

An interceptor hub application that receives requests from service-consuming applications, sends requests to multiple services, receives responses, and provides a combined response, while managing which applications can access which services and storing relevant information in a database, using different APIs for request and response protocols.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If service-consuming applications are modified to remain compatible with service changes, then compatibility is improved, but maintenance complexity and cost increase

Engineering Contradiction:
ImprovecompatibilityVSAvoidmaintenance complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent introduces an interceptor hub as an intermediary component between service-consuming applications and services. The hub intercepts API calls from applications, translates them to the current service API format, and forwards them to the service. This mediator absorbs the complexity of API changes, allowing applications to remain unmodified while maintaining compatibility through the translation layer provided by the hub.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If service-consuming applications are modified to support new protocols, then protocol compatibility is improved, but development time and effort increase

Engineering Contradiction:
Improveprotocol compatibilityVSAvoiddevelopment time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The interceptor hub serves as a protocol translation intermediary that converts between different communication protocols. The hub receives requests from applications using one protocol format, translates them to the protocol expected by the service, and manages the communication flow. This eliminates the need to modify applications to support new protocols, as the hub handles protocol adaptation transparently.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system performs protocol translation and adaptation in advance through the interceptor hub, before requests reach the actual service. The hub is pre-configured with knowledge of both the application's protocol format and the service's expected protocol format, allowing it to perform translations proactively rather than requiring applications to be modified for each protocol change.

Inventive Principle:
Principle #10Preliminary action

3Adaptability or versatility

If multiple services are called from a single application, then functionality is improved, but system complexity increases

Engineering Contradiction:
ImprovefunctionalityVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The interceptor hub merges multiple service calls into a unified translation and management layer. Instead of having applications directly call multiple services with different protocols and formats, the hub consolidates these interactions through a single intermediary point. It manages the complexity of coordinating multiple services, translating their various APIs into a unified interface for the application.

Inventive Principle:
Principle #5Merging (Combining)

4Adaptability or versatility

If service APIs change, then service functionality is improved, but application compatibility deteriorates

Engineering Contradiction:
Improveservice functionalityVSAvoidapplication compatibility
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The interceptor hub acts as a protective intermediary that shields applications from service API changes. When service APIs change, only the hub needs to be updated with the new translation rules, while applications continue to use the same unchanged API interface. The hub absorbs all API change impacts through its translation layer, maintaining application compatibility despite service evolution.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS11943322B2Interceptor hub for service-consuming applications
Publication Date: 2024.03.26 US POSTAL SERVICE
  • US11943322B2 patent drawing
  • US11943322B2 patent drawing
  • US11943322B2 patent drawing

AI summary

A method, a computing device, and a computer program product are provided. An interceptor hub application executing on a first computing device receives, via a network, a request for multiple services from a first service-consuming application executing on a second computing device. The multiple services execute on at least one other computing device and are accessible via the first computing device via the network. The interceptor hub application sends a respective request to each of the requested services executing on a corresponding one of the at least one other computing device. A respective service response from the each of the respective services is received by the interceptor hub application, which provides each of the respective responses in a combined service response to the first service-consuming.