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 the one is in C++, AMQP is in Python and JMS is, unsurprisingly, in Java), like in the diagram below.

This is all the code that is needed. Two lines in addition to an import and class/method definition.

from zato.server.service import Service

class MyService(Service):
    def handle(self):
        
        # JMS WebSphere MQ
        self.outgoing.jms_wmq.conn.send(self.request.payload, 'JMS MQ app', 'QUEUE.1')

        # AMQP
        self.outgoing.amqp.conn.send(self.request.payload, 'AMQP app', 'EXCH.1', '/')

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. In other words - for 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 folks seeking repeatable builds) manage objects en masse using a JSON config.

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

• a ZeroMQ channel for incomming messages
• an outgoing AMQP connection
• an outgoing JMS WebSphere MQ connection

After filling out the forms like below a service can be hot-deployed and is ready to use.

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?

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.

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.  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.