significado - ¿Qué es un ESB y para qué sirve?
openesb implementación en java. (7)
En un trabajo anterior, se habló mucho sobre "Enterprise Service Bus" (ESB). Leí partes de un libro conceptual al respecto, pero nunca entendí realmente cómo lo implementaría / integraría en términos concretos. Estoy familiarizado con SOA / colas / servicios de directorio / etc. pero no entiendo qué es exactamente un ESB.
¿Es algo concreto (service / server / broker / etc.) Que simplemente enlaza todas sus aplicaciones de diferentes maneras, o es más simplemente una forma conceptual de diseñar sistemas?
Cualquier explicación o enlace a buenos ejemplos sería muy apreciada. Gracias.
Básicamente es una forma conceptual de diseñar un sistema: las compañías de software intentan venderte más manteniendo la pegatina ''ESB'' ya 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 estructuras. 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 conecta DEBE enviar su información que se adhiere a esta definición de datos. El ESB admite cargar, compartir y versionar esta definición de datos común. Cuando se conecta un nuevo componente a un ESB, se puede esperar una mayor ''compatibilidad'' fuera de la caja que cuando se conecta a una MOM. Cada componente de ese bus se trata conceptualmente como un ''recurso'', por lo que se introduce una abstracción adicional para desacoplar al emisor del receptor.
Ejemplo: supongamos que quiere conectar la aplicación A con la aplicación B en un middleware orientado a mensajes estándar, tomemos JMS. Hable con sus colegas que trabajan en la aplicación B, acuerden un tema, tipo de mensaje y campos y envíelos (pseudo código): sendJms ("TRADE.MSFT", {MapMessage trader = "pete" price = 101.4 vol = 100})
Si haces lo mismo en una arquitectura orientada a servicios, necesitas
- instalar software adicional
- aprender muchos conceptos nuevos
- defina su nuevo componente Java en la GUI de administración del ESB
- implementar algunas interfaces que están 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 es probablemente un poco doloroso, pero supongo que te puedes acostumbrar, al igual que puedes acostumbrarte a EJB ;-)
Se podría decir que un sistema MOM está ''sin tipo'' (estructura dinámica) mientras que un ESB está ''tipado'' (estructura estática). Las compensaciones de mensajería en bruto frente a ESB son similares a otras opciones sin tipo / tipeo:
- RESTO contra SOAP
- XML no validado vs. XML validado con un XSD
- Groovy vs. Java
- lenguaje interpretado vs. lenguaje compilado
Para proyectos más pequeños es bueno eliminar la funcionalidad rápidamente (por ejemplo, código Groovy), pero para proyectos más grandes es bueno tener un depurador (por ejemplo, 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 de demasiadas personas rompiendo el sistema al registrar cambios no validados, avance hacia una mayor estructura (ESB en lugar de MOM). Si sus proyectos sufren por no hacer suficientes cosas a tiempo, elija la solución más simple y sin tipo. Si se trata de ambas cosas, consiga un asesor (es una broma ;-)
Bueno, eso depende de a quién le pregunte ... Muchos dirían que es una pieza de "Middleware" que conecta varias piezas de "lógica de negocios" para eliminar la codificación de los mensajes entre estos módulos. Creo que es una definición lo suficientemente general, pero estoy seguro de que ya has llegado a través de Wikipedia y todo eso.
Aquellos que quieren que el gran ESB salve el mundo lo ven como se lo presenta más comúnmente, un centro para hacer todo. La mayoría de las implementaciones de ESB intentan encapsular todas las tareas repetitivas que vemos en el software comercial. Eso significa que la mayoría de los ESB se ocupan de la transferencia de datos, la seguridad, el registro, la traducción de protocolos, los sistemas de eventos, la exposición a API a través de servicios web, etc.
Creo que eso es lo más claro que puedo ser ... Espero que eso ayude.
Descargo de responsabilidad: trabajo para IBM y consulto sobre WebSphere ESB, un producto de IBM diseñado para construir ESB con. Las siguientes son mis opiniones y no necesariamente reflejan la posición de IBM.
Un ESB es diferente para diferentes personas, desafortunadamente.
Para mí, una ESB es cualquier tecnología que pueda insertar en una SOA (arquitectura orientada a servicios), lo que le permite conectar sistemas dispares entre sí. A menudo realiza las funciones de transformación de protocolo, modificación de mensaje, enrutamiento, registro, actuando como una puerta de enlace de seguridad, etc. Por ejemplo, puede usar un ESB para exponer un servicio que anteriormente solo estaba disponible como un servicio web también como un servicio basado en JMS.
A este respecto, las implementaciones de ESB (o para ser más precisas, el software vendido para construir ESBs, como el que consulto) son a menudo tecnológicamente similares a lo que solía conocerse como un intermediario de mensajería o colas, aunque el propósito es algo diferente , porque (como implican los acrónimos) está orientado a servicios en lugar de mover mensajes de un lugar a otro. La importancia de la distinción es tecnológicamente una cuestión de opinión.
Eche un vistazo a mi presentación " Estropeado por la elección: cómo elegir el ESB correcto ".
Explico cuándo utilizar un ESB, un paquete de integración o simplemente un marco de integración (como Apache Camel). También discuto las diferencias entre los ESB de código abierto y propietario.
Es un concepto de abstracción de alto nivel. El concepto central es que el ESB proporciona el middleware y las interfaces que permiten a las empresas conectar sus aplicaciones sin escribir código.
Esto podría incluir la mediación para reconciliar protocolos incompatibles, datos e interacción.
La idea de un autobús central en el que todo pasa da la oportunidad de capas adicionales de abstracción. El uso de estándares de la industria para "conectar" otras aplicaciones, clientes y demás en este bus hace que conectar nuevos servicios, fuentes de datos, clientes con necesidades dispares sea relativamente fácil.
Implementaciones reales
En cuanto a las implementaciones reales, ese es el dominio de las grandes empresas de soporte empresarial. Si bien es muy animado, el objetivo es un ideal que en un nivel pequeño se puede entender a través de la comparación con Internet:
Similitud con Internet
Un gran bus de comunicaciones con usos y datos muy diferentes, pero todos ejecutan protocolos estandarizados.
De hecho, se puede escribir un conector HTTP a FTP que permita a los navegadores acceder a sitios FTP sin invocar un cliente FTP (generalmente integrado en el navegador ahora).
Mashups
Los mashups demuestran una implementación interesante: tomar algunos datos de ruta de autobús de la autoridad de San Francisco, mapear desde google, y ubicaciones de bares de sushi de Yahoo con calificaciones y ejecutar una consulta simple que te brinde la barra de sushi más cercana, ponderando para que estés dispuesto a viajar un poco más lejos para un mejor bar.
Todos los servicios completamente diferentes, incompatibles por sí mismos, pero utilizando conectores estándar (pipas de yahoo, por ejemplo) se pueden unir en un todo cohesivo y útil.
-Adán
Más allá de la definición estándar que puedes obtener de Wikipedia . Considero que es una gran herramienta para conectar un conjunto de sistemas heredados en múltiples plataformas y tecnologías. También es una buena herramienta para generar flujos de trabajo distribuidos y sistemas de gestión estatales (como el libro mayor).
Sin embargo, es bastante costoso, complejo e inconveniente de mantener y ampliar, lo que lo convierte en una opción de tecnología deficiente como herramienta de propósito general para escalar sus aplicaciones.
Mi experiencia con ESB comercial es que es una tecnología exagerada y costosa que crea tantos problemas como resuelve. El ESB conectará nuevos sistemas y legado, los mensajes volarán sobre el autobús y todo podrá hablar con todo lo demás sin problemas. Agregue un poco de resistencia, orquestación y tiene una pieza muy poderosa de software de aplicación empresarial.
El problema surge cuando intentas usarlos de manera real, la sobrecarga de escribir para el bus, crear las estructuras de mensajes y demás, pueden exceder los beneficios. Como elemento de alto costo, el ESB se ve como la panacea para todos los problemas tecnológicos que no lo es, se gasta demasiado tiempo en el bus y no en las aplicaciones / datos que se conectan. A menudo sucede que múltiples estándares competitivos luchan por la supremacía en la misma organización que lleva a los silos clásicos dominados por la tecnología que estos sistemas deberían estar solucionando.
En mi humilde opinión, es mucho mejor usar crear una pequeña cantidad de interfaces específicas, generalmente utilizando servicios web solo entre aquellos que lo necesitan.