source significado servicios open ejemplos ejemplo integration soa messaging esb

integration - significado - ¿Puede alguien explicarme un Bus de Servicios Empresariales sin un zumbido?



esb significado (6)

Después de investigar esto un poco, mi instinto es decir que esto es solo hablar por decir que tenemos que tener una forma independiente de la plataforma para pasar mensajes de un lado a otro

Eso es correcto. A veces, un ESB irá un poco más allá e incluirá funciones adicionales como garantías de entrega de mensajes, mensajes de confirmación / confirmación, etc. La presencia de un ESB también genera explícita o implícitamente un nuevo protocolo donde ninguno existía previamente, que es otra consideración importante. (Es decir, se debe establecer algún tipo de estándar o interfaz con respecto al formato de los mensajes).

¿Estoy en lo cierto al desechar la solicitud de nuestros socios simplemente tratando de que nuestro software sea más compatible con las palabras de moda, o nos están diciendo algo que debemos escuchar (incluso si está codificado en zumbido)?

Siempre debe escuchar a sus clientes, incluso si al principio suena tonto. Por lo general, vale la pena, al menos, gastar el esfuerzo para decidir qué está pasando. Leyendo entre líneas, lo que probablemente quieran decir sus socios es que quieren una manera para que su servicio se integre más fácilmente con sus propios servicios y productos.

Algunos de nuestros socios nos dicen que nuestro software necesita interactuar con un Enterprise Service Bus. Después de investigar esto un poco, mi instinto es decir que esto es solo hablar por decir que tenemos que tener una forma independiente de la plataforma para pasar mensajes de ida y vuelta. Solo estoy tratando de tener una idea de lo que nuestros socios nos dicen. ¿Estoy en lo cierto al desechar la solicitud de nuestros socios simplemente tratando de que nuestro software sea más compatible con las palabras de moda, o nos están diciendo algo que debemos escuchar (incluso si está codificado en zumbido)?


Después de investigar esto un poco, mi instinto es decir que esto es solo hablar por decir que tenemos que tener una forma independiente de la plataforma para pasar mensajes de un lado a otro

Estás en lo cierto, parcialmente porque el término ESB siempre es una palabra agradable que encaja bien con otra palabra de moda, legítima o no, que es gobernanza (es decir, te ayuda a gestionar quién accede a tus puntos finales y métricas de informes). Metrics es lo que les gusta a todos los trajes ver, entonces eso puede ser un contribuyente)

Otra razón por la que pueden querer un dispositivo neutral de plataforma es que todos los servicios que consuman estén siempre expuestos como puntos finales desde una ubicación central, en lugar de un recurso de máquina específico. El ESB hace que los puntos finales físicos reales de sus servicios sean irrelevantes para ellos, lo que no debería importarles de todos modos, pero que le permite mover los servicios, sin embargo, solo consumirán el ESB Endpoint.

Además de un repositorio centralizado para Discovery , un ESB también hace que las versiones de los servicios sean más sencillas. Si tuviera una opción y mi empresa tuviera el presupuesto, habríamos comprado el dispositivo x150 de IBM :(

En tercer lugar, una gran cantidad de buses más avanzados, como el producto de SoftwareAG si lo recuerdo, es nativamente capaz de exponer los datos heredados, como los datos que se encuentran en los marcos principales como servicios sin la necesidad de codificación a través de adaptadores

No sé si su intención es aprovechar todos los beneficios que ofrece ESB, o como usted dijo, hacer que cumpla con la palabra de moda.


Aunque ESB se basa en la mensajería, no es solo un mensaje y no solo una palabra de moda.

Entonces, si comienzas con un simple mensaje asincrónico, las primeras redes tendían a ser muy puntuales. Debías cablear (es decir, configurar a través de una interfaz de administrador) cada conexión y cada par de destinos, y si te atrevías a mover algo invariablemente algo se rompía. Debido a que los puntos de conexión estaban cableados a mano, estas redes nunca lograron una alta densidad de conexión. El costo incremental era demasiado alto y no escalaba. También había una gran cantidad de políticas y control de acceso integrados en la topología. La falta de densidad de conexión en realidad favorece este enfoque de seguridad, a pesar de que inhibe la flexibilidad.

El ESB intenta abordar estos problemas con ...

  • Resolución en tiempo de ejecución de destinos / servicios / recursos
  • Transparencia de ubicación
  • Conectividad Any-to-Any y máxima densidad de conexión
  • Diseñado para redundancia, escalabilidad horizontal, conmutación por error
  • Política, control de acceso, reglas externalizadas desde la topología
  • Capa de red de mensajería lógica implementada encima de la capa de red de mensajería física
  • Espacio de nombres común

Entonces, cuando su cliente solicita compatibilidad con ESB, quiere cosas como las anteriores. Desde el punto de vista de la aplicación, esto también implica ...

  • Evitar las afinidades de los mensajes, como los requisitos para procesar en una secuencia estricta o para dirigir las solicitudes solo a nodos específicos en lugar de a un destino de red genérico
  • Capacidad para resolver destinos dinámicamente en tiempo de ejecución (es decir, agregar otra instancia de una cola y automáticamente comienza a obtener tráfico, eliminar uno y rutas de tráfico a los nodos restantes)
  • Solicitantes y aplicaciones de proveedores desacoplados de saber dónde "viven" los demás. El solicitante hace una conexión, independientemente de la cantidad de servicios que pueda necesitar para llamar
  • Autorizar por política en lugar de por topología
  • Aplicaciones del proveedor de servicios capaces de reconocer y manejar duplicados (según la especificación JMS, ver "duplicados funcionales" debido al manejo de la sesión)
  • Posibilidad de ejecutar múltiples instancias activas de una aplicación de proveedor de servicios
  • Instrumente las aplicaciones del proveedor de servicios para que pueda consultar el estado de la red o realizar una prueba sin enviar una transacción real

Por otro lado, si su cliente no puede expresar estas cosas, es posible que solo desee poder marcar una casilla que dice "funciona con el ESB".


La explicación más simple es explicar lo que ofrece:

Durante muchos años, las empresas adquirieron diferentes plataformas y tecnologías para lograr funciones específicas en sus negocios, desde finanzas hasta recursos humanos. Estos sistemas necesitaban comunicarse entre sí para compartir datos, de modo que el middleware se convirtió en el pegamento que les permitía conectarse. Antes de que la empresa lo supiera, pagaban por soporte y mantenimiento en cada uno de estos sistemas y en el middleware. A medida que las necesidades cambiaban en el negocio, los departamentos decidieron crear sus propias soluciones personalizadas para abordar las necesidades especiales en lugar de tratar de hacer que las soluciones de envejecimiento fueran lo suficientemente flexibles como para satisfacer sus necesidades. Antes de que lo supieran, pagaban para respaldar y mantener los sistemas heredados, el middleware y las soluciones personalizadas. Con nuevas leyes como Sarbanes Oxley, las empresas necesitan tener mejor información disponible para los informes. Una vista única requiere que capturen datos de todos los sistemas. Además, ahora se está presionando a los CIO para que reduzcan los costos y aumenten el servicio al cliente. Una solución obvia es eliminar los sistemas redudant, los costosos contratos de soporte y mantenimiento, y las soluciones heredadas de alto costo que requieren el soporte de especialistas. Moverse a una nueva plataforma permite esto, pero es necesario que haya una transición. No hay soluciones integrales que puedan replicar lo que hace la empresa. Para abordar las necesidades de mover información, van con SOA porque permite el acceso a la información a través de una entidad genérica. Si solicito AllEmployees desde el bus de servicio, los obtengo ya sea de 15 sistemas de recursos humanos o 1. Cuando los 15 sistemas de recursos humanos se convierten en 1 sistema, la llamada y el resultado no cambian, solo cómo se hizo detrás de escena. El concepto de Bus de servicio estandariza el flujo de información y permite a los gerentes de TI realizar transiciones detrás del autobús sin efecto a largo plazo para los usuarios intermedios.


Trataré de mantener la palabra de moda libre (pero puede aparecer un acrónimo de zumbido).

Cuando los servicios / aplicaciones / mainframes / etc ... quieren integrarse (por lo que se envían mensajes entre ellos), puede terminar en un lío. Un ESB esconde ese lío dentro de sí mismo (o de ellos mismos) para que una organización pueda pretender que no hay un desastre y que tiene algo manejable. A continuación, envuelve una gran cantidad de características para hacer que esta caja sea aún más atractiva para las personas mayores de una organización que tomarán la decisión de comprar un producto tan costoso. Por lo general, estas personas querrán introducir una gran iniciativa que cuesta mucho dinero para demostrar que están ''haciendo algo'' y saben cómo gastar grandes cantidades de dinero. Si se trata de una iniciativa SOA, varios proveedores les habrán dicho que se requiere un ESB para que los proveedores tengan una idea clara de qué SOA funciona (por lo general, una vez que el número de servicios que desean supera un número trivial).

Entonces un ESB es:

  1. Un vehículo para que los vendedores ganen mucho dinero;
  2. Un vehículo para consultores para ganar mucho dinero;
  3. Una forma para que los altos ejecutivos (Directores de TI y similares) demuestren que pueden gastar mucho dinero;
  4. Una caja para esconder un desastre;
  5. Un PITA total para un equipo técnico con el que trabajar.

Un bus de servicio empresarial maneja los mensajes entre sistemas de forma estándar. Esto le permite comunicarse con el bus de la misma manera en todas sus plataformas y el bus maneja la traducción real al mecanismo de comunicación individual necesario para el punto final específico. Esto significa que usted escribe todo su código para hablar con el autobús usando un esquema de mensajería común y el bus maneja su esquema común y lo traduce para que el punto final lo entienda.