There was no output, because the service doesn't produce any. However,
when you check the logs you notice:

INFO - Key linuxjournal:rates:2013:09:03 set to 1.22

Now you can invoke get-rate from the command line using curl with JSON, XML
and SOAP. The very same service exposed through three independent channels
will produce output in three formats, as shown below (output slightly reformatted
for clarity).

IRA Is the Key

IRA (Interesting, Reusable, Atomic) is the key you should always keep in mind
when designing services that are to be successful.

Both the services presented in the article meet the following criteria:

I: focus on providing data interesting to multiple parties.

R: can take part in many processes and be accessed through more than one
method.

A: focus on one job only and do it well.

In this vein, Zato makes it easy for you to expose services over many
channels and to incorporate them into higher-level integration scenarios,
thereby increasing their overall attractiveness (I in IRA) to potential
client applications.

It may be helpful to think of a few ways not to design services:

Anti-I: update-cache could be turned into
two smaller services. One
would fetch data and
store it in an SQL database; the other would grab it from SQL and put
it into Redis.
Even if such a design could be defended by some rationale, neither of
the pair of services would be interesting for external applications.
A third service wrapping these two should be created and exposed
to client apps, in the case of it being necessary for other systems
to update the cache. In other words, let's keep the implementation
details inside without exposing them to the whole world.

Anti-R: hard-coding nontrivial parameters is almost always a poor
idea. The result being that a service cannot be driven by external
systems invoking it with a set of arguments.
For instance, creating a service that is limited to a specific year
only ensures its limited use outside the original project.

Anti-A: returning a list of previous queries in response to a request
may be a
need of one particular client application, but contrary to the needs
of another. In cases when a composite service becomes necessary,
it should not be obliged upon each and every client.

Designing IRA services is like designing a good programming interface
that will be released as an open-source library and used in places that
can't be predicted initially.

Born Out of Practical Experience

Zato it not only about IRA but also about codifying common admin and
programming tasks that are of a practical nature:

Each config file is versioned automatically
and kept in a local bzr repository, so it's always possible
to revert to a safe state. This is completely transparent and needs
no configuration nor management.

A frequent requirement before integration projects are started,
particularly
if certain services already are available on the platform, is to provide
usage examples in the form of message requests and responses. Zato
lets you specify that one-in-n invocations of a service be stored
for a later use, precisely so that such requirements can be
fulfilled by admins quickly.

Two popular questions asked regarding production are:
1) What are my slowest services? and
2) Which services are most commonly used?
To answer these, Zato provides statistics
that can be accessed via Web admin, CLI or API. Data can be compared over
arbitrary periods or exported to CSV as well.

Figure 7. Sample Statistics

Summary

Despite being a relatively new project, Zato is already a lightweight
yet complete solution that can be used in many integration and back-end
scenarios. Regardless of the project's underlying integration principles,
such as SOA or REST, the platform can be used to deliver scalable
architectures that are easy to use, maintain and extend.