La web de, la web de los auténticos expertos en Java

Ir a inicio


Know-How Java

Know-How de Negocio



Servicios de consultoria

Análisis y Diseño

Aportación de Know-How

Arquitectura Java EE

Auditoria de Proyectos

Formación experta

Gestión de proyectos

Preparación de equipos

Refactoring de sistemas

Reingeniería de proyectos

Selección de personal articles

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

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, Java expert