Communication model

This chapter describes the details of the communication model of the PalCom Open Architecture, defines the different parts that make up the communication model, the use of those parts, and discusses the detailed structure of some of these parts and their protocols.

The communication model is a fundamental aspect of the architecture. It allows the deployed and running services to collaborate with each other by firstly discovering each other, and thereafter allowing the services to communicate individually or in groups, locally on a device or between multiple physically separated devices.

Figure above: The layered, modularized communication model.

The main goal of the communication model is to offer a simple, yet powerful model to the services providing:

Portability. Services written in different programming languages, running on different hardware platforms are able to communicate using a shared communication protocol on top of an available network technology.
Applicability. An API that provides the mechanisms commonly needed by the service developer. Yet easy-to-use and well-designed, shielding the complexity of the underlying networking technologies.
Robustness. Partial failures of the distributed system are handled as they are detected, and the loss of system capability is proportional to the size of the faulty part. Moreover, suitable contingency mechanisms are in place to ensure that the system reconfigures itself to minimize the impact of faults.
Modularity. A modular design allowing for scaling the communication capabilities going from simple communication capabilities on resource constrained devices to rich communication capabilities on advanced devices.

The communication model is split into a number of layers, each consisting of a number of communication components. Each layer provides a level of abstraction, which hides implementation details from the components at the higher-level layers. The layered communication model is illustrated in the figure above.

The logical abstractions provided by the layers may or may not be observed by higher-level layers, including services. A service may decide to use a low-level layer rather than the layer directly below it, if it provides a better fit for its communication requirements. This, however, should be avoided since the clients of such service will have to understand its protocol.

Not all components in each layer are mandatory. Components may be present in the PalCom runtime environment according to its needs, resource and hardware capabilities. However, if a particular component is present, then all components on which it depends have to be present too.