¿Es BizTalk un ESB?

Question

Estoy buscando patrones arquitectónicos, Enterprise Services Bus (ESB) precisamente. Al leer este artículo Enterprise Integration, y con poca o ninguna experiencia, me pregunto si BizTalk tiene un ESB o es solo un EAI (Hub/Spokes o Bus)?

Encontré este NServiceBus and Biztalk, describiendo BizTalk como un intermediario central de mensajes.

Teniendo en cuenta otros marcos ESB (NServiceBus y Rhino Service Bus). Estos marcos no tienen un punto central para procesar los mensajes.

¿Es Biztalk un EAI en lugar de un ESB?

Muchas gracias

Answer 1

BizTalk es sin duda un ESB. EAI es más un concepto flexible: BizTalk ciertamente se puede implementar para soportar EAI, y también puede hacer mucho más.

Answer 2

BizTalk es más que un ESB pero sin duda cabe la factura. This link es un poco viejo, pero responde su pregunta exacta.

EDITAR: Aquí está a more-recent MS link que entra en detalles de la implementación.

Answer 3

BizTalk se despejó por Microsoft como tener capacidades ESB - ver la BTS ESB toolkit

Sin embargo, el término 'ESB' cubre una muy broad field, y hay una gran cantidad de subjetividad sobre una definición exacta de un ESB. En mi humilde opinión, hay puntos débiles en el reclamo de BizTalk de ser integral como ESB (en una> definición de 2010 del término).

• BTS se originó en la era de Hub-and-Spoke EAI, antes de que ESB se extendiera.
• BTS es más adecuado hacia procesos asíncronos que los procesos síncronos - latencias variarán dependiendo de la carga en el sistema, el estado de estrangulamiento, etc.
• BTS es engorroso cuando se trata de la facilidad de control de versiones de los servicios y los esquemas (nuevo despliegue se es necesario)
• BTS es engorroso cuando se trata de la gestión de los servicios de muchos (por ejemplo, utilizando BizTalk como fachada para todos 5000 de su SOA corporativa/servicios web serán dolorosas)

Fwiw hemos encontrado BTS un buen ajuste para:

• todos nuestros EAI síncronos y asíncronos (es decir, contratos de integración formalizados entre los principales sistemas LOB, y con socios comerciales), y la gran cantidad de adaptadores ayuda a integrar una gran cantidad de protocolos.
• para hacer negocios y observación de procesos de negocios capacidades
• Direccionamiento Reliablity transaccional y la entrega - Biztalk tiene la capacidad de volver a intentarlo, el seguimiento y la reanudación de los mensajes suspendidos, que es útil a través de redes no confiables o cuando se trata de la integración con los sistemas no fiables.

actualización, con algunas experiencias comparativas adicionales

• BTS es muy centralizado - en última instancia, incluso un grupo de BizTalk múltiples servidores/grupo depende de SQL Server. Los productos ESB basados ​​en cola tienden a ser más descentralizados (lógica y físicamente), por lo que la pérdida de unos pocos servidores de punto final o de cola no debería hacer que toda la empresa caiga.
• basadas Muchos cola de ESB se basan en tecnologías de código abierto, con un ojo puesto en evitar la dependencia de un proveedor único
• Muchos de ESB contemporánea parecen tomar un enfoque commodity-computing de escalar. Escalar con productos como BizTalk puede ser costoso.
• En el lado positivo, las capacidades de monitoreo y administración de ofertas comerciales como BTS no deben subestimarse: asegúrese de que cualquier ESB que considere tenga capacidades adecuadas de auditoría, instrumentación, reintento y diagnóstico (WMI/SNMP/SCOM, etc.) Necesitarás un tablero para monitorear el estado de tu bus, y no hay nada peor que no saber a dónde fue el mensaje. Aquí, la administración de centralización y el diagnóstico es una ventaja.

Answer 4

BizTalk es una plataforma de mensajería y orquestación de flujo de trabajo, en el que se puede construir comportamientos y capacidades ESB. Para hacerlo más fácil y estandarizar la implementación de ESB en BizTalk, Microsoft lanzó el BizTalk ESB Toolkit: un conjunto de directrices, patrones y códigos.

Los conceptos de EAI y BPM han existido por un tiempo, por lo que hay muchas empresas que han aprovechado BizTalk para crear soluciones a estos problemas. Las empresas que alojan un ESB completo en el servidor BizTalk son mucho menos, y la adopción ciertamente se ha ralentizado con la llegada de WCF/WF/NServiceBus y, por supuesto, Azure Service Bus.

Por lo tanto, en resumen, BizTalk de fábrica es EAI inferior o ESB, pero puede hacer ambas cosas con un número de desarrolladores aplicados al problema.

Answer 5

BizTalk se puede utilizar como EAI y ESB.

En cuanto a ESB, la arquitectura del servidor BizTalk está suscrita para publicar, se puede publicar un solo mensaje en el buzón de mensajes que actúa como el bus de la red troncal de mensajería. Ese mensaje puede ser recibido por uno o más sistemas de destino que están suscritos a ese mensaje. Por supuesto, hay más capacidades y características que puede obtener utilizando el servidor BizTalk como la herramienta de asignación y el uso de componentes de canalización, por ejemplo.

Para usar como EAI, BizTalk le ofrece orquestaciones que administran la lógica de negocios, LOB (Línea de negocios) adaptadores para conectarse a sistemas (también heredados), herramienta de correlación, motor de reglas y mucho de lo que necesita para ordenar para integrar los diferentes sistemas dentro o fuera de su empresa.

Answer 6

¡Absolutamente! Biztalk proviene de un fondo EIS, que tiene perfecto sentido para ESB como un backplane de infraestructura para arquitecturas orientadas a servicios que abarcan plataformas técnicas híbridas.

En una empresa anterior elegimos Biztalk con preferencia al producto IBM ESB por razones de funcionalidad y menor costo.

Es Microsoft, así que obtienes lo que pagas, pero vale la pena investigar.

Answer 7

Biztalk Server withot "ESB Toolkit" No es un ESB. por lo siguiente:

1. es un contrato en primer lugar, la necesidad de construir que los tipos de mensajes en primer lugar.
2. Es necesario planificar todo el escenario primero para minimizar el impacto de los cambios.
3. Los cambios requieren una implementación que aumenta el tiempo de inactividad.

En cuanto a su qustion, Sí BizTalk Server es EAI Producto

Answer 8

Estoy de acuerdo con la mayor parte de lo que se dice aquí. Es difícil lanzar BizTalk como una solución EBS todo incluido, incluso con el kit de herramientas de EBS.

Para hacer frente a un par de puntos hechos aquí ...

• BTS es más adecuado para los análisis asíncronos que síncronos procesos - latencias variarán dependiendo de la carga en el sistema, estado de estrangulamiento, etc.

Los hosts BizTalk con los valores predeterminados no modificados no son ideales para una baja latencia. Pero esos anfitriones están destinados a ser sintonizados. La configuración lista para usar no es adecuada para ninguna situación en la que se necesite un rendimiento. En mis experiencias de entrar en una organización donde se ha evitado BizTalk, siempre hay una instalación única sintonizada en el medio. Es algo similar a hacer tablas en un dbms sin índices, obtener problemas de rendimiento y decir que el propio DBMS apesta.

• BTS es engorroso cuando se trata de la facilidad de control de versiones de servicios y esquemas (es necesario un nuevo despliegue)

Al igual que con cualquier plataforma de desarrollo es necesario tener una estrategia de implementación. Si los esquemas tienen una versión en el espacio de nombres, no necesita volver a desplegar nada. Una nueva versión puede implementarse sin quitar nada.

En lo que respecta a los puntos terminales de servicio, BizTalk puede alojar servicios web sin el uso de IIS (BizTalk puede usar HTTP.SYS para hospedarlo como lo hace IIS). Alojar un servicio de proceso en BizTalk es simplemente una cuestión de importar un enlace que se puede hacer sin detener nada en BizTalk. En esos puntos finales también puede implementar el control de versiones (como http: .../thing/v1, http: .../thing/v2, etc.).

De todos modos ~ 5 años han pasado Estoy seguro de que usted ha golpeado una conclusión antes de ahora :)

Answer 9

Por "EAI o ESB" Estoy asumiendo que usted quería saber si BizTalk sigue el eje del rayo del & o la arquitectura de Bus.

Desde una perspectiva patrones de arquitectura, soluciones de integración más o menos son de una de las dos patterns-

• El concentrador y radio: Esto implica un intermediario de mensajes centralizado el envío de mensajes a varios receptores, mientras todos los remitentes envían sus mensajes solo a este intermediario. Por lo tanto, ni los remitentes ni los receptores deben conocerse entre sí. Esto suele ser lo que muchas personas llaman EAI (aunque es absolutamente posible implementar una solución EAI que siga el patrón BUS). Las soluciones que siguen este patrón son fáciles de desarrollar y administrar. Toda la lógica de enrutamiento se gestiona centralmente en un solo lugar: en el centro. Pero como habrás adivinado, esto tiene un inconveniente evidente: punto único de falla. Si el concentrador falla, todo se detiene. Además, este modelo no se escala muy bien.

• BUS: Las soluciones de integración empresarial que se desarrollan en torno a este patrón generalmente se conocen como ESB. No hay una autoridad central inteligente aquí. Todos los remitentes publican sus mensajes en el autobús. Los receptores deben ser lo suficientemente inteligentes como para determinar qué mensajes están destinados a ellos y sacarlos del autobús. Por lo tanto, los remitentes y los receptores solo deben conocer el bus. Pero aquí la lógica de enrutamiento se extiende a través de los receptores por lo que no hay un solo punto de falla. También este modelo es altamente escalable. Sin embargo, tales soluciones son bastante complejas y difíciles de administrar.

Llegando a la pregunta qué patrón sigue BizTalk, es un híbrido de estos dos patrones.

la apariencia a modo de cubo es muy evidente con su motor de mensajería centralizado , y una base de datos de cuadro de mensaje central de . Esto le da a uno la simplicidad y facilidad de administración que es típica del enfoque central.

Pero si nos fijamos en la arquitectura de BizTalk, uno puede tener una anfitrión con sus instancias de host difusión a través de múltiples servidores. También es posible tener las diferentes bases de datos de BizTalk como MessageBox, Tracking, Ent SSO, etc. configuradas en diferentes servidores. Esto hace que las soluciones de BizTalk sean más escalables y tolerantes a las fallas que las implementaciones de concentradores corrientes, que es un comportamiento generalmente atribuido al enfoque del bus.

Espero que responda a tu pregunta.