Runtime Independence Layer for Middleware Adaptation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing systems management software applications face significant challenges in supporting multiple middleware runtime frameworks, requiring costly and time-consuming rewrites of source code, especially when managing legacy automatic test systems with obsolete hardware and unavailable source data.
Innovation Solution
A method and apparatus for automatic conversion of existing systems management software applications to run in multiple middleware runtime frameworks, utilizing a scanner, ontologies, algorithmic components, and runtime dependency processing modules to identify and isolate runtime-dependent functions, and generate runtime-independent proxy components, allowing systems to operate without full source code rewrites.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If systems management software is rewritten to support multiple middleware runtime frameworks, then adaptability is improved, but development time and cost increase significantly
Solution Approach 1:
The patent introduces a runtime independence layer as an intermediary between the systems management application and multiple middleware runtime frameworks. This layer contains framework-specific code that handles compatibility differences, allowing the core application logic to remain unchanged while supporting multiple frameworks (e.g., WebSphere, Tomcat, OSGi, Spring). The intermediary absorbs the complexity of framework-specific implementations, enabling the application to adapt to different runtimes without requiring rewrites.
Solution Approach 2:
The patent segments the systems management application into distinct layers: a core application layer that remains framework-agnostic, and a runtime independence layer that contains framework-specific implementations. This segmentation allows the core functionality to be preserved while only the necessary adapter code is modified or added for each new middleware framework, significantly reducing the scope of required changes.
2Adaptability or versatility
If systems management software is rewritten to support multiple middleware runtime frameworks, then adaptability is improved, but maintenance cost increases
Solution Approach 1:
The runtime independence layer serves as a maintainable intermediary that centralizes all framework-specific code. When a new middleware framework needs to be supported or an existing one needs updates, only the runtime independence layer requires modification, not the entire application. This significantly reduces maintenance costs by isolating changes to a specific, manageable layer.
Solution Approach 2:
The runtime independence layer is designed to be universal, handling multiple middleware frameworks through a common architecture. This multi-functional design allows the same layer to support various frameworks (WebSphere, Tomcat, OSGi, Spring, etc.) using consistent patterns and approaches, reducing the need for framework-specific maintenance efforts and lowering overall maintenance costs.
3Adaptability or versatility
If legacy test program sets are redeveloped to work with new hardware, then system compatibility is improved, but loss of legacy data increases
Solution Approach 1:
The patent creates a virtual representation or copy of the legacy test program set that runs on the new hardware platform. Instead of rewriting the actual legacy code, the system uses the runtime independence layer to create an adapted version that preserves the original logic and data while executing on modern middleware frameworks. This copying approach maintains legacy data integrity while achieving hardware compatibility.
Solution Approach 2:
The runtime independence layer acts as an intermediary that bridges legacy test programs and new hardware platforms. It allows legacy applications to run on new infrastructure without direct modification, preserving the original code and data while providing compatibility through the adapter layer. This ensures legacy data is not lost or corrupted during the transition to new hardware.
4Adaptability or versatility
If extensive re-development of test program sets is performed, then system compatibility is improved, but time and cost of validation increase
Solution Approach 1:
The patent performs preliminary actions by establishing the runtime independence layer framework in advance, which provides a standardized approach for supporting multiple middleware frameworks. This preliminary infrastructure setup enables future compatibility improvements without requiring extensive re-validation, as the adapter pattern ensures consistent behavior across frameworks. Independent Validation & Verification processes can be reused more effectively.
Solution Approach 2:
By creating adapted copies of test programs through the runtime independence layer rather than performing extensive re-development, the patent preserves the original validated logic. These copies inherit the validation status of the original programs, significantly reducing the time and cost of re-validation while still achieving compatibility with new systems.
Data Source
AI summary
An apparatus for automatic conversion of existing systems management software applications to run in multiple middleware runtime frameworks by automating the unification of runtime framework ontologies and isolating runtime dependent code in the build process of system management applications through the introduction of a runtime dependency processor and performing runtime dependency analysis.