Services accept requests either from jobs initiated by the scheduler or via AMQP, IBM MQ, plain HTTP, SOAP and ZeroMQ channels.

Only HTTP channels are synchronous and make the requesting side wait before the response is ready.

Except for plain HTTP and SOAP channels, requests are accepted through connector processes which publish messages on Zato broker off of which they are consumed by services.

Plain HTTP and SOAP channels are exposed via Zato servers directly.

One of the key features of Zato is that precisely the same service can be exposed over multiple channels without any changes to the service’s implementation. That is, once the service has been written and deployed, it’s only a matter of a server’s configuration to make a service available through, say, AMQP in addition to ZeroMQ or HTTP.

Regardless of which channel a service was invoked over, the very same request and response objects will be available, same attributes and methods, and the service can make use of the same API for producing responses using Simple IO, JSON, XML or any other data format.

Note that you always need to take high-availability (HA) into account, particularly so if you’re using AMQP, IBM MQ or ZeroMQ channels.


In short, no programming is needed to expose a service over any channels supported. No config files need to be edited. It’s only a matter of filling out a form or two in the web admin (or using the public API if you prefer to do it programmatically) to make a service run through multiple channels.