Es básicamente una forma conceptual de diseñar un sistema: las empresas de software intentan venderle más pegando la etiqueta 'ESB' y a los gerentes les gusta porque un ESB se ve bien desde un 'nivel superior'.
Un ESB es básicamente un MOM (middleware orientado a mensajes) con un modelo de datos agregado y una gestión de definición de estructura. Tiene una definición de datos común para todas las aplicaciones y adaptadores en ese bus (podría ser XML con un XSD compartido). Todo lo que se conecte DEBE enviar su información que se adhiera a esta definición de datos. El ESB admite la carga, el intercambio y el control de versiones de esta definición de datos común. Al conectar un nuevo componente a un ESB, puede esperar más 'compatibilidad' de fábrica que cuando lo conecta a un MOM. Cada componente de ese bus se trata conceptualmente como un "recurso", por lo que se introduce una abstracción adicional para desacoplar el emisor del receptor.
Ejemplo: digamos que desea conectar la aplicación A con la aplicación B en un middleware estándar orientado a mensajes, tomemos JMS. Hablas con tus colegas que trabajan en la aplicación B, acuerdas un tema, tipo de mensaje y campos y lo envías (pseudocódigo): sendJms ("TRADE.MSFT", {MapMessage trader = "pete" price = 101.4 vol = 100})
Si hace lo mismo en una arquitectura orientada a servicios, necesita
- instalar software adicional
- aprender muchos conceptos nuevos
- defina su nuevo componente Java en la interfaz gráfica de usuario de administración de ESB
- implementar algunas interfaces que son controladas por el ESB
- sendJms (getDestination (), {MapMessage trader = "pete" price = 101.4 vol = 100}) - tenga en cuenta que el destino se inyecta desde el ESB
La primera vez probablemente sea un poco doloroso, pero supongo que puede acostumbrarse, al igual que puede acostumbrarse a los EJB ;-)
Se podría decir que un sistema MOM está 'sin tipo' (estructura dinámica) mientras que un ESB está 'escrito' (estructura estática). Las ventajas y desventajas de la mensajería en bruto frente a la ESB son similares a otras opciones no tipificadas / tipificadas:
- DESCANSO vs.JABÓN
- XML no validado frente a XML validado con un XSD
- Groovy contra Java
- lenguaje interpretado versus lenguaje compilado
Para proyectos más pequeños, es bueno eliminar la funcionalidad rápidamente (p. Ej., Código Groovy), pero para proyectos más grandes es bueno tener un depurador (p. Ej. Java), ser advertido con anticipación cuando las cosas se rompen y tener un estándar para las personas antes de comprometerse con el proyecto.
Entonces, si su proyecto sufre porque demasiadas personas rompen el sistema al verificar cambios no validados, avance hacia una estructura más (ESB en lugar de MOM). Si sus proyectos adolecen de no hacer suficientes cosas a tiempo, elija la solución más simple y sin tipo. Si son ambos, consiga un consultor (es broma ;-)