Connectivity Framework 4: Connectivity Framework Layer
4.2 TYPICAL CONSIDERATIONS
Typical considerations for choosing a connectivity framework can be grouped into system, data, performance, scalability, availability, deployment and operational considerations. The tradeoffs in each should be carefully evaluated.
4.2.1 SYSTEM ARCHITECTURE CONSIDERATIONS
4.2.1.1 PEER-TO-PEER VS. BROKER
Peer-to-peer is a symmetric data exchange pattern between endpoints without any intermediary or broker. A peer-to-peer architecture provides the lowest latency and jitter data exchange between endpoints. It can also avoid startup dependencies, as peers can come up in any order. There is a no single point of failure or vulnerability. However, a distributed peer-to-peer based system requires more careful planning---for example, one may need relays to avoid undue load on extremely resource constrained peers.
On the other hand, a broker-based architecture requires running a centralized process on a host in the system. Data exchanges flow through the broker. It needs to be started and run before the endpoints can communicate. A broker can become a choke point and a single point of failure, if not mitigated by redundancy and load balancing. Latency and determinism can suffer, especially as data volume goes up. It can increase vulnerability from a security perspective, but provisioning and management can be centralized.
4.2.1.2 DATA-CENTRIC VS. DEVICE / APP-CENTRIC
In a data-centric architecture, the endpoint application code does not need to be aware of who produces or consumes the data. Data is regarded as a first-class citizen that can be exchanged, stored, transformed and manipulated in its own right, independently of the endpoints that produce or consume it. There is an analogy with databases, which provide a data-centric abstraction for data at rest. Data-centric connectivity frameworks provide a data-centric abstraction for data in motion. Integrating new applications requires them to have knowledge of the data-centric abstraction.
In a device-centric architecture, the endpoint application code is aware of the devices or application endpoints responsible for producing or consuming data. Devices or application endpoints are regarded as the first-class citizen, and are modeled as such; data cannot exist without the context of a device or application. Integrating new types of devices or applications requires integrating new interfaces.
Data-centric connectivity frameworks provide location, device and application independence. They allow components to be decoupled from one another, developed and integrated independently. Device-centric connectivity frameworks require application components to understand the device context to use the data meaningfully. Each kind of device is be integrated separately, and the applications are aware of their behavioral interfaces.
IIC: PUB: G5: V1.0: PB: 20170228- 33-