ESB is an architectural style, a software product, or a group of software products?

In general terms a ESB is an arquitecture where applications communicate using messages over a network. Those messages could use several supports: from the heavy SOAP specification to the REST lightweight principle, even RPC and IIOP are possible supports for messaging in an ESB.

So far... so good.

The problem comes when we try to put together several concepts: ESB is related with SOA and BPM, but much more related with specific middleware from different vendors.

The first thing a ESB arquitect should have in mind is that as of 2010 there is no global standard for ESB, this means that if Oracle releases a product called ESBOracle (for example) they have no strict compromise on what functionality to provide.

Conclusions about ESB

First conclusion is: You can implement an ESB using mainly free software putting pieces together (axis, tomcat, jbpm, jboss, connectors for legacy systems,…) or buy an ESB enabled product from your vendor of choice (IBM, Oracle, ...).

Second conclusion is: If you decide to acquire a commercial ESB product, you will find big differences between those vendors.

Third conclusion: Be sure to ask your vendor what other licenses you will have to acquire in order to implement advanced features on your ESB like Single Sign On, Advanced reporting, connectors with legacy systems and so on.

Raúl Lapeira Herrero, ConsultoriaJava.com Java expert