Kaa framework consists of the Kaa server and endpoint components. The endpoint component is a library that integrates with the client application to implement communication, data marshaling, persistence, and other functions. It is the responsibility of the client application to process the structured data provided by the Kaa endpoint library (configuration, notifications, etc.), and to supply data to the return path interfaces (profiles, logs, etc.).
A single Kaa installation is able to support multiple business entities (tenants) and multiple applications. As illustrated in the figure below, applications belong to the tenants, and endpoints register within applications.
Kaa server implements the back-end part of the framework, exposes integration interfaces, and offers administrative capabilities.
The server is comprised of the Control, Operations, and Bootstrap servers. It also uses third-party database(s) for data persistence and Apache ZooKeeper for servers coordination. Web UI is a standalone component that integrates with the Control server for Kaa administration.
Kaa Control server is responsible for managing overall system data, processing API calls from the Web UI and external integrated systems, and delivering notifications to the Operations servers. Control server manages the data stored in the database (independently for each tenant) and notifies every Operations server on most data updates via a Thrift-based protocol. The up-to-date list of Operations servers is provided to the Control server by ZooKeeper.
To support high availability, a Kaa cluster must have at least two Control servers, one of which is active, and others in standby mode. In case of an active Control server failure, ZooKeeper notifies one of the standby Control servers and promotes it to active.
Kaa Operations server is a “worker” server that is responsible for concurrently handling multiple requests from multiple clients. Most common Operations server tasks include endpoint registration, endpoint profile update, configuration updates distribution, and notifications delivery.
Multiple Operations servers may be set up in a Kaa cluster for horizontal scaling. All of the Operations servers would function concurrently. In case of an Operations server outage, endpoints would switch to the next available server automatically. Kaa cluster provides instruments for runtime re-balancing of the workload, effectively diverting endpoints to the less loaded Operations servers.
Kaa Bootstrap server is responsible for directing clients to the Operations servers. Kaa endpoints have a built-in list of Bootstrap servers in the Kaa deployment. The endpoints query the Bootstrap servers to obtain a list of currently available Operations servers along with the security credentials. Bootstrap servers maintain their lists of available Operations servers by consulting with the ZooKeeper service.
The endpoint library implements functionality for communicating with the Kaa server, managing data locally in the client application, and provides integration APIs. The library abstracts the communication protocol, data persistence, and other implementations details that may be specific to any concrete solution based on Kaa.
After you familiarize yourself with all the sections in Design reference, use the following guides and references to advance further into Kaa. We also assume that you're already through with Kaa installation as described in either Sandbox or Installation guide. Make sure you did not skip the Getting started page as it allows you to quickly create your first Kaa application.
|Guide||What it is for|
|Administration UI guide||Use this guide to start working with the Kaa web UI.|
|Programming guide||Use this guide to create your own Kaa applications.|
|Contribute to Kaa||Use this guide to learn how to contribute to Kaa project and which code/documentation style conventions we use.|