ESB or not ESB?

I work for an organisation that is pretty well fixed on achieving a goal of an SOA but we are still wondering how to get there. The worst people to ask are software vendors, because the answer will always be to buy more software. This stuff costs big time though.

For the cost it took to set up our application servers I could have bought two comfortable suburban homes and then we pay the software maintenance which I have to invest in at the cost of having a couple of staff. It is not as if I can do without the staff though. I now have to recruit someone to administer the application server and find developers with the skills in this particular applications server. So when the software vendor tells me that all I need to is the pay the cost of another suburban house and sacrifice funds for another staff member to buy an ESB I need to be pretty clear that this will provide some benefit.

There is some disagreement about what an ESB is or what benefit it brings. Mark Richards looks at some of the definitions of ESB in his presentation for the NFJS conference (video clip at http://www.infoq.com/presentations/Enterprise-Service-Bus). He then defines the ESB in terms of the capabilities it might bring these are listed as:

1. Routing
2. Message Transformation
3. Message Enhancement
4. Protocol Transformation
5. Service Mapping
6. Message Processing
7. Process Choreography
8. Services Orchestration
9. Transaction Management
10. Security

If software contains about five or more of these capabilities then it is an ESB. This would normally include first three capabilities. Together Mark Richards refers to these as "mediation".

This list is handy because it allows you to look at your needs and determine whether you should purchase such a product with these capabilities. You can determine whether these capabilities are available in your application services already, whether you need to acquire a niche product to address a capability or whether you can handle some of this capability in your own code.

This list is also useful to determine what you are not getting in a particular product offering. One consultancy firm demonstrated to me a great way of addressing the routing problem in application code and claimed I did not need an ESB because of this. It was certainly useful but it will not help if I need the other nine capabilities.

There is certainly some difference of opinion on whether you need and ESB. Vendors will say you need to have an ESB to do SOA. Sandy Carter of IBM in her web presentation (http://www.infoq.com/interviews/sandy-carter-soa) says that an ESB is a a "crucial part of an SOA" and a "spinal chord of your business".

On the other hand a presentation by Jim Webber of Thoughtworks is critical of the ESB approach and believes it works against a good SOA (http://jim.webber.name/downloads/presentations/2006-10-EJA-Guerrilla-SOA.ppt). Jim claims that ESB adds a proprietary middleware to you SOA which will lock you an your software in to a particular vendor. He goes onto to say that "spaghetti" in SOA is inevitable and one of the strengths of SOA is that it copes with this. ESB on the other hand can make spaghetti worse.

One of the best quotes I found was in article by Colleen Frye discussing ESBs with Jason Bloomberg and others:

This bandwagon's a bus and ... vendors positioning in the SOA market have jumped on it over the last few years.

I don't believe my organisation is mature enough in its SOA progress to consider and ESB. We have to develop a critical mass of services before we should look at investing in more glue (as Jim Webber describes it) to organise and bring these services together.

References:

Mark Richards http://www.infoq.com/presentations/Enterprise-Service-Bus
I liked marks insight in that SOA "Presents IT Services as Business Services".
Also he mentioned a couple of open source ESBs
Mule: http://mule.codehause.org/
ServiceMix: http://servicemix.org/ (JBI = JSR-208 compatible).

Sandy Carter: http://www.infoq.com/interviews/sandy-carter-soa
Some good parts of this talk excuse her from being a vendor and almost excuse her from using the word "leverage" too much.
"ESB as a pattern of SOA."
A quote from Steve Mills "SOA will be with us for decades"
"I think that BPM and SOA are two sides of the same coin. I don't think you can do BPM without leveraging SOA."

Jim Webber: http://jim.webber.name/downloads/presentations/2006-10-EJA-Guerrilla-SOA.ppt
This is a powerpoint slide presentation. He is also promoting his book that looks interesting.

Colleen Frye: ESB Market Report, http://searchsoa.techtarget.com/originalContent/0,289142,sid26_gci1226497,00.html