Service Model Engine for Swagger-to-Orchestration API Mapping

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The gap between REST API data models from domain controllers and service orchestration systems necessitates manual adapter creation, requiring deep knowledge of both systems, leading to a complex, time-consuming, and costly process.

Innovation Solution

A service model engine generates service delivery models from vendor API swagger documentation, aligning with downstream domain controller interfaces to reduce integration complexity and cost.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If manual adapter creation is used to translate requests between Service orchestration system and domain controllers, then integration between systems is achieved, but the process becomes complex, time-consuming, and costly requiring deep developer knowledge

Engineering Contradiction:
Improveintegration reliabilityVSAvoidadapter creation complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system enables self-service by automatically generating service delivery models from vendor API Swagger documentation. The service model engine autonomously parses Swagger files, extracts API endpoint information, and generates aligned service models without requiring manual adapter creation, thereby eliminating the need for deep developer knowledge while maintaining integration reliability

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent replaces the mechanical manual process of adapter creation with an automated computational system. The service model engine uses algorithmic processing to parse Swagger documentation and generate service delivery models, substituting human developer effort with automated software that systematically transforms API specifications into integrated service models

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

2Adaptability or versatility

If manual adapter creation is used to bridge data model gaps, then system integration is achieved, but implementation time and costs increase significantly

Engineering Contradiction:
Improvedata model adaptabilityVSAvoidimplementation time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The system performs preliminary action by pre-generating service delivery models from Swagger documentation before actual service integration is needed. The service model engine proactively creates and maintains the translation layer between different data models in advance, eliminating the need for time-consuming manual adapter development when integration is required

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent applies parameter changes by transforming the input Swagger documentation parameters into aligned service delivery model parameters automatically. The service model engine systematically maps and transforms API endpoint parameters, request bodies, and response structures from vendor-specific formats into standardized service orchestration models, achieving data model adaptability through automated parameter transformation

Inventive Principle:
Principle #35Parameter changes

3Manufacturing precision

If deep developer knowledge of both systems is required for adapter creation, then accurate integration is achieved, but the process becomes ad-hoc and costly

Engineering Contradiction:
Improveintegration precisionVSAvoidadapter creation ease
Core Design Contradiction:
Manufacturing precisionVSEase of manufacture

Solution Approach 1:

The service model engine acts as an intermediary that mediates between the Service orchestration system and domain controllers. It automatically generates service delivery models that serve as a translation layer, eliminating the need for developers to deeply understand both systems while maintaining precise integration through systematic parameter mapping and model alignment

Inventive Principle:
Principle #24Intermediary (Mediator)

4Device complexity

If automated service model generation from Swagger documentation is implemented, then integration complexity and cost are reduced, but the system must process and interpret vendor-specific API formats

Engineering Contradiction:
Improveintegration complexityVSAvoidAPI specification parsing difficulty
Core Design Contradiction:
Device complexityVSDifficulty of detecting and measuring

Solution Approach 1:

The service model engine achieves universality by designing a parser that can handle multiple vendor-specific Swagger documentation formats through a unified processing approach. It extracts API endpoint information, parameters, and data models from various vendor formats and transforms them into a standardized service delivery model structure, reducing integration complexity while handling diverse API specifications

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

Data Source

PatentEP4664272A1Service model engine(s) for generating service delivery models from vendor API swagger
Publication Date: 2025.12.17 ORACLE INT CORP
  • EP4664272A1 patent drawingFigure 1
  • EP4664272A1 patent drawingFigure 2
  • EP4664272A1 patent drawingFigure 3

AI summary

Various embodiments of the present technology generally relate to systems and methods for providing a service model engine. In an aspect a method includes identifying, by a service model engine, a swagger file from a network vendor and parsing the swagger file for API endpoints. The service model engine may generate resource specifications based on the API endpoints and may generate delivery actions for each API endpoint. Each delivery action may include delivery parameters for each API endpoint, The service model engine may also map each of the delivery parameters to corresponding characteristics in the resource specifications to generate parameter mappings. The service model engine may generate a service delivery model including the resource specifications, the delivery actions, and the parameter mappings, where the service delivery model is used by a service orchestration system to deliver respective services.