Enterprise Service Bus was meant to be the saviour of enterprise integration. But I feel that the current ESB world has taken the turn that large EJB containers have taken. Don’t get me wrong, there are some valid applications of EJB, but in the recent years, we have seen a large move away from EJB towards light-weight architectures, such as the Spring Framework. Now, ESB attempts to solve all enterprise integration problems, just like EJB attempts to solve enterprise application development. Because of this, the current ESB solutions have spread themselves too thin; when you see an ESB solution, it will most likely include transaction manager, rule engine, single sign-on and load-balancing support.

What we wanted?

We wanted to make our software work just like we do. In other words, we place an object on the bus and say what we wanted to be done with it. We dreamt of being able to wite

// in Java
final Order order = getOrder();
send(order, toFulfilment);

The send method would place the order object on the bus with the indication of where we want the object to go (fulfilment). We thought that we would create complex routing rules on the ESB; rules that would perform the business process. We naturally wanted failure recovery and management interfaces.

What we got

Well, we got what we wanted. Today’s ESB solutions are complex pieces of software that are difficult to configure, deploy and test. But they do precisely what we want! The problem is that when we choose to use ESB, we are willingly committing to implement a very complex system. The implementation will most likely take tens of man-years. During all this development work, we hope that the requirements will not change.

Change happens

This is usually where the problems arise. I know of no project in the scale of tens of man-years that requires no change during the development.

What next?

I am not going to beat around the bush, I think we should all rethink our enterprise integration solutions. If they include ESB, we should ask ourselves what was the reason for ESB in the first place. If the reason was purely to simplify communication between services, we must ask ourselves whether the services are ready. If not (and if the implementation of the services is going to take many more months), we should quickly move away from ESB and start writing software that performs the business need now.
So, our recommendation is to start writing agile software, with smaller units, favour deployment of complete applications rather than focusing on some grand design that will most likely suffer too much change in its lifetime.

What about integration?

So, we have smaller applications, but what about allowing them to talk to each other? Let’s take a step back. Why not use the largest communication network in existence? Why not rely on the Internet? If each of the smaller applications can directly process structured textual data (read XML), then all our distinct and separate applications can integrate with each other using simple HTTP(s) protocol.

Conclusion

In summary, we advocate smaller applications that can directly use the HTTP protocol. With anecdotal evidence suggesting that even your fridge will soon be on the internet, then if your grocery shop’s ordering service can readily be made available on the Internet, then there is no reason why your fridge should not be able to order your favourite organic purple cauliflower automatically when you run out!