Server Object Versioning for Client Compatibility

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Conventional approaches to preventing clients from constructing unrecognized objects in client/server architectures face issues such as maintainability problems, increased complexity, and resource wastage, as well as causing clients to become unsupported and lose functionality when not upgraded simultaneously with servers.

Innovation Solution

A technique involving a client-provided identifier is used to manage the distribution of well-defined objects, where the server maintains a database and registry of identifiers to determine which objects a client can handle, ensuring only compatible objects are streamed to the client, preventing it from attempting to construct unsupported objects.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If the server is upgraded to provide newer well-defined objects, then the server functionality is improved, but older clients fail to process the streamed objects properly

Engineering Contradiction:

Improveserver functionalityVSAvoidclient processing reliability

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The server dynamically adjusts the version of well-defined objects streamed to clients based on the client's version identifier. When a client requests objects, the server compares the client's identifier with available object versions and streams only compatible versions, allowing the server to adapt its behavior to different client capabilities while maintaining system reliability

Inventive Principle:

Principle #15Dynamics

Solution Approach 2:

Different versions of well-defined objects are provided to different clients based on their specific capabilities. Each client receives a customized stream of objects appropriate to its version level, rather than a uniform stream, allowing the server to maintain both old and new functionality simultaneously for different clients

Inventive Principle:

Principle #3Local quality

2Reliability

If the common version approach is used to maintain client and server at a common version, then client compatibility is maintained, but server maintainability deteriorates

Engineering Contradiction:

Improveclient compatibilityVSAvoidserver maintainability

Core Design Contradiction:

ReliabilityVSEase of manufacture

Solution Approach 1:

The server transitions from a static common-version model to a dynamic version-matching model where the server version is independent of client versions. The server automatically determines which version of objects to stream based on client identifiers, eliminating the need to hold back server upgrades for client upgrade schedules

Inventive Principle:

Principle #15Dynamics

3Adaptability or versatility

If new well-defined objects are embedded in older objects to support both old and new clients, then backward compatibility is maintained, but device complexity increases

Engineering Contradiction:

Improvebackward compatibilityVSAvoidobject structure complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system segments well-defined objects into different version groups, where each group is independent and complete. Instead of embedding new objects within old objects, the server maintains separate collections of objects at different version levels and streams the appropriate segment to each client based on its capabilities, simplifying the overall structure

Inventive Principle:

Principle #1Segmentation

4Reliability

If the no-longer supported approach is used where older clients receive no objects, then client failure is prevented, but client functionality is lost

Engineering Contradiction:

Improveclient failure preventionVSAvoidclient functionality

Core Design Contradiction:

ReliabilityVSEase of operation

Solution Approach 1:

The server provides a partial stream of objects to older clients - specifically, only those objects compatible with the client's version identifier. This partial action is sufficient to maintain client functionality and prevent failure, while avoiding the provision of incompatible objects that would cause construction errors

Inventive Principle:

Principle #16Partial or excessive action

Data Source

PatentUS7739688B1Techniques for managing distribution of well-defined objects in a client/server system

Publication Date: 2010.06.15 EMC IP HLDG CO LLC

AI summary

A technique enables managing distribution of well-defined objects. The technique involves maintaining a database of well-defined objects and a registry of identifiers. The technique further involves receiving an object request from a client device. The object request includes a particular identifier. The technique further involves providing (i) all of the well-defined objects from the database in response to the well-defined object request when the particular identifier of the well-defined object request is at least as recent as the most recent identifier in the registry, and alternatively (ii) less than all of the well-defined objects from the database in response to the well-defined object request when the particular identifier of the well-defined object request is not as recent as the most recent identifier in the registry. Accordingly, an older client device can be prohibited from receiving a newer well-defined object thereby preventing the older client device from attempting to construct the newer object and inadvertently failing.