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 -