Zaqar is a multi-tenant cloud messaging and notification service for web and mobile developers.
The service features a REST API, which developers can use to send messages between various components of their SaaS and mobile applications, by using a variety of communication patterns. Underlying this API is an efficient messaging engine designed with scalability and security in mind. The Websocket API is also available.
Other OpenStack components can integrate with Zaqar to surface events to end users and to communicate with guest agents that run in the “over-cloud” layer.
This documentation is generated by the Sphinx toolkit and lives in the Zaqar project source tree. Additional draft and project documentation regarding Zaqar and other components of OpenStack can be found on the OpenStack Wiki, as well as in the user guides found on docs.openstack.org.
Zaqar provides the following key features:
The Zaqar API is data-oriented. That is, it does not provision message brokers and expose those directly to clients. Instead, the API acts as a bridge between the client and one or more backends. A provisioning service for message brokers, however useful, serves a somewhat different market from what Zaqar is targeting today. With that in mind, if users are interested in a broker provisioning service, the community should consider starting a new project to address that need.
Zaqar, as with all OpenStack projects, is designed with the following guidelines in mind:
Zaqar is composed of two layers:
The transport drivers are responsible for interacting with Zaqar clients. Every query made by clients is processed by the transport layer, which is in charge of passing this information to the backend and then returning the response in a format understandable by the client.
The storage drivers are responsible for interacting with the storage backends and, that way, store or retrieve the data coming from the transport layer.
In order to keep these layers decoupled, we have established that checks should be performed in the appropriate layer. In other words, transport drivers must guarantee that the incoming data is well-formed and storage drivers must enforce their data model stays consistent.