¿BizTalk es un ESB?

eai (10)

Estoy buscando en patrones de arquitectura, Enterprise Services Bus (ESB) con precisión. 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 y Biztalk , describiendo a 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 mensajes.

¿Es Biztalk un EAI en lugar de un ESB?

Muchas gracias

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

En una empresa anterior, elegimos Biztalk en lugar del producto IBM ESB por razones de funcionalidad y menor costo.

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

BizTalk es ciertamente un ESB. EAI es un concepto más generalizado: BizTalk puede implementarse para ser compatible con EAI, y también puede hacer mucho más.

BizTalk es más que un ESB pero ciertamente cumple con los requisitos. Este enlace es un poco viejo, pero responde a tu pregunta exacta.

EDITAR: Aquí hay un enlace de MS más reciente que incluye información específica de la implementación.

BizTalk es una plataforma de mensajería y orquestación de flujo de trabajo, en la que puede crear comportamientos y capacidades de ESB. Para hacer esto más fácil y estandarizar la implementación de ESB en BizTalk, Microsoft lanzó el kit de herramientas ESB de BizTalk, un conjunto de pautas, patrones y códigos.

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

Entonces, en resumen, BizTalk fuera de la caja no es EAI o ESB, pero puede hacer ambas cosas con varios desarrolladores aplicados al problema.

BizTalk puede hacer tanto ESB como EAI, depende de cómo diseñe sus aplicaciones biztalk.

BizTalk se puede utilizar como EAI y ESB.

En cuanto a ESB, la arquitectura del servidor BizTalk es publicación-suscrita, se puede publicar un solo mensaje en el buzón de mensajes que actúa como el bus 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 al usar el servidor BizTalk como la herramienta de mapeo y el uso de componentes de canalización, por ejemplo.

Para su uso como EAI, BizTalk le ofrece orquestaciones que administran la lógica empresarial, los adatpers de LOB (Línea de negocio) para conectarse a los sistemas (también heredados), la herramienta de asignación, el motor de reglas y mucho de lo que necesita para integrar los diferentes Sistemas dentro o fuera de su empresa.

Biztalk Server sin "ESB Toolkit" no es un ESB. Por lo siguiente:

Es un contrato primero, necesita construir sus tipos de mensajes primero.
Necesita planificar todo el escenario primero para minimizar el impacto de los cambios.
Los cambios requieren una implementación que aumenta el tiempo de inactividad.

Con respecto a su qustion, Yes BizTalk Server es un producto EAI

Estoy de acuerdo con la mayoría de lo que se dice aquí. Es un esfuerzo para lanzar BizTalk como una solución EBS todo incluido incluso con el kit de herramientas EBS.

Para abordar un par de puntos hechos aquí ...

• BTS es más adecuado para los procesos asíncronos que para los procesos síncronos: las latencias variarán según la carga en el sistema, el estado de regulación, etc.

Los hosts de BizTalk con valores predeterminados sin cambios no son ideales para una latencia baja. Pero esos anfitriones están destinados a ser sintonizados. La configuración inmediata no es adecuada para cualquier situación en la que se necesite rendimiento. En mi experiencia de entrar en una organización en la que se ha rechazado BizTalk, siempre hay una configuración de host único sin sintonizar en medio de ella. Es algo similar a hacer tablas en un dbms sin índices, obtener problemas de rendimiento y decir que el propio dbms apesta.

• BTS es incómodo cuando se trata de la facilidad de versión de servicios y esquemas (se necesita una nueva implementación)

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

En lo que respecta a los puntos finales del servicio, BizTalk puede hospedar servicios web sin el uso de IIS (BizTalk puede usar HTTP.SYS para hospedar como lo hace IIS). Alojar un servicio en 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 has llegado a una conclusión antes de ahora :)

Microsoft considera que BizTalk tiene capacidades ESB; consulte el kit de herramientas BTS ESB

Sin embargo, el término ''ESB'' cubre un campo muy amplio , y hay mucha subjetividad acerca de una definición exacta de un ESB. En mi humilde opinión, hay puntos débiles en la afirmación de BizTalk de ser integral como un ESB (en una definición> 2010 del término).

BTS se originó en la era EAI de Hub-and-Spoke, antes de que la ESB se generalizara.
BTS es más adecuado para los procesos asíncronos que para los procesos síncronos: las latencias variarán según la carga en el sistema, el estado de regulación, etc.
BTS es incómodo cuando se trata de la facilidad de versión de servicios y esquemas (se necesita una nueva implementación)
BTS es incómodo cuando se trata de la administración de MUCHOS servicios (por ejemplo, usar BizTalk como fachada para los 5000 servicios SOA / Web corporativos será difícil)

FWIW hemos encontrado que BTS es una buena opción para:

todos nuestros EAI síncronos y asíncronos (es decir, contratos de integración formalizados entre los principales sistemas de LOB y con socios comerciales), y la gran cantidad de adaptadores ayuda a integrar una gran cantidad de protocolos.
Para procesos de negocio y capacidades de monitoreo de negocios.
Abordar la fiabilidad transaccional y de entrega: Biztalk tiene la capacidad de reintentar, rastrear y reanudar los mensajes suspendidos, lo cual es útil en redes no confiables o cuando se trata de integración con sistemas no confiables.

Actualización , con algunas experiencias comparativas adicionales.

BTS es muy centralizado; en última instancia, incluso un clúster / grupo de BizTalk multiservidor depende de Sql-Server. Los productos de ESB basados en la cola tienden a ser más descentralizados (lógica y físicamente), por lo que la pérdida de algunos servidores de punto final o de cola no debería perjudicar a toda la empresa.
Muchos ESB basados en la cola se basan en tecnologías de código abierto, con el objetivo de evitar el bloqueo de un solo proveedor
Muchos ESB contemporáneos parecen tomar un enfoque de commodity-computing para escalar. La ampliación de escala con productos como BizTalk puede resultar costosa.
En el lado positivo, las capacidades de monitoreo y administración de ofertas comerciales como BTS no deben ser subestimadas. Asegúrese de que cualquier ESB que esté considerando tenga capacidades adecuadas de auditoría, instrumentación, reintento y diagnóstico (WMI / SNMP / SCOM, etc.). necesita un panel para monitorear la salud de su autobús, y no hay nada peor que no saber a dónde fue un mensaje. Aquí, la administración de centralización y el diagnóstico es un plus.

Por " EAI o ESB " Supongo que quiere saber si BizTalk sigue la arquitectura de Hub & Spoke o Bus.

Desde la perspectiva de los patrones de arquitectura, las soluciones de integración se enmarcan aproximadamente en uno de los dos patrones:

El concentrador y la radio : se trata de un agente de mensajes centralizado que envía mensajes a varios receptores, mientras que todos los remitentes envían sus mensajes solo a este agente. Por lo tanto, ni los remitentes ni los receptores deben estar conscientes el uno del otro. Esto suele ser lo que muchas personas denominan 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 administra de forma centralizada en un lugar, en el concentrador. Pero como habrías adivinado, esto tiene un inconveniente evidente: un solo punto de falla. Si el hub se estrella todo se detiene. Además, este modelo no se escala muy bien.
BUS : Las soluciones de integración empresarial desarrolladas alrededor de este patrón generalmente se conocen como ESB. Aquí no hay una autoridad central inteligente. Todos los remitentes publican sus mensajes en el bus. Los receptores deben ser lo suficientemente inteligentes para determinar qué mensajes están destinados a ellos y sacarlos del bus. 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 punto único de falla. También este modelo es altamente escalable. Sin embargo, tales soluciones son bastante complejas y difíciles de administrar.

A la pregunta de qué patrón sigue BizTalk, es un híbrido de ambos patrones.

La apariencia de Hub es muy obvia con su motor de mensajería centralizado y una base de datos central de MessageBox . Esto le da a uno la simplicidad y facilidad de administración que es típica del enfoque de hub.

Pero si nos fijamos en la arquitectura de BizTalk, uno puede tener un Host con sus Instancias de Host distribuidas en múltiples servidores. También es posible tener 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 hub de ejecución del molino, que es un comportamiento generalmente atribuido al enfoque de bus.

Espero que esto responda a su pregunta.