Structural View

The middleware provides service-oriented interfaces for communication between applications running in the same process, on different cores, or in separate processes. Generated service code is split into application-facing proxies and skeletons and middleware-owned cluster and queue infrastructure.

The system is divided into the following conceptual sub-components. The names in this view describe architecture responsibilities, not necessarily one C++ class or one documentation page:

service interface proxy
service interface skeleton
cluster
queue

Service Interface Proxy: It is composed of a core part proxy_base and a generated part generated proxy. The generated proxy is created from an interface definition and sends requests through cluster_connection.
Service Interface Skeleton: It is composed of a core part skeleton_base and a generated part generated skeleton. The generated skeleton receives requests through cluster_connection and dispatches them to the application.
Cluster: A cluster owns the processing context for its service endpoints. It reads incoming messages from its queue, dispatches requests to skeletons, and routes responses and events to proxies.
Queue: A queue provides FIFO transport between cluster connections. Queue and allocator configuration is generated from the deployment model.

Note

The conceptual terms map to the current implementation as follows:

proxy_base and skeleton_base: ProxyBase and SkeletonBase in middleware/core.
cluster_connection: IClusterConnection and ClusterConnectionBase.
queue and message transport: Message, ClusterConnectionBase, and the platform/shared-memory queue configuration.
message payload handling: MessagePayloadBuilder and the memory allocator types documented by the memory-pool unit.

The units toctree documents the detailed class diagrams currently maintained for the proxy/skeleton base, request/response, and memory-pool abstractions. Cluster connection and queue behavior is documented through the component-flow diagrams because their concrete implementations are platform/deployment-specific.

' *******************************************************************************
' Copyright (c) 2026 BMW AG
'
' This program and the accompanying materials are made available under the
' terms of the Apache License Version 2.0 which is available at
' https://www.apache.org/licenses/LICENSE-2.0
'
' SPDX-License-Identifier: Apache-2.0
' *******************************************************************************

@startuml

note as conceptual_view
The labels in this diagram are conceptual architecture units.
They group implementation interfaces and platform-specific realizations;
they are not intended to name one C++ class each.
end note

package "Middleware" as middleware_de <<SEooC>> {
component "Communication Core" as communication_core_component <<component>> {
component "Proxy/Skeleton Base" as proxy_skeleton_base_unit <<unit>>
component "Request/Response" as request_response_unit <<unit>>
}

component "Communication Infrastructure" as communication_infrastructure_component <<component>> {
component "Instance Database" as instance_database_unit <<unit>>
component "Cluster Connection" as cluster_connection_unit <<unit>>
}

component "Data Structures" as data_structures_component <<component>> {
component "Message Management" as message_management_unit <<unit>>
component "Message Queue" as message_queue_unit <<unit>>
component "Memory Pool Management" as memory_pool_management_unit <<unit>>
}

component "Interface" as interface_component <<component>> {
component "Logging API" as logging_api_unit <<unit>>
component "Platform Abstraction Interface" as platform_abstraction_interface_unit <<unit>>
}

communication_core_component --> communication_infrastructure_component
communication_core_component --> interface_component
communication_infrastructure_component --> data_structures_component
communication_infrastructure_component --> interface_component
data_structures_component --> interface_component
}

@enduml — Middleware unit structure