Extensible Single Point Orchestration System for API Aggregation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing systems for managing Application Program Interfaces (APIs) face significant administrative overhead due to the complexity of aggregating and maintaining multiple APIs from various providers, which becomes unwieldy as the number of services increases, requiring extensive code releases and management processes to maintain stability.
Innovation Solution
An extensible single point orchestration system that employs a layered, stateless, configuration-based approach for managing API services, enabling aggregation, selection, and proxy services with centralized key management, allowing for efficient modification, extension, and maintenance through run-time modifiable stored configuration entities.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If physical implementation logic is built to aggregate or select APIs, then API aggregation functionality is achieved, but system complexity and maintenance difficulty increase as the number of services increases
Solution Approach 1:
The patent uses configuration files as copies of API service definitions, allowing the system to manage API aggregations through data-based representations rather than hard-coded logic. Configuration entities define service parameters, endpoints, and aggregation rules that can be modified without changing the underlying system structure, thus reducing complexity while maintaining versatility.
Solution Approach 2:
The system manages API aggregation by changing parameters in configuration entities rather than modifying system architecture. Service parameters, endpoint URLs, authentication credentials, and aggregation logic are all controlled through configurable parameters that can be adjusted at runtime, enabling adaptability without increasing structural complexity.
2Reliability
If code releases are used to maintain API aggregation services, then system stability is maintained, but development overhead and time consumption increase
Solution Approach 1:
The patent implements dynamic configuration loading where the system reads and applies configuration entities at runtime rather than requiring compilation and deployment cycles. Configuration changes can be made and take effect immediately without code releases, enabling the system to maintain stability through version-controlled configurations while eliminating the time loss associated with software release management.
Solution Approach 2:
The system automatically manages configuration validation and application without requiring manual code deployment processes. The configuration management system self-updates by loading new configuration entities, validating them against defined schemas, and applying changes automatically, thus maintaining reliability while eliminating the need for developer intervention in routine updates.
3Reliability
If centralized key management is implemented, then security is improved, but system architecture complexity increases
Solution Approach 1:
The patent merges key management functionality into the existing configuration entity structure. Authentication credentials, API keys, and security parameters are stored as fields within the same configuration entities that define service endpoints and aggregation logic. This consolidation provides centralized security management without adding separate complex key management infrastructure, as the configuration system already serves as a centralized management point.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
An extensible single point orchestration system receives service requests from applications. In dependence upon the service request a single third party provider service or multiple third party provider services is identified. When the single third party provider service is identified, the system dynamically adapts a core capability service, using a stored configuration entity, so as to set an appropriate message format and transmit a service call message to an external API of the identified single third party provider service. When multiple third party provider services are identified, the system dynamically adapts the core capability service, using another stored configuration entity, so as to set a respective appropriate message format for parallel data transmission of service call messages to each of the respective identified third party provider services and transmits the service call messages to respective external APIs of each of the third party provider services.