State-Dependent Entity Graphs for SOA Data Granularity

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Service-oriented architecture (SOA) systems face processing and resource constraints due to data transfer granularity issues, where higher flexibility in data manipulation comes at the cost of significant overhead in moving granular data elements between services.

Innovation Solution

Implementing state-dependent entities to manage and constrain entity graphs based on different states of service components, allowing for varying data granularity, with a state table correlating states to entity graph constraints and using software models of state machines for automated performance optimization.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If higher levels of granularity are used in data transfer between services, then flexibility in data manipulation is improved, but overhead in moving data elements increases significantly

Engineering Contradiction:
Improveflexibility in data manipulationVSAvoidoverhead in moving data elements
Core Design Contradiction:
Adaptability or versatilityVSLoss of energy

Solution Approach 1:

The patent implements dynamic data granularity by allowing the data model to transition between different states (coarse-grained and fine-grained) based on operational context. The entity graph can be dynamically constrained to include only necessary properties for the current operation, enabling the system to adapt data transfer granularity in real-time rather than being fixed. This resolves the contradiction by making granularity adjustable rather than static.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent applies local quality by allowing different parts of the entity graph to have different levels of detail based on their relevance to the current operation. Instead of uniformly transferring all data properties, the system selectively includes only the necessary properties in the entity graph based on the operational state, thereby reducing overall data transfer overhead while maintaining flexibility where needed.

Inventive Principle:
Principle #3Local quality

2Productivity

If a small number of operations transfer large amounts of data, then data transfer frequency is reduced, but data manipulation flexibility is limited

Engineering Contradiction:
Improvedata transfer efficiencyVSAvoiddata manipulation flexibility
Core Design Contradiction:
ProductivityVSAdaptability or versatility

Solution Approach 1:

The system dynamically adjusts the amount of data transferred based on operational state. During design-time modeling, the complete entity graph is available for full manipulation flexibility. During runtime operations, the entity graph is constrained to include only necessary properties, optimizing transfer efficiency. This dynamic adjustment allows the system to achieve both high transfer efficiency and flexibility at different appropriate times.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent segments the entity graph into mandatory and optional properties, allowing selective transfer of data elements. This segmentation enables the system to transfer only the essential data subset needed for each operation, improving transfer efficiency while preserving the ability to include additional properties when flexibility is required, thus resolving the contradiction between transfer efficiency and manipulation flexibility.

Inventive Principle:
Principle #1Segmentation

3Adaptability or versatility

If a larger number of operations transfer smaller amounts of data, then data manipulation flexibility is improved, but processing overhead increases

Engineering Contradiction:
Improvedata manipulation flexibilityVSAvoidprocessing overhead
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent performs preliminary action by establishing the complete entity graph model during design-time, where all properties and relationships are defined. This preliminary modeling phase captures the full data manipulation flexibility requirements. During runtime, this pre-defined model is used to efficiently constrain and filter data, reducing processing overhead by avoiding repeated analysis of data structure requirements during operation execution.

Inventive Principle:
Principle #10Preliminary action

4Adaptability or versatility

If data granularity is increased for flexibility, then service adaptability is improved, but resource consumption in data transfer increases

Engineering Contradiction:
Improveservice adaptabilityVSAvoidvolume of data transferred
Core Design Contradiction:
Adaptability or versatilityVSQuantity of substance

Solution Approach 1:

The patent changes the parameter of data granularity based on operational state. The entity graph transitions between different granularity levels by including or excluding specific properties based on the current service operation context. This parameter change allows the system to use fine-grained data representations when adaptability is needed and coarse-grained representations when resource efficiency is prioritized, thus resolving the contradiction between service adaptability and data transfer volume.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS8996714B2State-dependent entity based implementation of a service oriented architected application
Publication Date: 2015.03.31 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • US8996714B2 patent drawing
  • US8996714B2 patent drawing
  • US8996714B2 patent drawing

AI summary

Embodiments of the present invention address deficiencies of the art in respect to data granularity for an SOA and provide a method, system and computer program product for implementing an SOA using state-dependent entities. In an embodiment of the invention, a method for varying data granularity of a service component in an SOA according to state dependent entities can be provided. The method can include managing different states for a service component responsive to different operations performed in the service component; constraining an entity graph for the service component according to a first state of the service component; and, re-constraining the entity graph to include different properties for a second state of the service component.