Non-Invasive Runtime Environment for Software Function Call Monitoring

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing methods for monitoring complex software applications require changes to the application or the presence of specific interfaces, making it difficult to extract monitoring data from applications without substantial modifications, especially for older systems without these interfaces.

Innovation Solution

A non-invasive runtime environment that identifies and generates monitoring data for function calls during execution, including function parameters and additional runtime information, without modifying the software application, by duplicating function parameters before and after execution and forwarding this data to an analytic engine for processing.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of information

If instrumentation code is inserted into target functions to enable monitoring, then monitoring data can be collected, but the application code must be modified which is invasive and difficult for older systems

Engineering Contradiction:
Improvemonitoring dataVSAvoidapplication modification
Core Design Contradiction:
Loss of informationVSEase of manufacture

Solution Approach 1:

The patent introduces an intermediary layer (instrumentation manager and runtime environment) that sits between the monitoring system and the application code. This intermediary enables monitoring data collection without requiring direct modification of the application's core logic, as the instrumentation manager handles the insertion and management of monitoring code separately from the application itself.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The monitoring functionality is segmented into separate components (instrumentation manager, runtime environment, monitoring code) that can be independently managed and applied to the application. This segmentation allows the monitoring infrastructure to be added as a separate layer rather than being tightly coupled with the application code, facilitating easier implementation on legacy systems.

Inventive Principle:
Principle #1Segmentation

2Measurement precision

If a dedicated API is required for data extraction, then structured monitoring data can be obtained, but applications without such interfaces cannot be monitored without substantial code changes

Engineering Contradiction:
Improvemonitoring data qualityVSAvoidapplication compatibility
Core Design Contradiction:
Measurement precisionVSAdaptability or versatility

Solution Approach 1:

The runtime environment is designed to provide universal monitoring capabilities across different application types and programming languages. By implementing a language-neutral bytecode level and a standardized runtime environment interface, the system can monitor diverse applications without requiring application-specific adaptations, thus achieving both measurement precision and broad compatibility.

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

Solution Approach 2:

The patent changes the monitoring approach from application-level API calls to a lower-level bytecode instrumentation point. By operating at the bytecode level where all applications converge regardless of their high-level language or interface, the system achieves universal applicability while maintaining precise monitoring capabilities through standardized parameter extraction.

Inventive Principle:
Principle #35Parameter changes

3Loss of information

If manual extraction from databases is used, then data can be obtained from applications without interfaces, but the process is time-consuming and requires substantial effort

Engineering Contradiction:
Improveapplication dataVSAvoiddata extraction time
Core Design Contradiction:
Loss of informationVSLoss of time

Solution Approach 1:

The patent implements preliminary action by automatically instrumenting the bytecode code during the application loading phase or deployment phase. This pre-instrumentation ensures that monitoring data is automatically captured during runtime without requiring manual extraction efforts, thereby eliminating time loss while maintaining complete data collection capabilities.

Inventive Principle:
Principle #10Preliminary action

4Loss of information

If debugging techniques are used for monitoring, then detailed function call information can be obtained, but these techniques are not designed for automated monitoring extraction

Engineering Contradiction:
Improvefunction call dataVSAvoiddata extraction automation
Core Design Contradiction:
Loss of informationVSExtent of automation

Solution Approach 1:

The instrumentation manager and runtime environment implement self-service by automatically identifying, instrumenting, and collecting monitoring data from function calls without requiring external debugging tools or manual intervention. The system autonomously extracts relevant information at the bytecode level and presents it in a structured format suitable for automated monitoring and analysis.

Inventive Principle:
Principle #25Self-service

Data Source

PatentEP2587380B1Runtime environment and method for non-invasive monitoring of software applications
Publication Date: 2016.01.27 SOFTWARE AG
  • EP2587380B1 patent drawingFigure 1
  • EP2587380B1 patent drawingFigure 2a
  • EP2587380B1 patent drawingFigure 2b

AI summary

The present invention relates to a runtime environment (10) for non-invasive monitoring of software applications, wherein the runtime environment (10) is adapted for: a. during execution of at least one software application (20) within the runtime environment (10), identifying a function call (25) to be executed by the at least one software application (20); and b. generating monitoring data relating to the identified function call (25).