Middleware Matters

Steve Maine's assessment of centralized ESBs, inspired by what he dubbed "Rich Turner's 'little rant against ESBs'," is right on the money. Radovan also considers ESBs harmful.

Unfortunately the term "ESB" is not at all clear. For some, it implies the centralized entity that Steve and others are correctly questioning. Vendors pushing such centralized ESBs are essentially telling you

"Hey, I can solve all of your integration needs. All you need to do is make everything in your enterprise tie into my centralized ESB. Just make sure everything you want to hang off my bus can either speak its protocols and handle its data formats, or can be adapted to do so. Direct all your messages and data through this centralized bus, and all your integration woes will magically go away."

It's just EAI all over again.

"But Steve," you might say, "isn't your Artix product an ESB?" Yes, it's classified that way, but it's about as far from a centralized ESB as you can get. Frankly, there's nothing else like it, which is why we call it an extensible ESB.

One of the best ways to use Artix is to embed it directly into an endpoint, thus allowing that endpoint application to speak multiple protocols and data formats. That's how you move integration to the edges, thus achieving the decentralized integration dream of WS-* without buying into the flawed assumption that SOAP/HTTP can solve all integration needs. It can also be used as a lightweight switch that can do protocol or format switching. Its extensibility means that making Artix handle a different protocol or format is very straightforward. But Artix does all that and more without requiring centralization and without requiring that it becomes the main player in your system. It just kind of "flows around" the systems you're trying to integrate, letting them function exactly as designed while opening them up to interworking cleanly with other disparate systems.

IONA is basically the Switzerland of middleware and integration. Other players essentially feed you quotes like the hypothetical one above. We're the ones who come in after you've fallen for their empty promises, and we get your integration projects working the way the others wish they could. We deliver fast, efficient, flexible, and cost-effective integration, allowing you to protect your investments in your existing systems by maintaining their existing protocols and formats while opening them up to other protocols and formats. This makes them even easier to integrate going forward. And we do all this without requiring EAI-like centralization, and without assuming that SOAP/HTTP is a universal answer.

Just a reminder about the IEEE Internet Computing (IC) call for papers on asynchronous middleware and services that Doug Lea, Werner Vogels, and I are running. The due date is June 1.

In general, IC is always looking for good articles on the general topic of, well, internet computing. The current issue, for example, contains articles on

• replication for content management environments
• e-services infrastructure for power distribution
• moving from business to technology with service-based processes
• secure electronic data exchange over the internet
• how BPEL and SOA are changing web services development
• multiprotocol label switching and IP

In terms of journal citation reports, IC has one of the highest citation impact factors among all computer science and software engineering journals and magazines. In the 2003 citation report, for example, IC was ranked second in impact factor. In contrast, IEEE Computer was 13th, Communications of the ACM was ranked 14th, and IEEE Software was ranked 20th. What this means is that if you publish in IC, your article is very likely to be noticed and subsequently cited in other important works. Way more people will read your article in IC than if it's published in any conference proceedings. Also, the IC editorial staff is amazingly good, so your published article will be polished and will read extremely well.

See the author guidelines for details on how to submit your articles, and feel free to email me if you have any questions.

Last week while traveling I had time to read Greg Wilson's new book, Data Crunching: Solve Everyday Problems using Java, Python, and more. I think it's nothing short of stellar.

The book says it targets the beginning to intermediate programmer, but I think even seasoned developers will learn from this book, especially those who grew up on systems other than UNIX. Users of UNIX are of course familiar with the collection of classic programs it provides, such as grep, cat, find, sed, and awk, that can quickly be piped together to create incredibly powerful data processing facilities. While this is not a UNIX book, it does describe and promote the same mindset that resulted in those UNIX capabiltiies. That mindset, which has always been useful, is more important than ever given today's focus on software agility. Greg keeps that theme front and center throughout his book.

The book is full of thoughtful, practical examples. Many are written in Python, and some are in Java. There's some XML, some SQL, and even some C as well. All tastefully convey the power of simplicity as well as the utility of having agile tools that can be quickly assembled into larger solutions.

Greg's writing is exceptional. It's minimal and tight, yet it never fails to fully and clearly explain precisely what needs explaining. The fact that it was written so well meant that I tore through the roughly 200 pages in no time, and enjoyed every page. I think even Brian Kernighan would be pretty impressed.

If you have friends or family members who are about to graduate from college and enter the working world as software developers, or if you have folks on your team who have been working as developers for just a few years, get each of them a copy of this book. The fundamentals it will give them will serve them well throughout their careers. And while you're at it, get yourself a copy too, so you can remind yourself how fun it is to be able to quickly put together useful solutions to everyday problems -- when you have the right tools and the right mindset, of course.