InfoQ has just published an article on Zato - covers Zato's architecture, goes through all of its main features and presents a sample integration using Yahoo YQL/JSON and Google XML with a goal of exposing their financial APIs.

All that in a concise and straight-to-the-point manner, including code samples, screenshots and CLI usage examples.

To everyone coming here from InfoQ - hello and have a nice stay :-)

As suggested on the zeromq-dev list, here's an integration example making use of ZeroMQ.

THE CODE

Say you need to forward messages sent from ZeroMQ-based apps to AMQP and JMS WebSphere MQ ones.

No message transformation, no enrichment, validations - simply connect several incompatible technologies and, possibly, programming languages (let's say ZeroMQ one is in C++, AMQP is in Python and JMS is, unsurprisingly, in Java), like in the diagram below.

Diagram

This is the whole code needed. 2 lines in addition to an import and class/method definition.

THE PHILOSOPHY

Zato is an open-source middleware/ESB (Enterprise Service Bus) and backend server in Python designed for connecting other applications and creating systems of systems. This also known as working in SOA - Service Oriented Architecture.

You create interesting, reusable, atomic and loosely-coupled services that are shielded from underlying technologies, transport methods or data formats. You can trivially access raw requests but you usually don't need to, you work on a higher level.

Services can be simultaneously exposed over independent channels, each possibly using different data format, transport method or security definition.

Almost everything in Zato is hot-deployed and hot-reconfigured, restarts are rarely needed.

You can use GUI, CLI, API or (for devops seeking repeatable builds) manage objects en masse using a JSON config.

Let's use the GUI in this blog post. 3 things will be needed:

Screenshot Screenshot Screenshot Screenshot Screenshot

AND MORE

What if out of a sudden another application needs to push data, say, through HTTP (which as of Zato 1.1 happens to be the only way to invoke services synchronously), using SOAP, JSON or anything?

Diagram

You'll have to create a new HTTP channel, using GUI or other tools, and that's it. The service will have now been exposed through another channel, servers are automatically reconfigured and you can start invoking the service from HTTP, no restarts are needed.

Screenshot

You can also check the service's source code directly in the browser, browse its statistics and do more using the GUI, CLI or API.

WHAT'S NEXT?

This was only a very simple example of a pass-through router and Zato can do much more. Please have a look programming examples, architecture, intro to ESB/SOA and more documentation over here.

Zato has HTTP, JSON, SOAP, SQL, AMQP, JMS WebSphere MQ, ZeroMQ, Redis NoSQL, FTP, browser-based GUI, CLI, API, security, statistics, job scheduling, load-balancing, hot-deployment and a lot of docs to cover everything.

The tutorial will quickly help you get started using a scaled-down real-world integration example.

Please check out the support page if you'd like to chat or need assistance with anything.

Cheers!

Imagine, or recall, a scenario. You integrate three applications, two client HTTP ones and the third is a backend one (no matter the technology).

All is well except client1 tends to send requests in bursts for no good reason and its developers just cannot tame it.

The backend app can't deal with it, they prefer a steady inflow of messages, and you're tasked with containing the issue.

In that situation you can take advantage of the fact that Zato uses an embedded instance of HAProxy as its load-balancer through which HTTP apps connect so you can fire up the GUI in config's source code view and add these lines to 'frontend front_http_plain'

so the whole of if reads now:

The GUI can be now used to validate and save the config:

Screenshot

There's a couple of assumptions

  • Instead of HAProxy 1.4, you use 1.5 (or later, but this is the latest version as of the time of this writing)
  • Each client accesses URLs beginning with a client-specific prefix - but this is a good idea anyway

It was always possible to use GUI, API or a service to ping an outgoing HTTP/SOAP connection - the idea behind it is that you pretty much always want to check whether it is your servers that can connect to remote services not that you can access remote resources from your local host as it doesn't tell you, for instance, if firewalls between the servers and outside world are configured properly.

As suggested on GitHub, a new thing in 2.0 will be the option to specify what HTTP method to use for pings. This used to be always HEAD but can now be configured though HEAD is still the default one if you don't choose anything else.

Screenshot Screenshot

Did you know that you could invoke any service from command line? This works with both Zato's own API and the services you develop. Depending on how a service is implemented/what it's exposed through, it can be done with JSON, plain XML, SOAP or any other data format a service accepts.

This will work even if a service isn't available over any channel and can be used to quickly test things out or to script Zato in bash or any other shell language.

For instance, browsing the API we can see there's a zato.security.basic-auth.get-list service which returns a list of all HTTP Basic Auth security definitions on a given cluster. Given that it's part of the API it can be invoked from command line using JSON or XML (or SOAP but let's skip that part here), as below. Output a bit reformatted for clarity

This also works for asynchronous invocations and can be used to make a service think it's been invoked through any channel type.

And by the way - the GUI can be used for invoking services directly too.