Service Connector Orchestration for Multi-Format API Requests
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing solutions for service requests in complex environments, such as 5G service providers, face inefficiencies due to the need for multiple unique APIs, long response times, and difficulties in coordinating responses from various services, leading to potential failures and resource-intensive development for each customer's unique requirements.
Innovation Solution
A system utilizing a single API and a proxy service to parse and format requests for multiple services, coordinated by an orchestrator, which manages request and response logistics, including retry mechanisms and metadata logging, to ensure efficient and adaptable service delivery.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If multiple unique APIs are used to contact each service individually, then service coordination capability is improved, but response time increases and system complexity increases
Solution Approach 1:
The patent introduces an orchestrator as an intermediary component that receives requests from a single API, coordinates with multiple services, and manages their responses. This mediator pattern allows the system to maintain service coordination capability while reducing the number of direct API calls from external systems, thereby improving response time.
Solution Approach 2:
The system segments the service coordination function into a dedicated orchestrator component, separating the coordination logic from the API handling. This segmentation allows the single API to remain simple while the orchestrator handles the complexity of coordinating multiple services independently, reducing overall system response time.
2Adaptability or versatility
If multiple unique APIs are used to contact each service individually, then service coordination capability is improved, but device complexity increases
Solution Approach 1:
The orchestrator is designed as a universal component that can coordinate with multiple different services through a standardized interface. This multi-functionality allows a single orchestrator instance to handle various service coordination scenarios, reducing the need for multiple specialized components and thereby decreasing system complexity.
Solution Approach 2:
By introducing the orchestrator as an intermediary layer, the system reduces complexity at the API boundary. The orchestrator absorbs the complexity of service coordination internally, allowing external systems to interact through a simple single API without being exposed to the underlying service complexity.
3Loss of time
If a single API is used with an orchestrator, then response time is reduced and system complexity is reduced, but adaptability to different service formats decreases
Solution Approach 1:
The orchestrator dynamically changes parameters such as service endpoints, request formats, and response handling based on the specific service being accessed. This parameter-based adaptability allows the single API to maintain fast response times while remaining flexible enough to handle different service formats through configuration rather than structural changes.
Solution Approach 2:
The orchestrator is designed as a universal coordinator that can adapt to multiple service formats through a single interface. It maintains adaptability by implementing format conversion and parameter mapping capabilities, allowing it to work with diverse services while preserving the simplicity and speed of the single API approach.
4Ease of operation
If services are contacted individually, then service-specific handling is improved, but reliability decreases due to potential failures from single service failures
Solution Approach 1:
The orchestrator implements feedback mechanisms to monitor the status of individual service calls and adjust coordination strategies accordingly. When a service fails or responds slowly, the orchestrator can detect this through feedback and implement retry logic, load balancing, or fallback options, thereby improving overall system reliability while maintaining service-specific handling capabilities.
Solution Approach 2:
The orchestrator prepares cushioning measures in advance by implementing retry mechanisms, timeout configurations, and fallback service options before failures occur. This beforehand cushioning allows the system to handle individual service failures gracefully, maintaining reliability even when specific services experience issues.
Data Source
AI summary
A method may include receiving request data associated with a service, the request data in a first format. The method may also include determining an endpoint of the service and a second format associated with the service. The method may include generating a service request based at least in part on the request data, the service request in the second format. The method may then include providing the service request in the second format to an orchestrator. The method may include transmitting, by the orchestrator, the service request to the endpoint of the service. The method may include receiving, by the orchestrator, response data from the service, the response data based at least in part on the service request. The method may include generating, by the orchestrator, a response based at least in part on the response data. The method may include providing, by orchestrator, the response to the user.