This is a feature that will be added in much a broader scope - along with GUI, API and more usage examples - in next releases, but for 1.1, a zato-labs project is provided to support an invoke/retry pattern.

This can be used to implement any of these scenarios

  • invoke a service synchronously and if it fails, repeat the invocation a configured number of times waiting blockingly for the response
  • invoke a service synchronously and if it fails, invoke the service asynchronously in background notifying a callback service when it's finished, successfully or not
  • invoke a service asynchronously in background, and if it fails, repeat the invocation a configured number of times notifying a callback service when it's finished, successfully or not Install the add-on by putting it on PYTHONPATH, for instance, using pip and linking it to zato_extra_paths as below. This is a change that needs a server restart.
$ sudo pip install zato-invoke-retry
Downloading/unpacking zato-invoke-retry

...
[snip]
...

Successfully installed zato-invoke-retry
Cleaning up...
$
$ ln -s /usr/local/lib/python2.7/dist-packages/zato /opt/zato1/zato_extra_paths
$

You can now make use of invoke/retry as in the code examples below.

400: Invalid request

As an ending note, this feature is a good example of Zato's extensibility. No changes were needed to support it and only publically available features and API were used to add new value on top of existing core platform.

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.

400: Invalid request

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'

400: Invalid request

so the whole of if reads now:

400: Invalid request

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