More on ESBs

One of my for more popular postings has been "ESB or not ESB". I suspect the only reason was the word "ESB" appeared twice in the title and the Google search engine gave it a high priority when people searched on this acronym.

This was cited in an Italian language blog posting by Andrea Gumina which also cited a good posting by Steve Vinoski . Steve's posting is perceptive and has many good comments on it.

Steve is commenting on an earlier posting by Patrick Logan. Patrick describes the concept of an ESB as a "mangy mutt" because it is a " grab-bag of mechanisms that form no coherent whole". I agree with this assessment but feel that the ESB concept will mature. The ESB may be a mechanism to provide some plumbing. Many organisations SOA efforts need that plumbing because the system delivery has a number of leaks.

My organization was galvanized into inaction and has not yet bought an ESB. However we are fairly typical I would guess because we want the vendors products to do 'everything' for us. IT is not our core business and we do not want to worry about location or services, security, integration, messaging etc. We want our developers to focus on business logic and data models specific to the business. If the vendor came up with an ESB that really did remove the need to spend time on software infrastructure (and did not charge a fortune for it), then we would be interested.

I would also like our developers to settle on a "one best way" to develop applications rather than the organization investing in training and support for a multitude of programming languages and technologies. Steve advocates using the right language for the job and not being confined to one language. This is a noble cause but it is hard work learning another language and becoming proficient in it. Most developers I know have the one language that they would prefer to write everything in, just as most people I know don't communicate in anything but English. If I weren't so lazy I'd teach myself Italian so I could find out what that Italian site was saying about my blog posting. Similarly I think many developers can't realistically be expected to be truly multilingual when it comes to programming languages.

The discussion of Steve's posting gets a hijacked by the REST vs Web Services debate. This is unfortunate because the ESB discussion should be a separate issue. Using SOAP and Web Services does not require an ESB. ESBs have been conceived to assist with REST such as open source ESBs WSO2 and Mule. The more popular arrangements seem to be that Web Services use an ESB and REST does not, but this need not be the case. The REST vs Web Services argument is taken up elsewhere and in some people's minds have already been settled. Ronald Schmelzer of Zapthink states:

In many ways, however, the debate about Web services and REST is as pointless as arguing whether a hammer or a screwdriver is a better tool.

In the discussion in Steve Vinoski's posting I found myself agreeing with Jonas Ekstrom and Paul H that the ESB market is not yet mature. Jonas put this eloquently:

Religions give easy answers, but there are no easy answers. Natural selection will strike again and again until we have reached the perfect SOA.

Paul H puts a similar slant on this:

I look forward to the day when we’re in a similar stage of maturity … and there exists generally accepted, standardized, manageable, and self-federating mediation technologies … until then, we’ll all have to suffer through endless arguments along the lines of 'should I use a BEA ESB or a Sonic ESB? is an ESB really necessary, or can I get away with REST + Dynamic Languages?'

I will continue to wait until the need for an ESB (or some part of one) becomes self-evident. While an implementation of SOA can function without and ESB there seems little point in making the investment.