Dynamic Dispatch for Distributed Object-Oriented Systems

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Distributed software systems face challenges in adapting to new resource types and larger scales without requiring system upgrades, as existing algorithms and architectures are rigid and inflexible.

Innovation Solution

The implementation of dynamic dispatch techniques, using Provider Definitions and Providers, allows for run-time modification of software function semantics, enabling flexible distribution of software functions across multiple nodes and resources, with dynamic selection of providers based on policies and relationships.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If rigid algorithms and architectures are used in distributed software systems, then system stability is maintained, but adaptability to new resource types and scales deteriorates

Engineering Contradiction:
Improveadaptability to new resource typesVSAvoidsystem architecture complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements dynamic dispatch mechanisms that allow the distributed software system to adapt its behavior at runtime based on the actual resource types and conditions encountered. The system transitions from static, rigid algorithms to dynamic decision-making processes that can handle new resource types without requiring architectural changes, thereby improving adaptability while maintaining manageable complexity.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system changes its operational parameters dynamically based on the type of resources it encounters. Instead of requiring structural modifications for new resource types, the system adjusts its dispatch parameters and selection criteria to accommodate heterogeneous resources, enabling versatility without proportionally increasing system complexity.

Inventive Principle:
Principle #35Parameter changes

2Adaptability or versatility

If the entire system is upgraded to extend control functions, then functional capability is improved, but system complexity and deployment difficulty increase

Engineering Contradiction:
Improvecontrol function extensibilityVSAvoidsystem deployment ease
Core Design Contradiction:
Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

The patent segments the control function extension capability into independent, deployable units that can be added to the distributed system without upgrading the entire system. Individual nodes or components can be enhanced with new control functions independently, allowing incremental adoption and reducing deployment complexity while maintaining system-wide extensibility.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system introduces intermediary components or abstraction layers that enable new control functions to be added without directly modifying the core system architecture. These intermediaries facilitate the integration of extended functionality while isolating the changes from the main system, thereby improving extensibility without proportionally increasing deployment difficulty.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Productivity

If static resource allocation is used, then system simplicity is maintained, but resource utilization efficiency deteriorates

Engineering Contradiction:
Improveresource utilization efficiencyVSAvoidresource management complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent implements feedback mechanisms where the distributed system continuously monitors resource usage and performance metrics, then uses this information to dynamically adjust resource allocation decisions. The feedback loop enables the system to optimize resource utilization based on actual conditions while maintaining manageable complexity through automated decision-making algorithms.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The system performs preliminary actions by pre-establishing dispatch rules and resource allocation strategies that can be quickly activated based on detected conditions. This allows the system to respond efficiently to changing resource utilization patterns without requiring complex real-time calculations, thereby improving productivity while keeping management complexity acceptable.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS8589471B2Dynamic dispatch for distributed object-oriented software systems
Publication Date: 2013.11.19 BMC HELIX INC
  • US8589471B2 patent drawing
  • US8589471B2 patent drawing
  • US8589471B2 patent drawing

AI summary

A provider definition represents software that implements the semantics of one or more operations on an object in an object-oriented system. A provider represents a specific instance of a provider definition. One or more providers implement operations for objects in the system. A component of the system called the provider registry maintains a mapping of providers and operations as defined by the provider definitions. When handling a request to invoke a operation on an object, the system dynamically dispatches to the correct provider based on this mapping. Where more than one provider are registered as implementing the desired operation on an object, techniques are disclosed for selecting a provider to perform the desired operation.