Introducing Zato

My last post ended on a cliff hanger. What if there was an ESB that natively used a proper scripting language while still having all of the features you’d expect of an ESB? I said there is, and this is it… Zato.

With the tag line of “Open Source ESB, SOA, REST, APIs and Cloud Integrations in Python” and with a feature set that includes a high availability load balancer, hot deployment and reconfiguration, as well as support for a wide range of standard data formats, it’s described as being written by pragmatists for pragmatists.

Sounds good, right? It is.

At its most basic, it lets you define endpoints – referred to as channels – that can send and receive messages. Messages posted to the inbound channels are automatically converted into a Python object. That object contains the incoming payload already parsed into a suitable Python structure – in the case of JSON, for example, this will be a dictionary object. You only write code to process the message and build up an output object that then gets returned to the caller in the format specified in your channel definition.

Let’s illustrate that with a simple, if contrived, example. Say we want a JSON api that takes first name and surname and returns a greeting, again in JSON.

We start by putting the following code in

from zato.server.service import Service

class SendGreeting(Service):

    def handle(self):
        firstname = self.request.payload['firstname']
        surname = self.request.payload['surname']

        greeting = "Hello " + firstname + " " + surname

        self.response.payload = { 'greeting': greeting }

Then we deploy the code by copying it to the zato server pickup directory. This automatically creates a new service based on the filename and class called example.send-greeting.

In the admin GUI we then set up a plain HTTP channel to create the URL we will call to invoke the service:

That’s it.

Testing it out with curl gives:

curl http://linux2:11223/example/greeting -d '{"firstname": "John", "surname": "Smith"}' 

{"greeting": "Hello John Smith"} 

Couldn’t be much simpler – a request object contains the incoming message, the response object contains your reply. In between you can do whatever you need to do, in a language that makes it easy. A quick look at the documentation page gives a good idea of the range of things it supports, but the key advantage is that because you’re using Python you have the ability to write your own code to do just about anything.

It’s also pretty well documented. The tutorial takes you through installation and there’s a quickstart feature to get a working configuration up and running as soon as it’s installed. The rest of the documentation is pretty thorough.

So far so good, but what are the downsides?

It’s a pretty niche product and outside of the website and mailing list you won’t find much help on the internet. The mainstream ESBs have a wealth of blog posts, stack overflow questions and other external material if you get stuck. While the documentation is good, it would be useful to see more fully worked examples.

Being fairly obscure, it would be a tough sell to bet on it for an enterprise deployment.

The answer to both of those, of course, is to promote it and get more people using it. Open source works its way into enterprise environments by being used to solve real problems when there’s no official budget. Zato is a great fit for that, because it’s quick and easy to get started but it can scale to a full production solution in a way that a bunch of in-house scripts probably wouldn’t.

There’s also the issue of support. It looks a bit like a one man operation, at least as far as the core development is concerned, which is a legitimate concern for businesses aiming to deploy it. It’s not a risk to overstate though – scratch the surface of some big corporate enterprise products and you often find just one or two core developers who really understand them. At least with open source you’re not at risk of the vendor deciding to discontinue the product and leaving you high and dry or with an expensive conversion to another system.

I think it could also find a niche at home, and that’s how I’m going to use it. I want to link together various systems I have running, both on my server and outside of it, and I’m going to use Zato to do that.

For my first proper project, I want to record the temperature data collected by my SmartThings sensors and I’m going to try to do that by getting SmartThings talking to my ESB instance. If it works it promises to be much more flexible than trying to do the same thing entirely within the SmartThings ecosystem.

Getting into a real project is the best way to get to grips with something new, and I’m never one for learning to walk before I try running when it comes to technology. Stay tuned for the progress reports…

in Home Automation

Related Posts