Service Registry Version Routing for API Compatibility

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing Web service systems face challenges in handling incompatible changes, such as syntax and semantic changes, which require updating Web service clients, and lack efficient mechanisms to manage different versions and implementations.

Innovation Solution

A method that uses a call identifier to detect mismatches between service clients and providers, allowing for corrective actions like conversion or notification, and enables clients to request specific functionality versions through a single interface, leveraging Web Service Description Language (WSDL) and Universal Description, Discovery, and Integration (UDDI) specifications.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If Web service clients need to access updated Web services with incompatible changes, then the service functionality can be improved, but the clients must be updated which increases complexity and workload

Engineering Contradiction:

Improveservice functionalityVSAvoidclient update complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces a service registry as an intermediary component that mediates between service providers and clients. The registry stores version information and routing rules, allowing clients to access different service versions without direct updates. The registry acts as a mediator that handles version routing, compatibility detection, and client-provider coordination, thereby reducing client update complexity while enabling service functionality improvements.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent implements dynamic service versioning where the service interface can change over time while maintaining backward compatibility. The system allows dynamic routing of requests to different service versions based on client capabilities and service availability. This dynamic approach enables the service to evolve its functionality without requiring immediate client updates, as the routing mechanism adapts to both old and new service versions.

Inventive Principle:

Principle #15Dynamics

2Reliability

If multiple service versions are maintained in parallel, then compatibility with existing clients is preserved, but system complexity increases

Engineering Contradiction:

ImprovecompatibilityVSAvoidsystem complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The patent segments the service interface into distinct versions, each with its own routing rules and compatibility characteristics. The service registry divides the service traffic into separate streams based on version requirements, allowing different service versions to coexist without interfering with each other. This segmentation enables reliable compatibility management while organizing complexity into manageable, isolated version-specific pathways.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The service registry serves multiple functions simultaneously: it acts as a version router, compatibility detector, and service dispatcher. By consolidating these functions into a single universal component, the system manages multiple service versions without proportionally increasing overall system complexity. The registry's multi-functionality allows it to handle versioning overhead that would otherwise require separate mechanisms.

Inventive Principle:

Principle #6Universality (Multi-functionality)

3Adaptability or versatility

If service interfaces are changed frequently to meet changing requirements, then the service can adapt to new needs, but clients experience more frequent updates

Engineering Contradiction:

Improveservice adaptabilityVSAvoidclient update frequency

Core Design Contradiction:

Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent implements preliminary action by pre-configuring version routing rules in the service registry before service changes occur. When a service version is deployed, the registry is updated in advance with routing information, allowing clients to automatically access the new version without needing to update their own software. This preliminary setup of routing mechanisms enables service adaptability while preventing client update frequency increases.

Inventive Principle:

Principle #10Preliminary action

4Adaptability or versatility

If incompatible service changes are implemented, then service functionality is enhanced, but detection of mismatches between clients and providers becomes difficult

Engineering Contradiction:

Improveservice functionalityVSAvoidversion mismatch detection

Core Design Contradiction:

Adaptability or versatilityVSDifficulty of detecting and measuring

Solution Approach 1:

The patent incorporates feedback mechanisms where the service registry continuously monitors service versions and client requests. The registry provides feedback about available service versions and their compatibility characteristics to clients and providers. This feedback loop enables enhanced service functionality while making version mismatches detectable, as the registry actively reports version information and routing status to all participants in the service ecosystem.

Inventive Principle:

Principle #23Feedback

Data Source

PatentUS7406520B2Identifying interfaces related to a service

Publication Date: 2008.07.29 SAP SE

AI summary

A method in a computing device for identifying interfaces related to a service provider includes receiving a call identifier as an explicit parameter in a call or as an implicit parameter contained within input data to request a service provided by the service provider, the call identifier representing a version of the service.