Article presenting a scalable integration pattern utilizing OpenStack Swift connections, a feature to be released in Zato 2.0, to connect independent applications in an asynchronous manner.

Let's say your application receives invoices that need to be distributed to multiple target applications using a cloud storage.

It doesn't matter how many input channel there are, how many receivers there will be or what the transport protocol and data format are - the approach needs to be generic and re-usable.

Here's how one would tackle it in Python with Zato ESB and app server.

First using the web-admin, a connection to OpenStack needs to be defined. This particular one uses Rackspace but any OpenStack provider will do.

Screenshots

Screenshots

Note that filling out a form suffices for a pool of clients to be created and made available on all nodes of a Zato cluster, as confirmed in server logs.

Screenshots

Next you need to hot-deploy a service, such as the one below.

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

from __future__ import absolute_import, division, print_function, unicode_literals

# Zato
from zato.server.service import List, Service

class InvoiceDispatcher(Service):
    name = 'invoice.dispatcher'

    class SimpleIO:
        input_required = (List('target'),)

    def handle(self):

        # Grab a connection wrapper
        conn = self.cloud.openstack.swift['Invoice Dispatcher'].conn

        # Fetch a client for that connection
        with conn.client() as client:

            # Iterate over targets and store the invoice in the cloud
            for target in self.request.input.target:
                client.put_object(target, 'Invoice', self.request.raw_request)

Note the use of SimpleIO - this is a declarative syntax for expressing requests and responses independent of how the data is transported, in query string parameters, JSON, XML or SOAP.

This service expects a list of elements called 'target' to be provided on input. In the article, the list will be produced using the query string but it could have been any other source as well and the service wouldn't care as long as they were available on input.

Once a service has been deployed a JSON channel is needed, again filling out a form is enough.

Screenshots

And that's it. That's the whole of it. You can now invoke the service over HTTP with JSON/XML/SOAP, AMQP, ZeroMQ or perhaps WebSphere MQ, including JMS.

The trick is - no code changes would have been ever required, the same service can handle multiple channels or target applications without ever touching the code. Everything is a matter of configuration and the service itself is re-usable in many contexts (R in IRA of Interesting, Reusable and Atomic).

Likewise, if one day you decide to change the OpenStack provider no code changes will be needed - filling out a form with new credentials would be enough. The changes will propagate throughout the whole cluster with no restarts, unless your deployment methodology needs them.

For clarity's sake, curl will now be used to invoke the newly deployed service but the same would have been achieved if say, AMQP with XML had been used instead of curl with JSON ..

$ curl "localhost:11223/invoice.dispatcher?target=CRM&target=Billing" -d '{"id":"123"}'

.. and the result in OpenStack-based Rackspace Cloud Files is ..

Screenshots

Screenshots

Note that GUI is not the only way to configure Zato - everything the GUI does is always available through command line, enmasse, and the admin API so while being a powerful ally web-admin is not the only way for managing Zato clusters.

Regardless of the config method, no restarts are required unless you need them - everything can be always reconfigured on fly.

The next installment will cover the other side of the story - means to receive requests over cloud connections sent by other applications connecting to Zato-based solutions.