"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.

Search This Blog

Loading...

Sunday, September 30, 2007

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.

4 comments:

PetrolHead said...

There are several aspects of ESB's I'm not comfortable with:

(1) Centralized command and control via those nasty configuration files.

(2) The connect everything to everything via some centralized mechanism. Messy, messy, messy - what's going where, how do you trace things around etc

(3) Follow on from (2) - yes these connected things can be remote but they're all sharing a single "backplane" which seems like it could lead to resilience disasters.

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

Yuen-Chi Lian said...

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

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

Nick Malik said...

Fascinating post. There are a lot of different things out there that share a common label of "ESB." Some are more 'centralized' than others.

The purist in me says that "ESB" as a concept is worth doing, but that ESB as a single point of failure is an example of the bad implementation of a good idea.

That said, most ESB's that exist today do not exhibit a resiliance problem, because, when architected well, there is no single point of failure.

And to the concerns of 'petrolhead,' If an ESB connects 'everything to everything' in a messy manner, what do you call it when everything is connected to everything but NONE OF IT IS VISIBLE? Is that less messy?

Face it, an ESB attempts to solve a problem. Perhaps the attempt has weaknesses, but the problem remains. If you are truly dedicated to building fewer applications, each contributing to a more operationally efficient enterprise, you need to be able to track the transactions that make up a business process, end to end, across the many cooperating systems in your infrastructure.

That requires a system that is aware of the processes and transactions and is able to not only bring that information together, but act on failures. That system is necessary and important.

I don't care what label you place on it.

Patrick Logan said...

Nick -- you are an enterprise architect for Microsoft. Can you describe some successful ESB implementations you've been a part of, or aware of? How long they've been around, something about their scope?

Blog Archive

About Me

Portland, Oregon, United States
I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer. Contact me at my gee mail account, username patrickdlogan.