¿Deberíamos presentar BizTalk/ESB?

Question

Mi empresa está a punto de implementar una nueva arquitectura en la que hemos propuesto BizTalk (somos una tienda de Microsoft) como Enterprise Service Bus (ESB) en un entorno SOA (no cite la Ambigüedad Orientada al Servicio).

Nuestro negocio es tomar pedidos a través de nuestra nueva GUI de Order Capture que debe conectarse a nuestra base de datos de clientes, catálogo de productos, sistema de pedidos y algunos otros sistemas auxiliares que se expondrán como servicios de WCF. Gestión de pedidos y otros sistemas downstream para el cumplimiento y finalmente a nuestro sistema de Facturación para la facturación. Actualmente, cada sistema tiene su propia GUI y utiliza el proceso manual para pasar información entre ellos, en un esfuerzo por automatizar e integrar el pensamiento natural era introducir un ESB para conectarlos.

Algunos de mis motivos para un ESB es que el bus se preocupará por cómo conectar los sistemas (cada sistema es independiente y no sabe nada de ningún otro sistema) y cómo formatear/traducir la información. Es muy probable que en el futuro algunos de los sistemas existentes se intercambien por sistemas o sistemas nuevos dentro de nuestra familia de empresas.

Esto parece tener sentido para mí, pero ahora me encuentro con cierta resistencia en cuanto a por qué introducirlo cuando una solución punto a punto podría ser suficiente.

Desafortunadamente en el historial de la compañía (antes de mi cita) falló un intento inicial de introducir BizTalk, pero estoy seguro de que tiene un lugar y puedo entregarlo.

Mi pregunta quizás no sea tanto acerca de BizTalk, pero si un ESB es una buena idea en mi escenario descrito, ¿cuándo tiene sentido presentar un ESB?

Answer 1

Creo que tiene sentido tener un intermediario de datos basado en los requisitos que describió, pero personalmente no creo que BizTalk sea la mejor opción en su situación. Para el tipo de integración que ha descrito, miraría un dispositivo de intermediario de datos de hardware. Algunas de las que he visto funcionan bien son IBM DataPower, el dispositivo de Vordel y el dispositivo de Layer7. Para el tipo de llamadas que usará para esto, un dispositivo es ideal. Proporcionan enrutamiento, transformación y traducción, además de que protegerán contra cosas como el envenenamiento por esquema. También manejarán la autorización, autenticación y auditoría al vincularla a su tienda de usuario (supongo que tiene una tienda de usuarios de Active Directory basada en el entorno que describió, pero también funcionará con LDAP)

An el dispositivo será BizTalk o cualquier otra solución de software en términos de costo de propiedad (sin costos de soporte), y el rendimiento de cualquier dispositivo probablemente superará a BizTalk en un orden de magnitud.

Answer 2

Bien. ESB Orientación sobre Biztalk del grupo presrciptive architechture - http://msdn.microsoft.com/en-us/library/cc487894.aspx

Utilizamos BizTalk donde trabajo para hacer muchas cosas. Él tiene algunas intuiciones de puntos simples. Tenemos algunas integraciones de puntos más complicadas con adpaters y tuberías altamente personalizados. Contamos con integraciones de sistemas empresariales divisionales para el maestro de clientes, información de productos y precios y presupuestos por pedido. Estas son todas las aplicaciones de BizTalk separadas. Algunos bastante pequeños y otros bastante grandes. Principalmente hemos usado BizTalk para hacer sesiones punto a punto/muchos puntos sin usar un patrón ESB. La implementación de un ESB implica un nivel de gobernanza del bus en sí y los estándares de mensaje de la empresa que se permitirán en el autobús. Si va a interactuar con una gran cantidad de sistemas con una gran cantidad de formatos diferentes, ESB tiene mucho sentido. Si las integraciones que desea lograr son menos ambiciosas, un ESB puede ser excesivo. Dicho esto, es una arquitectura limpia y extensible. Deberá tomar la decisión del valor de costo.

BizTalk es también una bestia complicada, pero con todas las partes móviles viene un nivel de flexibilidad que es maravilloso. Pero prepárese para una curva de aprendizaje o algunos costos de consultoría.

Answer 3

Tiendo a evitar el término ESB porque creo que está muy sobrecargado; al final del día, en todas las descripciones que he recibido, es solo un patrón, una vez que BizTalk admite muy bien.

Entonces, ¿creo que BizTalk se ajustará a lo que desea hacer? categóricamente sí. Creo que tiene razón para evitar las conexiones punto a punto, también sí, pero, al igual que con cualquier ejercicio de refactorización para su reutilización, incluida cualquier iniciativa SOA, debe considerar cuánto cambio y ahora mucha reutilización espera decidir cómo ahora estás tomando el ejercicio de "desacoplamiento".

Answer 4

Es un patrón muy distinto. Normalmente, cuando envía un mensaje del Sistema A al Sistema B, realiza una conversión directa del formato del Sistema A al formato que el Sistema B desea. Cuando tiene un ESB, convierte el mensaje del sistema A al formato ESB (es decir, PO, orden, etc.) genéricos y luego al formato requerido por el sistema B. Es una conversión de dos en comparación con 1 y también, el patrón de bus requiere cada mensaje tiene un verbo (es decir, agregar, eliminar, actualizar, etc.). Esta es una distinción realmente importante y es lo que hace que ESB sea muy útil en integraciones con muchos sistemas participantes.

Answer 5

Debe hablar sobre la latencia y el rendimiento. Todo lo demás es bla bla.

Answer 6

acabo de recibir esta misma pregunta de un colega y esto es lo que le dije:

En la mayoría de escenarios de integración puede ir muy lejos antes de usar algo como BizTalk. Me aseguraría de que no pude hacer la integración más simplemente antes de ir con BizTalk. Sólo

si parece que la solución de integración necesita para escalar a altas volúmenes con baja latencia (que tiene una fantástica asíncrono publicación-suscripción mecanismo ), y necesidad Tolerancia a Fallos (que tiene redundancia, la ampliación y reintentar el mensaje características) y el gobierno sobre la solución (tiene Actividad empresarial Monitoreo) realmente tendría argumentos fuertes para considerar el uso de BizTalk. Y si sabe que hay son múltiples integraciones futuras que se necesitarán , entonces realmente se obtiene convincente para utilizar BizTalk.

Por otro lado, necesita hacer asegúrese de que las habilidades están disponibles para operar el tema. Se necesita un tiempo para aprender y un cambio de paradigma para los desarrolladores de los sistemas . Sin embargo, está construido desde cero en .NET y SQL Server, por lo que hay bastante de familiaridad en los conceptos de herramientas y .

creo que la clave es conseguir que la arquitectura conceptual de una solución derecho teniendo en cuenta las requisitos no funcionales como rendimiento, disponibilidad, extensibilidad, resistencia, robustez, y escalabilidad y asegurarse de que son abordados correctamente por el diseño técnico . Puede encontrar su más barato para pagar la licencia de 35k $ por CPU por lo que BizTalk le da a conocer la caja que desarrollar para todos estos NFR.

También recientemente implementé el nuevo ESB Toolkit 2.0 en un cliente y estoy muy contento con él. La funcionalidad de procesamiento del Itinerario (ver el patrón de deslizamiento de enrutamiento http://www.enterpriseintegrationpatterns.com/RoutingTable.html) realmente hace que los servicios web de composición sean fáciles, flexibles y rápidos.