Publish/subscribe introduction


Publish/subscribe offers advanced messaging means to REST applications, both JSON and XML - clearly separating producers of messages and applications interested in consuming information, thus forming networks of loosely coupled parties operating asynchronously with regards to the others.

Messages published using regular REST HTTP verbs are stored by Zato in Redis-based queues.

There can be more than one producer of messages to a given topic and similarly, more than one consumer can be subscribed to a topic.

Consumers either poll using HTTP for new data or provide REST callback URLs for Zato to invoke when new messages arrive in topic queues.

The same application can poll for messages in one topic yet have Zato invoke callback URLs for another.

Zato retains messages in topics until subscribers are ready to consume them or, alternatively, until messages expire.

Messages can be consumed in either FIFO or LIFO order (First In First Out or Last In First Out). Each consumer can have its own preferred consuming order independent of, and not interfering with, other consumers for the same topic.

Messages can have priorities assigned, from 1 (lowest) to 9 (highest) that may dictate the order of retrieval.

Topics and their accompanying producers or consumers can be added at any time allowing to dynamically expand capabilities of environments without interrupting other applications.

Messages are always durable and are kept in topics even if there isn’t any subscriber to a topic at the time a mesage is being published. Applications subscribing to topics at a later time will receive all such messages available in a topic.

Depending on how the underlying Redis storage server is configured, messages in topics can be persistent - sustaining restarts of Redis - or not. Restarts of Zato servers do not influence the state of topics with regards to their persistency.

Administrators use web-admin forms to manage topics, producers, consumers and check current state of queues, including means to publish messages directly from a web browser.

Subsequent chapters go through development and usage scenarios along with tasks involved in managing a publish/subscribe environment.