Generated Middleware Interface for Stable Hardware Access APIs
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Custom streaming channels between the system and framework layers in computing devices cause compatibility issues when the application programming interface (API) for the system layer changes, requiring rewriting and redesign.
Innovation Solution
A middleware interface is automatically generated using a hardware abstraction layer interface definition language (HIDL) to provide a consistent interface between the system and framework layers, comprising a server stub, client proxy, and middleware interface specification, allowing processes to access hardware without custom streaming channels.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If custom streaming channels are used to communicate between system layer and framework layer across separate computing devices, then communication between layers is enabled, but compatibility issues arise when system layer API changes, requiring rewriting or redesign of streaming channels
Solution Approach 1:
The patent introduces a middleware interface as an intermediary layer between the system layer and framework layer. This middleware interface includes a server stub on the system layer and a client proxy on the framework layer, which communicate through a standardized interface definition. The intermediary absorbs API changes in the system layer, allowing the framework layer to maintain compatibility without direct coupling to system layer changes.
Solution Approach 2:
The patent segments the communication interface into distinct components: the system layer with its hardware access library, the middleware interface with server stub and client proxy, and the framework layer with its own services. This segmentation allows each layer to evolve independently while maintaining standardized interaction points through the middleware interface definition.
2Productivity
If custom streaming channels are implemented for communication between system and framework layers, then layer communication is achieved, but frequent updates are required when API changes occur
Solution Approach 1:
The middleware interface acts as a stable intermediary that shields the framework layer from system layer API changes. When the system layer updates its API, only the server stub needs to be updated, while the client proxy and framework layer services continue to function with the same interface definition, eliminating the need for frequent updates across the board.
Solution Approach 2:
The interface definition serves as a preliminary contract that is generated before implementation. By defining the communication interface in advance and using code generation tools to create server stubs and client proxies from this definition, the system ensures that updates only affect the generated code rather than requiring manual rewriting of communication channels.
3Reliability
If a standardized middleware interface is generated using HIDL, then compatibility and fault localization are improved, but additional generation steps and tools are required
Solution Approach 1:
The system uses self-service code generation where the HIDL interface definition automatically generates the server stub, client proxy, and middleware interface specification through compiler tools. This eliminates manual implementation errors and ensures consistency across all components, improving reliability while the automation handles the complexity of generation.
Solution Approach 2:
The HIDL interface definition language serves multiple functions simultaneously: it defines the communication protocol, generates server stubs for the system layer, generates client proxies for the framework layer, and creates middleware interface specifications. This multi-functionality reduces the need for separate tools and manual processes.
Data Source
Figure 1A
Figure 1B
Figure 2
AI summary
A computer system exposes a hardware access library providing an interface for commanding an I/O device of the computer system. The computer system launches an agent process that can receives a request from a remote process to command the I/O device. The agent process invokes a first call to a middleware driver, the middleware driver invokes a second call to the client proxy, and the client proxy invokes a third call to a server stub, and the server stub accesses the input/output device responsive to receiving the third call via the hardware access library.