ESB = Enterprise Service Bullocks

As you can see from the title I’m not a big fan of Enterprises Services Buses.

I’m not the only one, Jim Webber motivated already in these nice slides why, I’ll just add my impressions, as a newbie.

I’ve tried using serviceMix and I had a quick look to some other not OS vendors.

The first weird thing is that everybody is writing an ESB, you got so many choices, even the Apache foundation has two ESBs: ServiceMix and Synapse, must be an easy thing to write is so many companies are writing their own version: don’t assume knowing and writing code for one will work elsewhere!

The second very bad thing is maintenance. I had to change a little some JBI components written a couple of months ago, it has been painful, ServiceMix is all about XML configuration but you have no clue on what’s talking with who, which service is connected to what and why, you change a name and bang, nothing works anymore. Aweful.

You might buy one of those cool ESB (Oracle, Tibco, the list is long) offering a “nice UI” to drag and drop components, well I’m sceptical, never been a big fan of this type of tools (vendors too, to be honest).

Testability. Assuming that you care about testing how do you want to test this stuff? Writing long running integration tests?

I tried a little and I ended up pinging ServiceMix to understand if it’s up or not (it akes honestly ages to came up) and do some clever wait on JMS queues for messages in order to understand if the bus still works but hey… That’s not cool at all. It’s slow and breakes very easily.

Instead of an ESB you might consider the architecture proposed by Jim on the slides mentioned above, if that’s not enough (maybe you’ve got some syncronized JMS queues) you might try to have a look to Scala, I think (and I’ll try to write something more about it) you can write an ESB (only what YOU need, no XML, no bullshit) in a day or so with a couple of Scala Actors.

What’s really agile?

Today we ended a scrum sprint, two weeks long.

In two weeks a team of five developers managed to setup a project using state of art tecnologies such as DRW, ActiveMQ, ServiceMix, Hibernate, Spring, Atomikos XA Transactions.

Not only we have a use case up and running and we are able to show case it to the customer.

Now,  few choices in my opinion made this “more agile”.

  • The usage of Maven, we have probably 50 dependencies, I can’t imagine how to handle this with ant.

  • The usage of Hudson as CI tool, simple UI, no need to read the manual

  • The usage of Spring, in a couple of hours we had all we need (DAOs, JMS senders and receivers especially)

  • The usage of Hibernate3 with annotations, can’t be faster to write down your domain

  • The usage of Jetty to have a fast feedback locally

  • Well, ovious maybe but worth mention, we wrote tests first, we used Junit4.5

  • Flexible pair programming, we paired only when in trouble or when we felt the solution was mature enough to be showcased and shared in the team

  • Focused work, one developer on the Web UI, one on the deployment, one on the ServiceMix/ActiveMQ, one on the Transactions + Design of the system

I call this agile, hard work and good fun.