Communication between entities (i.e. exchange of information). Communication is a concern and relates to the following levels:
This architectural pattern relates to the following roles:
An essential set of communication patterns that is rich enough to cover common communication use-cases, yet at the same time reduced enough to support composability.
Different middlewares allow for different middleware abstraction levels. For instance, message-based middlewares require a protocol-based abstraction, while e.g. DDS allows for a higher level of abstraction (i.e. directly using the publish/subscribe communication with accordingly preselected QoS attributes). In any case, middleware details should be hidden from both, the component’s internal communication access and the communication semantics between components.
The separation of patterns into groups for Communication (i.e. continuous data exchange), Configuration (i.e. parametrization of individual components) and Coordination (i.e. skill-component interaction) provides solutions for recurring communication problems and clarifies the purpose of a particular pattern.
The communication access from within a component (i.e. communication interface access) needs to be as flexible as possible as long as it does not violate with the clearly specified communication semantics outside of the component (resp. between interacting components).
Not every semantic detail needs to be made explicit on model level (some may come from “de-facto standard” implementations). The focus in models need to be on a consistent representation and systematic management of different communication schemes.
This document contains material from: