Check out the command line snippet and screenshot below - as of recent git master versions on GitHub it's possible to use MySQL as a Zato's SQL Operational Database. This is in addition to previously supported databases - PostgreSQL and Oracle DB.

The command shown was taken straight from the tutorial - the only difference is that MySQL has been used instead of PostgreSQL.

$ zato quickstart create ~/env/qs-1 mysql localhost 3306 zato1 zato1 localhost 6379

ODB database password (will not be echoed): 
Enter the odb_password again (will not be echoed): 

Key/value database password (will not be echoed): 
Enter the kvdb_password again (will not be echoed): 

[1/8] Certificate authority created
[2/8] ODB schema created
[3/8] ODB initial data created
[4/8] server1 created
[5/8] server2 created
[6/8] Load-balancer created
Superuser created successfully.
[7/8] Web admin created
[8/8] Management scripts created

Quickstart cluster quickstart-887030 created
Web admin user:[admin], password:[ilat-edan-atey-uram]
Start the cluster by issuing the /home/dsuch/env/qs-1/zato-qs-start.sh command
Visit https://zato.io/support for more information and support options
$ 

Screenshots

A newly added Zato feature lets one update HTTP timeouts on fly, without any redeployments.

It's been always possible to provide a timeout a given HTTP connection should be capped to. However, changing the value required either redeploying a service or storing it in an external store, such as Redis, that was queried each time a request was made. While being very lightweight, these operations still were something to remember about.

Thus recent GitHub versions allow one to update the value on fly, with no deployments or any restarts. It works with JSON, SOAP (both Suds and string-based) or any other HTTP connection established.

Screenshots

Screenshots

The feature will be released in Zato 2.0 but it's already available in git master.

The steps below describe what is needed to install Zato ESB and app server under OS X.

osx$ mkdir ~/zato && cd ~/zato
osx$ curl -O https://zato.io/download/osx/Vagrantfile
osx$ vagrant up
[snip output]
  • ssh into the newly provisioned virtual machine - Zato is installed in /opt/zato, default username/password zato/zato
osx$ vagrant ssh

And that's it - Zato is installed in the VM so you can head over to the main documentation site.

Screenshots

Screenshots

Screenshots

Screenshots

Screenshots

Kudos to Ernesto Revilla Derksen for his assistance in preparing the installation guide.

Recent works on Zato's command line interface resulted in several improvements that are available on GitHub, slated for delivery in the next release.

  • zdaemon has been replaced with sarge - this resulted in a signifact speedup and servers now start much faster.

  • Improved configuration checks provide immediate feedback when a component is found to have been misconfigured - TCP ports are checked to be free, Postgres/Oracle and Redis are pinged and the existence of pidfiles prevents components from attempting to run.

  • All the components start commands work with grew a new --fg flag indicating that a given component - servers, Django-based web admin or load-balancers, shoud start in foreground instead of going into background daemon mode. Components started in such a way can be stopped with Ctrl-C.

Screenshots

Thanks to the work sponsored by Forbrugerrådet Tænk, Zato ESB and app server has grown additional means through which it is now even easier to invoke SOAP services.

Given an existing WSDL, all that is needed is filling out a couple of forms and a pool of SOAP clients is automatically generated and available in a cluster.

Built on top of Suds, the feature is available in git master and here's a preview showing how to consume SOAP services without any need for direct XML manipulations in order to build a RESTful service validating credit card numbers with JSON output.

First, let's upload the service that will connect to SOAP and produce JSON on output.

Note that the service doesn't really know what type of output it produces - this is configured from the GUI and no code changes are needed for the service to produce XML instead of JSON.

# -*- coding: utf-8 -*-

# Zato
from zato.server.service import Service

class ValidateCreditCard(Service):

    class SimpleIO:
        input_required = ('number',)
        output_required = ('card_type', 'is_valid')

    def handle(self):
        conn = self.outgoing.soap['Credit Card Validator'].conn

        with conn.client() as client:

            # Invoke a SOAP service dynamically with no need for stub classes
            result = client.service.CheckCC(self.request.input.number)

            # Results are turned into Python objects automatically
            self.response.payload.card_type = result.CardType
            self.response.payload.is_valid = result.CardValid

While not strictly required, let's say we need to secure our REST service with Basic Auth:

Screenshot

Now a channel is created through which requests will flow in. Note that the URL path is a pattern - all named attributes, such as number here, are available as input to services.

And although it's not used in this example, both JSON or XML can be mixed on input with URL parameters with full control of what has priority over other parts.

Screenshot

Next an outgoing SOAP connection is needed. Note that its serialization type is Suds - this is the new feature. The WSDL points to a free SOAP service online courtesy of CDYNE.

In the example below, each server will be given a pool of 20 SOAP clients, each generated dynamically on fly from the WSDL provided on input.

If you're coming from Java or C# background you'll note that no stubs nor client classes need to be generated. This is all taken care of behind the scenes so one can focus on invoking SOAP services straightaway.

Screenshots

With all that in place, the Zato service can now be invoked. curl is used from command line in the examples below:

$ curl -u user:password localhost:17010/validate-cc/4111111111111111 {"response": {"card_type": "VISA", "is_valid": true}}
$
$ curl -u user:password localhost:17010/validate-cc/123456789 {"response": {"card_type": "NONE", "is_valid": false}}
$

What if the WSDL changes with time? You only need to click 'Reload WSDL' and a new pool of SOAP clients will be created using the newest contents.

Screenshot

The feature will be released in the upcoming 2.0 release and until then - please use git master version.