Communication - universAAL/middleware GitHub Wiki
To provide for a higher level of independence of the users of the middleware (as the communicating parties) from each other, no assumptions about the whereabouts of the parties should be made. In that sense, the middleware is acting as a broker between the communicating parties. This brokerage must handle the exchange of messages in a way that the heterogeneity of technologies used by the communicating parties is absorbed by the middleware.
Providing such a generalized support for communication regardless of which components from which layers the communicating parties are, needs a thorough analysis of the communication patterns in open distributed systems so that quasi the most generalized solution for covering all of the specific communication cases can be worked out.
The API of this building block introduces a high-level protocol for interoperability over all of the more specific protocols used to realize Discovery & Peering at the device level, and extends the scope of seamless connectivity to the level of end-to-end communication between software components. This API together with the underlying information model should be the only visible interfaces to the world outside the middleware for brokerage.
The communication building block defines how data is transported from the sender to the receivers. For the data exchange between the communicating parties different communication modes (e.g., event based communication vs. request/reply) may be supported. Additionally, possible roles that are involved in the communication (e.g., publisher, subscriber, requestor, responder) need to be specified.
This building block consists of two main components:
- the bus model, which provides the base for concrete brokers, and
- the control broker, a specialized broker for control messages between nodes.
See building block Black-box description
| Artefact: Bus Model | |
|---|---|
| Maven artefact | org.universAAL.middleware / mw.bus.model {.core/.osgi} |
| Pax Composite bundle | scan-composite:mvn:org.universAAL.middleware/mw.bus.model.osgi/x.y.0/composite |
| Karaf Feature | - |
| Maven Site |
https://universaal.github.io/middleware/middleware.core/mw.bus.model.core/index.html https://universaal.github.io/middleware/middleware.osgi/mw.bus.model.osgi/index.html |
- Base for buses providing basic support and definition of
- Communication Modes
- Roles
- Message based communication
- Encryption of messages
- Brokerage: The sender of a message does not have to know whether the receivers are located on the same node or if they are distributed in a, possibly heterogeneous, network. For a message that has been passed to the communication building block (using the provided API) the nodes at which the receivers reside are determined. Afterwards, the message is forwarded to the target nodes using the protocol of the network which connects the target nodes with the sending node. At the receiving nodes the software components interested in the message are identified, and finally the message is delivered to those components.
-
Communication Modes: The communication modes specify how the exchange of data from the sender to receivers is managed. Serveral different modes are possible, where each of them has advantages and drawbacks depending on the concrete application. Examples of communication modes are:
- Event communication: Data is exchanged upon the arrival of an significant event (e.g., a change in the context)
- Data streaming: Data is exchanged continuously (e.g., a video stream)
- Request/Response: One party requests some data or service from another party. The second side finally answers (possibly after executing the requested service) with a response message containing the requested data or output of the service.
-
Roles in communication: Depending on the communication modes different roles in the exchange of data are possible. Thereby the role determines the behaviour of the involved parties. Examples of communication roles are:
- Publisher/Subscriber: These roles are especially applicable for event communication or data streaming. The software component that is pushing data to the communication channel is called publisher. On the other side, subscribers can register to that channel and get notified when new data has arrived. In case a subscriber is only interested in a particular type of data, it can specify filtering options when it registers to the communication channel.
- Requestor/Responder: Whenever a requestor is interested in some data or the execution of a service, it sends a request message to a component that can handle the request. This latter component is called responder, as it anwers to the request with a response message that contains the data or the output of the service, which the requestor previously asked for.
-
Cross Layer Functionalities: Depending on the application context, the communication platform and network topology the middleware should be able to exploit all the ISO/OSI stack information to optimize the communication on the network. Moreover, at application level, we may need to adapt the behaviour automatically without an explicit user intervention, or to be constrained to the operating system configuration:
- A context-aware application should be able to choose the access medium on the basis of both the user profile (e.g. cost policy), situation (e.g. emergency) and the feedbacks from the network interfaces status (availability of UMTS, WiFi, WiMAX, Quality of the Services and so on).
- A video application changes the data stream rate according to the notification of a certain level of congestion gathered by the transport layer. The resulting outcome could be a tunable data stream driven by the network congestion status.
- Differently from other cases, for performance reasons in data distribution services, the middleware may need to select different types of addressing: unicast, broadcast or even creating multicast groups.
The role of the Control Broker is twofold. First it manages the messages used in order to request the installation/un-installation of universAAL into the uSpace, second it separates the Manager layer (for example the DeployManager and uSpaceManager) from the Module layer.
| Artefact: Control Broker Core | |
|---|---|
| Maven artefact | org.universAAL.middleware / mw.brokers.control {.core/.osgi} |
| Pax Composite bundle | scan-composite:mvn:org.universAAL.middleware/mw.brokers.control.osgi/x.y.0/composite |
| Karaf Feature | - |
| Maven Site |
https://universaal.github.io/middleware/middleware.core/mw.brokers.control.core/index.html https://universaal.github.io/middleware/middleware.osgi/mw.brokers.control.osgi/index.html |
- Decouple the Manager from the Module layer
- Manages the deploy messages used for the installation and un-installation of uAAP inside the uSpace.