Enterprise Integration Zone is brought to you in partnership with:

Dariusz Suchojad has 12 years’ experience in enterprise architecture and software engineering with 8 years in EAI/ESB/SOA/BPM/SSO in telecommunications and banking. He feels equally well in dissecting proprietary protocols, developing systems of systems, talking businesses over and anything in between. Having spent far too many nights on putting out fires caused by the poor quality of solutions he had to use daily, he quit his job and spent almost 2 years on creating Zato, which is a Python-based ESB for SOA, cloud integrations and backend servers. Dariusz has posted 5 posts at DZone. You can read more from them at their website. View Full User Profile

Integrate ZeroMQ, AMQP, JMS WebSphere MQ and more in 2 lines of Python code with Zato

08.08.2013
| 3223 views |
  • submit to reddit

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.

Sample integration using Zato - ZeroMQ, AMQP and JMS WebSphere MQ

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:

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.

Published at DZone with permission of its author, Dariusz Suchojad. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)