Zato—Agile ESB, SOA, REST and Cloud Integrations in Python

Installing Services

There are several ways to install a service:

  • Hot-deployment from the command line.

  • Hot-deployment from the browser.

  • Adding it to services-sources.txt—you can specify a path to a single module, to a Python package or a Python-dotted name by which to import it.

Let's hot-deploy what you have so far from the command line, assuming a Zato server is installed in /opt/zato/server1. You can do this using the cp command:

$ cp /opt/zato/server1/pickup-dir

Now in the server log:

INFO - - Creating tar archive
INFO - - Uploaded package id:[21],

Here's what just happened:

  • The server to be deployed was stored in an SQL database, and each server from a cluster was notified of the deployment of new code.

  • Each server made a backup of currently deployed services and stored it in the filesystem (by default, there's a circular log of the last 100 backups kept).

  • Each server imported the service and made it available for use.

All those changes were introduced throughout the whole cluster with no restarts and no reconfiguration.

Using the GUI to Configure the Resources Needed

Zato's Web admin is a GUI that can be used to create server objects that services need quickly, check runtime statistics or gather information needed for debugging purposes.

The Web admin is merely a client of Zato's own API, so everything it does also can be achieved from the command line or by user-created clients making API calls.

On top of that, server-side objects can be managed "en masse" using a JSON-based configuration that can be kept in a config repository for versioning and diffing. This allows for interesting workflows, such as creating a base configuration on a development environment and exporting it to test environments where the new configuration can be merged into an existing one, and later on, all that can be exported to production.

Figures 2–6 show the following configs:

  • Scheduler's job to invoke the service updating the cache.

  • Outgoing HTTP connection definitions for connecting to

  • HTTP channels for each client—there is no requirement that each client be given a separate channel but doing so allows one to assign different security definitions to each channel without interfering with any other.

Figure 2. Scheduler Job Creation Form

Figure 3. Outgoing HTTP Connection Creation Form

Figure 4. JSON Channel Creation Form

Figure 5. Plain XML Channel Creation Form

Figure 6. SOAP Channel Creation Form


Dariusz Suchojad is a systems architect specializing in SOA/ESB/EAI/BPM/SSO with 12 years of experience completing projects for enterprise customers in telecommunications and banking.