Pub/sub topics and message queues
Publish/subscribe features are a built-in part of Zato that that lets one use it as a message broker in addition to SOA/API services and SSO and user management APIs.
Business data can be exchanged between applications using a notion of topics and delivery queues. Publishers produce messages that are routed by Zato to subscribers, applying transformation or security rules while flowing through the platform.
Each application exchanging information using publish/subscribe may use a different connection protocol and different security mechanism without influencing each other.
A key difference between publish/subscribe and point-to-point or peer-to-peer integrations is that producers of data do not necessarily need to know who the recipients will be. Conversely, the recipients do not need to know who is producing the information that they are receiving. Moreover, with publish/subscribe, neither producers nor consumers have to be up and running at the same time.
Conceptually, a topic is a named address, which can be in RAM only or backed by persistent storage, to which data is sent (published). If you are coming from an SQL background, think of a topic as if it were a table to which rows were written with each row representing a single message published to the topic.
A counterpart of a topic is a queue. Each consumer of messages, also known as a subscriber, will receive messages not from the topic directly, but from a queue of messages referencing the ones published to a given topic. Using the same SQL analogy, each subscriber would receive messages from its own table of rows referencing the messages from the main topic table, rather than from the topic table itself directly - in this way, each queue is independent of all the others.