Since version 3.0, it is possible to directly connect Zato clusters and exchange messages as though remote services where running in a local instance. This makes it an ideal choice for environments split into multiple parts.

Introduction

The reasons to have more than one cluster, each with one or more servers, may vary:

  • For HA and performance, environments may be broken out geographically into a setup with one cluster per continent or a region of the world
  • CPU-extensive operations may be carried out in one cluster with another making use of the results the former produces to offer a set of APIs
  • For legal reasons, it may not be allowed to run all integration services in one cluster, using the same hardware and software infrastructure

The new feature in Zato 3.0 which allows for efficient communication between clusters are WebSocket connections - one of clusters will create a channel through with other clusters may invoke its services via their outgoing connections.

WebSockets (WSX for short) have essentially no overhead in practice but they can be used for bi-directional communication hence they are a great choice for such scenarios.

From a Zato programmer's perspective, all the communication details are hidden and a couple of lines of code suffices to invoke services or receive messages from remote clusters, for instance:

# Obtain a handle to a remote connection
with self.out.wsx.get('My Connection').conn.client() as client:

    # Invoke a remote service - expects a Python dict on input
    # and returns a Python dict on response. All the serialization
    # and network connectivity is handled automatically.
    response = client.invoke(msg)

Architecture and configuration

Screenshots

  • Each cluster which is to become a recipient of messages from other clusters needs to have a new WebSocket channel created with service helpers.web-sockets-gateway mounted on it. A security definition should also be attached as required.

  • Each cluster that should invoke another one needs to have an outgoing WebSocket connection created - make sure Is remote end Zato checkbox is on and that credentials are provided, if required by the other side.

  • If the cluster with an outgoing connection is interested in receiving publish/subscribe messages, all topics it wants to subscribe to should be listed, one in each line. Make sure the cluster with a channel has a correct pub/sub endpoint configured for that channel.

  • The cluster which establishes the connection (here, cluster1) may also want to subscribe to events of interest via hooks services - more about it below.

  • Once an outgoing connection is created, internal tasks will start on cluster1 to establish a remote connection to server2. If successful, authentication will take place automatically. Finally, if configured, a hook service will fire to let cluster1 know that a new connection was established. Afterwards, cluster1 may start to invoke remote services.

  • There are no other steps involved, at this point everything is configured and ready to be used.

Screenshots

Screenshots

From a programmer's perspective

  • To invoke remote Zato services, programmers use WebSockets outgoing connections methods - providing a dictionary of input data to the invocation and receiving a dictionary of data on input. Note that the invocation is synchronous, your service is blocked until the remote cluster responds.
# -*- coding: utf-8 -*-

from __future__ import absolute_import, division, print_function, unicode_literals

from zato.server.service import Service

class MyService(Service):
    def handle(self):

        # Message to send - needs to be a dictionary with name
        # of the service to invoke as well as its input data, if any is required.
        # In this case, we are invoking an echo service
        # which writes back to output anything it receives on input.
        msg = {
             'service':'zato.helpers.echo',
             'request': {
                 'elem1': 'value1',
                 'elem2': 'value2',
             }
         }

        # Name of the connection to send messages through
        conn_name = 'My WSX Outconn'

        # Obtain a client from the connection pool
        with self.out.wsx.get(conn_name).conn.client() as client:

            # Send the message and read its response
            response = client.send(msg)

            # Or, client.invoke can be used with Zato WebSocket connections,
            # this method is an alias to client.send
            response = client.invoke(msg)

            # Log the response received
            self.logger.info('Response is `%s`', response.data)
INFO - Response is `{u'elem2': u'value2', u'elem1': u'value1'}`
  • To receive messages, hook services are used. There are three events for which hooks can be triggered - they can be handled by different services or the same one, it is up to users:
  1. Upon connecting to a remote cluster, including reconnects (on_connect)
  2. Upon receiving messages from remote clusters (on_message)
  3. Once a connection to the remote cluster is shut down (on_close)
  • The on_message hook can be combined with publish/subscribe topics and queues - each time the remote cluster (the one with a WSX channel) publishes a message that the local cluster (the one with a WSX outgoing connection) is interested in, the on_message hook will be called to handle it, in this manner making it possible for remote clusters to deliver messages to clusters subscribing to topics.

  • Each hook is just a Zato service with a specific SimpleIO signature, as in the on_message example below:

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

from __future__ import absolute_import, division, print_function, unicode_literals

from zato.server.service import Opaque, Service

class OnMessageHook(Service):
    class SimpleIO:
        input_optional = (Opaque('ctx'),)

    def handle(self):

        # Object describing incoming data
        ctx = self.request.input.ctx

        # Message type
        msg_type = ctx.type

        # Data received
        data = ctx.data

        # Log message type
        self.logger.info('Msg type: `%s`', msg_type)

        # Log actual data
        self.logger.info('Data received: `%s`', data.data)

        # Log metadata - ID and timestamp
        self.logger.info('Meta: `%s` `%s`', data.id, data.timestamp)

Now, we can use web-admin to publish a test message and confirm that the on_message service receives it:

Screenshots

In the on_message service's server logs:

INFO - Msg type: `message`
INFO - Data received: `[
  {u'delivery_count': 0,
   u'msg_id': u'zpsme26726911ffbe8cba2cca278',
   u'expiration_time_iso': u'2086-09-21T14:03:05.285470',
   u'topic_name': u'/customer/new',
   u'pub_time_iso': u'2018-09-03T10:48:58.285470',
   u'priority': 5,
   u'expiration': 2147483647000,
   u'has_gd': True,
   u'data': u'This is a sample message',
   u'sub_key': u'zpsk.websockets.6ef529f7cab64a71d8bd2878',
   u'mime_type': u'text/plain',
   u'size': 24}
  ]`
INFO - `6fd296ecf78493a3a0ce7570` `2018-09-03T10:49:00.540024`

Summary

Zato 3.0 has just been released - this is a major release that brings a lot of immensely interesting API integration features.

Zato is an enterprise open-source Python-based ESB/SOA/API integration platform and backend application server.

It is designed specifically for construction of online, mobile, IoT, middleware and backend Python systems running in banking, telecommunications, health-care, insurance, education, public administration or other environments that require integrations of multiple applications.

Highlight of the release are:

Here is the documentation, downloads and full changelog.

Screenshots

Screenshots

Screenshots

Screenshots

Screenshots

Screenshots

Screenshots

Screenshots

As an enterprise integration platform and backend, API-oriented, application server, Zato 3.0 ships with Single Sign-On and User Management APIs whose many exciting features are detailed in this blog post.

Screenshots

  • No need for maintaining one's own user database

  • Everything is API-based - user creation, updates, logging in, logging out, checking access, creating sessions, validating sessions, search, there is an API call for everything

  • Strong encryption and safe data storage assist in achieving compliance with regulations such as HIPAA or EU GDPR

  • APIs exist for both REST and Python calls which means that everything is also available to user-based services communicating through additional protocols, such as AMQP, WebSockets, ZeroMQ, IBM MQ or any other that Zato supports

  • Comes with a built-in workflow for user signup, including user approval and welcome messages - just fill in the email templates

  • Personally Identifiable Information (PII) can be optionally encrypted and decrypted without any programming needed

  • Both users and their sessions can be given arbitrary key/value tags, also optionally encrypted and decrypted on the fly

  • Users can be required to log in from selected applications only

  • Users can be required to access APIs from selected IP addresses only

  • Passwords are always hashed (PBKDF2) and, by default, encrypted as well (Fernet)

  • PBKDF2 parameters can be easily fine-tuned in each environment separately

  • Configurable warnings of an approaching password expiry

  • Password strength enforcement, including length checks and blacklisting of the most commonly used ones

  • Audit log keeps track of who accesses personal information and for what purpose

  • Clearly defined roles - regular users and admins (super-users)

  • Convenient command line tools for scripted management of user accounts, including typical tasks such as resetting a user's password or locking and unlocking an account

  • Extensive documentation covering the functionality, including dozens of REST and Python examples

The functionality is a major addition to Zato in version 3.0 and can be expected to expand with each new release, including support for additional authentication methods and interoperability with existing authentication protocols, yet in its initial form it can already handle a lot of use-cases and processes.

In particular, if you are creating applications that would not otherwise need a full server nor a database, e.g. single-page apps or mobile ones, be sure to check the new APIs out!

With the addition of WebSocket channels in Zato 3.0, a question arises of how to combine both HTTP and WebSocket channels in Zato environments. This article shows how a Docker container running in AWS can be configured to expose a single port to handle both kind of requests, including health-status checks from Amazon's ALB (Application Load Balancer).

Configuration

The configuration we would like to arrive at is in the diagram below:

Screenshots

  • There is ALB (Application Load Balancer) which sends HTTP pings to Zato, expecting an HTTP 200 OK response if everything is fine
  • There are WebSocket-based clients (WSX) that send their own business requests, independent of regular HTTP ones
  • A Docker container holds a Zato environment, publishing port 11224 to the outside world, to ALB and WSX
  • Inside the container, Zato's load-balancer, based on HAProxy, distributes requests individual TCP sockets of a Zato server
  • If the request begins with a well-known prefix (here, /ws), it is forwarded to a WebSocket channel on port 48902
  • All other requests, including the one from ALB, will go the default HTTP port at 17010

WebSocket channel

First step is to ensure that a WebSocket channel's path begins with the desired prefix, such as /ws, as in the screenshot.

Screenshots

HAProxy

Now, HAProxy needs to be reconfigured in its source code view, from web-admin:

Screenshots

  • The changes required need to go the stanza called 'front_http_plain' - right after its current content add the lines with logic that will separate incoming requests into WebSocket ones or any other.

  • Next, add a new HAProxy backend pointing to the WebSocket channel created earlier.

  • Now, stop and start the load-balancer again

# ##############################################################################

frontend front_http_plain

    ...

    acl is_websocket path_beg /ws
    acl is_websocket hdr(Upgrade) -i WebSocket
    use_backend websockets if is_websocket

# ##############################################################################

backend websockets
    mode http
    option http-server-close
    option forceclose

    server http_plain--server1 127.0.0.1:48902 check inter 2s rise 2 fall 2

# ##############################################################################

That's it

There are no more steps as far Zato is concerned - if a Docker container is now started with port 11224 mapped to 11223 inside the container, all the external applications will be able to access Zato-based services using both HTTP and WebSockets through a single port:

$ docker run -p 11224:11223 zato

WebSphere MQ is a messaging middleware by IBM - a message queue server - and this post shows how to integrate with MQ from Python and Zato.

The article will go through a short process that will let you:

  • Send messages to queues in 1 line of Python code
  • Receive messages from queues without coding
  • Seamlessly integrate with Java JMS applications - frequently found in WebSphere MQ environments
  • Push MQ messages from Django or Flask

Prerequisites

Preliminary steps

  • Obtain connection details and credentials to the queue manager that you will be connecting to:

    • host, e.g. 10.151.13.11
    • port, e.g. 1414
    • channel name, e.g. DEV.SVRCONN.1
    • queue manager name (optional)
    • username (optional)
    • password (optional)
  • Install Zato

  • On the same system that Zato is on, install a WebSphere MQ Client - this is an umbrella term for a set of development headers and libraries that let applications connect to remote queue managers

  • Install PyMQI - an additional dependency implementing the low-level proprietary MQ protocol. Note that you need to use the pip command that Zato ships with:

# Assuming Zato is in /opt/zato/current
zato$ cd /opt/zato/current/bin
zato$ ./pip install pymqi
  • That is it - everything is installed and the rest is a matter of configuration

Understanding definitions, outgoing connections and channels

Everything in Zato revolves around re-usability and hot-reconfiguration - each individual piece of configuration can be changed on the fly, while servers are running, without restarts.

Note that the concepts below are presented in the context of WebSphere MQ but they apply to other connection types in Zato too.

  • Definitions - encapsulate common details that apply to other parts of configuration, e.g. a connection definition may contain remote host and port
  • Outgoing connections - objects through which data is sent to remote resources, such as MQ queues
  • Channels - objects through which data can be received, for instance, from MQ queues

It is usually most convenient to configure environments during development using web-admin GUI but afterwards this can be automated with enmasse, API or command-line interface.

Once configuration is defined, it can be used from Zato services which in turn represent APIs that Zato clients invoke. Then, external applications, such as a Django or Flask, will connect using HTTP to a Zato service which will on their behalf send messages to MQ queues.

Let's use web-admin to define all the Zato objects required for MQ integrations. (Hint: web-admin by default runs on http://localhost:8183)

Definition

  • Go to Connections -> Definitions -> WebSphere MQ
  • Fill out the form and click OK
  • Observe the 'Use JMS' checkbox - more about it later on

Screenshots

  • Note that a password is by default set to an unusable one (a random UUID4) so once a definition is created, click on Change password to set it to a required one

Screenshots

  • Click Ping to confirm that connections to the remote queue manager can be established

Screenshots

Outgoing connection

  • Go to Connections -> Outgoing -> WebSphere MQ
  • Fill out the form - the connection's name is just a descriptive label
  • Note that you do not specify a queue name here - this is because a single connection can be used with as many queues as needed

Screenshots

  • You can now send a test MQ message directly from web-admin after click Send a message

Screenshots

Screenshots

API services

  • Having carried out the steps above, you can now send messages to queue managers from web-admin, which is a great way to confirm MQ-level connectivity but the crucial point of using Zato is to offer API services to client applications so let's create two services now, one for sending messages to MQ and one that will receive them.
# -*- coding: utf-8 -*-

from __future__ import absolute_import, division, print_function, unicode_literals

# Zato
from zato.server.service import Service

class MQSender(Service):
    """ Sends all incoming messages as they are straight to a remote MQ queue.
    """
    def handle(self):

        # This single line suffices
        self.out.wmq.send(self.request.raw_request, 'customer.updates', 'CUSTOMER.1')
  • In practice, a service such as the one above could perform transformation on incoming messages or read its destination queue names from configuration files but it serves to illustrate the point that literally 1 line of code is needed to send MQ messages

  • Let's create a channel service now - one that will act as a callback invoked for each message consumed off a queue:

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

from __future__ import absolute_import, division, print_function, unicode_literals

# Zato
from zato.server.service import Service

class MQReceiver(Service):
    """ Invoked for each message taken from a remote MQ queue
    """
    def handle(self):
        self.logger.info(self.request.raw_request)

But wait - if this is the service that is a callback one then how does it know which queue to get messages from?

That is the key point of Zato architecture - services do not need to know it and unless you really need it, they won't ever access this information.

Such configuration details are configured externally (for instance, in web-admin) and a service is just a black box that receives some input, operates on it and produces output.

In fact, the very same service could be mounted not only on WebSphere MQ ones but also on REST or AMQP channels.

Without further ado, let's create a channel in that case, but since this is an article about MQ, only this connection type will be shown even if the same principle applies to other channel types.

Channel

  • Go to Connections -> Channels -> WebSphere MQ
  • Fill out the form and click OK
  • Data format may be JSON, XML or blank if no automatic de-serialization is required

Screenshots

After clicking OK a lightweight background task will start to listen for messages pertaining to a given queue and upon receiving any, the service configured for channel will be invoked.

You can start as many channels as there are queues to consume messages from, that is, each channel = one input queue and each channel may declare a different service.

JMS Java integration

In many MQ environments the majority of applications will be based on Java JMS and Zato implements the underlying wire-level MQ JMS protocol to let services integrate with such systems without any effort from a Python programmer's perspective.

When creating connection definitions, merely check Use JMS and everything will be taken care of under the hood - all the necessary wire headers will be added or removed when it needs to be done.

Screenshots

No restarts required

It's worth to emphasize again that at no point are server restarts required to reconfigure connection details.

No matter how many definitions, outgoing connections, channels there are, and no matter of what kind they are (MQ or not), changing any of them will only update that very one across the whole cluster of Zato servers without interrupting other API services running concurrently.

Configuration wrap-up

  • MQ connection definitions are re-used across outgoing connections and channels
  • Outgoing connections are used by services to send messages to queues
  • Data from queues is read through channels that invoke user-defined services
  • Everything is reconfigurable on the fly

Let's now check how to add a REST channel for the MQSender service thus letting Django and Flask push MQ messages.

Django and Flask integration

  • Any Zato-based API service can be mounted on a channel
  • For Django and Flask, it is most convenient to mount one's services on REST channels and invoke them using the zato-client from PyPI
  • zato-client is a set of convenience clients that lets any Python application, including ones based on Django or Flask, to invoke Zato services in just a few steps
  • There is a dedicated chapter in documentation about Django and Flask, including a sample integration scenario
  • It's recommended to go through the chapter step-by-step - since all Zato configuration objects share the same principles, the whole of its information applies to any sort of technology that Django or Flask may need to integrate with, including WebSphere MQ
  • After completing that chapter, to push messages to MQ, you will only need to:
    • Create a security definition for a new REST channel for Django or Flask
    • Create the REST channel itself
    • Assign a service to it (e.g. MQSender)
    • Use a Python client from zato-client to invoke that channel from Django or Flask
    • And that is it - no MQ programming is needed to send messages to MQ queues from any Python application :-)

Summary

  • Zato lets Python programmers integrate with WebSphere MQ with little to no effort
  • Built-in support for JMS lets one integrate with existing Java applications in a transparent manner
  • Built-in Python clients offer trivial access to Zato-based API services from other Python applications, including Django or Flask

Where to next? Start off with the tutorial, then consult the documentation, there is a lot of information for all types of API and integration projects, and have a look at support options in case you need absolutely any sort of assistance!