More on the ESB

Cross-referencing fuzzy's cross reference to my cross reference -- we may create a vortex that implodes on itself. But anyway, in my URI post I said the ESB subject per se is a topic for another post, which turns out to be this one. Mike's hit my main impression with ESBs over the years. I wonder what Ross Mason or other ESB advocates have to say about my experience. First Mike's note on his recent exploration with Mule...

I have more learning on Mule to do. I was a little overwhelmed in working with it yesterday (lots of jar files, lots of XML config, examples that didn't help with what I wanted to do, docs that didn't answer my questions - typical newbie stuff). I did succeed in getting it configured to do what I wanted it to do after going down a number of rat holes & now have something to build on this week.

In my experience with various middleware tools (some of which predate the term "ESB" but all of which tend now to place themselves somewhere in the ESB territory) these turn out to be excercises in installation and configuiration by dialog box and/or by XML config file. I dislike both.

ESBs seem to me to be lumps of things useful for integration, but do not form any kind of coherent shape out of the individual lumps. If you need XML transformation, email, HTTP, file drop, etc. then why not just use the simplest dang library for the one or two of those needed for any given situation? If you need more than two of those in a single situation, then that's a symptom rather than a need.

Look at the list of "adapters" or whatever an ESB advertises. In each case, one can locate a fairly simple library, probably already on their machines, that implement that one feature well enough. ESB's say they can "wire" all that stuff together.

Such wiring usually appears to be more complicated than the original problem. They just have never appealed to me. But never say never, I guess.

I am from Missouri when it comes to ESBs. Show me. I'll give you the benefit of the doubt, if you can just show me, why it makes more sense to use such an all-in-one, configuration nightmare. :-/

I may be biased already, but I've not seen where these things pay off over a little code, some tests, and a couple simple libraries that do exactly what's needed. Assuming your experience differs from mine, please show me.

Update from comments: Yuen-Chi Lian's comment to this post responds to Dan Creswell's. First, Dan Creswell's... (Dan's connected to Jini/Javaspaces, in particular to the Blitz Javaspace implementation and some significant uses of J/J in production situations)

Of course the more point-to-point type integration solutions can also get out of hand but as you say it's simpler, more contained and easier to get to grips with.....

And now Yuen-Chi Lian's response to that... (he's connected to Mule, says google, so presumably has some good case studies in applying ESBs)

That's the point. And when it comes to a system with more and more enterprise applications connecting to it -- different vendors, different language, etc. You need a centralized mechanism, a universal connectivity, a message bus, an ESB. To keep messy things at a manageable level.

Also, programming in the large is simply a different (not better) development model to follow. But there are still fundamental concepts as its core which we have learned throughout the years in "traditional" development -- "high abstraction" and "loose-coupling".

I've got some experience with the Tibco RV bus, JMS, and Javaspaces. I understand how to use pub/sub, queues generally, and tuple spaces to reduce the NxM connectivity problem. I understand how to define "canonical messages" so that the messages on the bus are not just propagating the internal implementation details of the participants. And so this to me seems like appropriate "high abstraction" and "loose coupling".

I've never been a fan of the big tools sets that have grown up around tools like RV. All the point-and-click, configure the xml, "wire-up-the-bubbles" tools just don't do much for me. Writing a little bit of code to read/write messages on a bus seems just fine.

And so to me "message bus" and "enterprise service bus" seem to be two different animals. One is a simple animal (basic bus capabilities), the other a mangy mutt (ESB). The ESB is like a grab-bag of mechanisms that form no coherent whole. And they tend to have WS-Deathstar infused in their being, lacking simplicity and simply defined terms.

So give me a bus, give me a tuple space, give me simple mechanisms like that. But xml config'ing a zillion jar files to "mix-n-match" all the ESB thingies -- who really does that? Successfully? And what does the *architecture* of that look like? I remain unconvinced and nearly uninterested.

Today I am drawn to the simple web approach as opposed to the simple bus approach. The web, via atompub and the atom format, seems to incorporate enough "bus-like" behavior to meet many needs. Where it falls short then simple bus mechanisms can be employed as I'd turn to before. But I'd look to do that *without* hurting the web aspects. All that NxM connectivity stuff should have a web woven around the bits. They can all use the web as the simple, unifying architecture.

ESBs do not form an architecture in and of themselves. They are mechanisms that can provide some plumbing. I'm not sure at all that they add much to the simple plumbing mechanisms I've had success with already. I have trouble understanding how to approach them, and nothing I have seen to date has eased that for me.

So really good case studies would be appreciated. Give me your best shot, and I'll try to consider it.