Enterprise service bus (ESB for short), is an enterprise integration pattern you can use to interconnect and organize your services in any non-trivially sized environment. It can be particularly helpful when dealing with legacy systems with limited possibilities to develop new APIs and services.
Zato developers have done a very good job at explaining what SOA and ESBs are keeping buzzwords to a minimum. This is by far the best introduction to the topic I've ever read, I recommend checking it out.
At QDQ media, we're currently redesigning the way we interconnect some of our systems and we had a look at Zato to understand if it was a good fit for our architecture. The goal was to use the ESB to shield the complexity and ugliness of certain legacy systems from the applications we're writing. Basically, we don't want to see a web application interacting with some legacy system making SOAP calls and doctoring the XML generated by SOAP libraries to make it comply with the (nonstandard) implementation of the remote system.
Let me state that Zato is a high-quality piece of software. The documentation reminds me of the quality of the django documentation, which is great. Developers took their time to write a tutorial and a quickstart procedure which lets you take a dive into this ESB world without any uncertainty.
I also got in touch with Zato developers and they were really friendly and responsive. One of the things I was afraid of was the little community and hype around this project (compared to other open source ESBs like Mule for instance). But seeing the developers so responsive and committed goes a long way towards giving credibility to the project.
Eventually we decided not to use Zato and we started writing our own wrappers around these legacy systems. Why? Because we feared that centralizing things within the ESB would create what's called a "Spaghetti-meatball" antipattern. Suddenly you have all the complexity and ugliness (spaghetti) concentrated in one place (the meatball) that no one really enjoys touching and working with.
Another argument that convinced us to write our own wrappers around these legacy systems is that we were sure that eventually we'd have to touch the internals of Zato to do certain things, and we'd probably be just faster by writing these wrappers from scratch instead of studying the internals of Zato, which is a complex piece of software.
The bottom line is that probably when you want to sanitize the
communication with a large number of legacy systems, ESB looks like a
great idea and it probably makes sense to invest time in understanding
the internals of Zato and committing to it. In our case, we had only
3-4 of these systems, and writing ad-hoc
HTTP/JSON wrapper APIs felt