Plug-in System Metadata Mapping for Maintenance Reduction

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The proliferation of plug-ins in plug-in frameworks leads to increased maintenance overhead due to the need for managing multiple versions and customizations, making it challenging to determine the correct plug-in for specific business scenarios.

Innovation Solution

A plug-in system that associates plug-ins with metadata and utilizes mapped values, allowing plug-ins to be reusable across multiple scenarios and managed through a user interface, with the plug-in framework searching for and returning mapped values based on specific business requirements.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If multiple individualized plug-ins are created to satisfy specific deployment requirements, then the software application can be customized for different business scenarios, but the maintenance overhead increases due to the proliferation of plug-ins and version management

Engineering Contradiction:
Improvecustomization capabilityVSAvoidmaintenance overhead
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements a universal plug-in template that can serve multiple business scenarios through parameterization. Instead of creating separate plug-ins for each scenario, a single template plug-in is designed to accommodate different requirements by accepting configuration parameters during instantiation. This reduces the number of plug-ins from many individualized versions to a single multi-functional template, directly addressing the contradiction between adaptability and complexity.

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

Solution Approach 2:

The patent uses parameter changes to differentiate plug-in instances created from the same template. Each plug-in instance is customized by passing different parameters during creation, such as business scenario identifiers, configuration values, or behavioral modifiers. This allows the system to maintain high adaptability while managing complexity through a single template definition rather than multiple hard-coded plug-in versions.

Inventive Principle:
Principle #35Parameter changes

2Adaptability or versatility

If multiple versions of plug-ins are registered to handle different business requirements, then the software application can support diverse scenarios, but it becomes challenging to determine the correct plug-in for specific business scenarios

Engineering Contradiction:
Improvescenario supportVSAvoidplug-in selection difficulty
Core Design Contradiction:
Adaptability or versatilityVSDifficulty of detecting and measuring

Solution Approach 1:

The patent performs preliminary action by pre-defining a template plug-in with all possible configurations and parameters before actual deployment. The template includes metadata, version information, and parameter definitions that guide the selection process. When a new business scenario arises, the system can match it against the template's predefined capabilities rather than searching through multiple versioned plug-ins, thereby reducing selection difficulty while maintaining scenario support.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent introduces an intermediary layer between the business scenario and the plug-in implementation. This intermediary is the parameterized template system that translates specific business requirements into appropriate plug-in instance configurations. The template acts as a mediator that simplifies the matching process by providing a standardized interface and configuration mechanism, making it easier to determine the correct plug-in instance for any given scenario without directly managing multiple versions.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Ease of operation

If customers create multiple individualized plug-ins for specific business requirements, then the software application can be tailored to exact needs, but the plug-in framework complexity increases due to version registration and loading management

Engineering Contradiction:
Improvebusiness requirement fulfillmentVSAvoidframework management complexity
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The patent extracts the customization logic from the plug-in framework itself and places it in the application layer through parameterized instantiation. Instead of the framework needing to manage multiple versions and provide complex version selection mechanisms, the framework simply loads the single template plug-in. The customization is achieved by passing different parameters when creating plug-in instances, thereby extracting the complexity of version management from the framework while maintaining ease of operation for fulfilling business requirements.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent implements self-service by enabling the application to create and configure plug-in instances autonomously using the template and parameter mechanism. The application can directly instantiate plug-ins with appropriate parameters based on its specific business requirements without needing to interact with complex framework version management systems. This self-service approach simplifies the framework's role to just providing the template and loading mechanism, while the application handles the customization, thereby reducing framework complexity while maintaining operational ease.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS8407461B2Plug-in system for software applications
Publication Date: 2013.03.26 ORACLE INT CORP
  • US8407461B2 patent drawing
  • US8407461B2 patent drawing
  • US8407461B2 patent drawing

AI summary

A plug-in framework is invoked within a plug-in, where the plug-in framework includes a software library configured to define, register, and configure plug-ins, where the plug-in includes a software module that extends or customizes functionality of a software application that is external to the plug-in, and where the plug-in includes a mapping name. A plug-in instance declaration is searched, by the plug-in framework, for a mapping that includes the mapping name, where the plug-in instance declaration is located within a plug-in file, and where the plug-in declaration comprises one or more mappings. When a mapping of the mapping name to the value is found, the value is returned, by the plug-in framework, to the plug-in based on the mapping. The plug-in framework also allows a plug-in provider to associate a plug-in with metadata.