Inter-Service Communication Management via Configuration-Based IPC Abstraction

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

In distributed software architectures, the tight coupling of business logic with specific Inter-Process Communication (IPC) mechanisms hinders portability and flexibility, making it difficult to switch between different IPC mechanisms and support multiple mechanisms simultaneously.

Innovation Solution

An inter-service communication management system that uses configuration files to specify IPC mechanisms, instantiates stubs and proxies, and manages IPC channels, allowing services to communicate independently of specific IPC APIs and formats, enabling seamless switching and support for multiple IPC mechanisms.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If business logic is tightly coupled with specific IPC mechanisms, then message exchange between services can be achieved, but portability and flexibility are hindered

Engineering Contradiction:

Improvemessage exchange capabilityVSAvoidportability

Core Design Contradiction:

ReliabilityVSAdaptability or versatility

Solution Approach 1:

The system segments the architecture into distinct layers: business logic layer and IPC mechanism layer. The business logic is separated from specific IPC implementations through interface definitions, allowing the business logic to remain platform-independent while IPC mechanisms can be swapped without affecting core functionality.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

Interface definitions act as intermediaries between business logic and IPC mechanisms. These interfaces provide a standardized communication protocol that decouples the business logic from platform-specific IPC implementations, enabling portability across different platforms.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Productivity

If services are designed with platform-specific IPC mechanisms, then optimized communication can be achieved, but switching between IPC mechanisms requires re-implementing business logic

Engineering Contradiction:

Improvecommunication efficiencyVSAvoidre-implementation effort

Core Design Contradiction:

ProductivityVSDevice complexity

Solution Approach 1:

The interface definition language creates a universal interface layer that can work with multiple different IPC mechanisms. Services define their communication interfaces in a platform-independent manner, allowing the same service to communicate efficiently through different IPC mechanisms (shared memory, sockets, pipes, etc.) without re-implementation.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system allows dynamic selection and switching of IPC mechanisms at runtime based on platform availability and performance requirements. The interface definitions remain static and reusable, while the underlying IPC implementation can be changed dynamically without affecting business logic.

Inventive Principle:

Principle #15Dynamics

3Productivity

If serialization is specific to each IPC mechanism, then efficient data exchange can be achieved, but services cannot support multiple IPC mechanisms simultaneously

Engineering Contradiction:

Improvedata exchange efficiencyVSAvoidmulti-IPC support

Core Design Contradiction:

ProductivityVSAdaptability or versatility

Solution Approach 1:

The serialization logic is extracted from the business logic and placed in the IPC mechanism layer. Interface definitions specify data structures in a platform-independent format, while actual serialization/deserialization is handled by the IPC mechanism implementation, allowing efficient platform-specific serialization without coupling business logic to specific formats.

Inventive Principle:

Principle #2Taking out (Extraction)

Data Source

PatentUS11785111B2Managing inter-service communication

Publication Date: 2023.10.10 APTIV TECHNOLOGIES AG

AI summary

This document discloses techniques, apparatuses, and systems for inter-service communication management to manage inter-service communication between a server-side service and a client-side service. The inter-service management system may comprise memory and a controller configured to perform the inter-service communication management. In aspects, a configuration file may be used to obtain information specifying a first inter-service communication mechanism for communicating one or more messages between the client-side and server-side services. The inter-service communication management system may instantiate a stub associated with the inter-service communication mechanism information, which can be used to communicate a message from the server-side service to a proxy that interacts with the client-side service. The message may then be forwarded from the proxy to the client-side service to enable inter-service communication between the server-side service and the client-side service.