open source - ¿Cuáles son algunas alternativas viables a BizTalk Server?
open-source (12)
Mi experiencia con BizTalk fue básicamente una frustrante pérdida de tiempo.
Hay tantos casos extremos y pequeños ajustes de lógica de negocios extraños que tiene que hacer cuando realiza la integración de datos B2B (que es probablemente la parte más difícil de cualquier aplicación empresarial) que solo necesita para rodar su propia solución.
¿Qué tan difícil es analizar los archivos de datos y convertirlos a un formato diferente? No es tan difícil. A menos que estés tratando de inyectar un sistema de middleware hinchado como Biztalk en medio de él.
Al evaluar diferentes estrategias de integración de sistemas, he encontrado algunas palabras de aliento, pero también algunas palabras de frustración sobre BizTalk Server.
¿Cuáles son algunos de los pros y los contras del uso de BizTalk Server (tanto desde el punto de vista de un desarrollador como de un usuario de negocios), y las compañías también deberían considerar alternativas de código abierto? ¿Qué alternativas viables hay por ahí?
EDITAR: Jitterbit parece una opción interesante. Código abierto y parece estar muy bien diseñado. ¿Alguien aquí tiene alguna experiencia trabajando con eso?
En el espacio de OSS (aunque nunca los he usado personalmente como reemplazo de BizTalk, esto es anecdótico) puede usar uno de los motores de mensajería Java / J2EE como OpenMQ (que es la empresa de Sun una rebadged y sin soporte). Si necesita orquestación / coreografía (es decir, piezas de SOA / ESB) además de esto, podría ver algo como Apache Mule
No tengo experiencia directa con JitterBit, pero he escuchado cosas muy buenas de compañeros de trabajo.
Utilizamos BizTalk durante un par de años, pero lo abandonamos por nuestro propio marco personalizado que permitía más flexibilidad.
Como consultor de BizTalk, tengo que estar de acuerdo, al menos en parte, con Eric Z Beard, hay muchos casos extremos que requieren mucho tiempo. Pero bastantes escenarios se manejan extremadamente bien también, por lo que todo depende de la OMI. Pero cuando (Eric) llamas a BizTalk hinchado, ¡tengo que estar en desacuerdo! Descubrimos que el rendimiento y la confiabilidad son excelentes, son flexibles y vienen con muchos buenos adaptadores listos para usar.
Evaluamos BizTalk en nuestra empresa y nos sentimos realmente decepcionados.
Estamos utilizando IBM WebSphere Transformation Extender (que también tiene muchos (otros) problemas) y la herramienta de mapeo de BizTalk es una broma en comparación con WTX.
La herramienta gráfica no es realmente útil para mapeos complejos (tenemos esquemas con unos cientos de campos en grupos repetitivos) y si haces más de las asignaciones habituales de "concat nombre y apellido a nombre", estarás cansado de la gráfica enfoque (por ejemplo, los argumentos de los functoids en el mapeador gráfico no están etiquetados y el orden en el que se conectan los campos a estos argumentos es importante).
El XSLT-Mapper era utilizable pero no muy convincente, e incluso el representante de microsoft nos dijo que usáramos una herramienta como XMLSpy para XSLT y carguemos el archivo XSL resultante en BizTalk.
Un tercer enfoque para el mapeo es usar el C # -Code para el mapeo, que no era aceptable para nosotros como un enfoque general (no queremos enseñar a todos C #).
Además de la herramienta de mapeo, no nos gustó la implementación en BizTalk. Para implementar su proceso, necesita realizar muchas configuraciones en diferentes herramientas y lugares. Esperábamos encontrar un mecanismo como un archivo WAR para aplicaciones web Java en BizTalk, de modo que usted pueda proporcionarle un archivo para su solución de proceso completo a su administrador y él pueda implementarlo.
Hemos estado usando BizTalk desde la versión 2004, y ahora tenemos una mezcla de versiones 2006 R2 y 2004 en ejecución. Descubrí que la curva de aprendizaje era bastante severa, y el tiempo de desarrollo para las soluciones no siempre es rápido. Esas son definitivamente deficiencias. Donde realmente sobresale BizTalk es en su tolerancia a fallas, entrega garantizada y rendimiento. Puede estar seguro de que los datos no se perderán. La funcionalidad de reintento y la robustez de la tolerancia a fallas están incorporadas, por lo que, en términos generales, si los sistemas están caídos, BizTalk se encargará de eso y la entrega exitosa ocurrirá una vez que los sistemas vuelvan a funcionar. Todos estos problemas, como el tiempo de inactividad, etc., que son importantes en un escenario de integración, son manejados por BizTalk.
Además, en términos generales, al desarrollar soluciones, BizTalk abstrae los protocolos de comunicación y formatos de datos de los sistemas nativos al tratar todo como xml, por lo que cuando desarrolla soluciones, normalmente no tiene que escribir código específico para esos sistemas, usa BizTalk xml marco de referencia.
En el último año, implementamos un motor de código abierto de Java llamado Mirth para nuestro enrutamiento HL7. Descubrí que para HL7, el adaptador HL7 para BizTalk es un reto para trabajar. La administración señaló que usamos Mirth para el enrutamiento HL7. Donde BizTalk se cae en términos de curva de aprendizaje, Mirth lo compensa. Es mucho más fácil desarrollar una solución. El problema con la alegría es que realmente no tiene ninguna entrega garantizada. La mayoría de los adaptadores (a excepción de hl7) no tienen funcionalidad de reintento, por lo que si lo desea, tendrá que escribir los suyos propios. En segundo lugar, Mirth puede perder fecha si baja. Lo llamaría muy fácil de usar (aunque no hay documentación) pero sería difícil llamarlo una solución empresarial. Voy a ver jitterbit que fue mencionado por otra persona.
Me encontré con Apatar (no se puede publicar url, pero Google lo encuentra) mientras buscaba una solución más económica que BizTalk. Todavía tengo que probar esto.
Mi última compañía tuvo muchos problemas con BizTalk al ser demasiado compleja y complicada, pero no puedo evitar pensar que esto se debió principalmente a la implementación que hizo el consultor.
BizTalk necesita ser utilizado correctamente, soy desarrollador de BizTalk y mi experiencia con BizTalk es bastante buena. Es confiable, eficiente y escalable, contiene una gran cantidad de patrones arquitectónicos incorporados y componentes incorporados para hacer que la integración sea fácil y rápida, obtienes seguridad, reintentos, transportes secundarios, validación, transformación, etc. y lo que sea que no tengas compilado con BizTalk puede personalizar fácilmente con el código .NET, básicamente es un sistema de integración difícil de conseguir y obtiene todo esto en una sola caja. PERO necesita saber cómo implementar BizTalk correctamente, no una vez que encontré las soluciones que se implementaron y, a menudo, también se diseñaron incorrectamente.
pero el beneficio real de BizTalk es que puede implementar pequeñas soluciones y escalar, mientras que la mayoría de los otros sistemas de integración de grandes proveedores solo venderán un paquete de integración completo que puede costar mucho más.
BizTalk se considera el servidor más complicado de la casa de Microsoft.
Por lo tanto, cualquier persona que diga BizTalk no es buena dosent conoce el período BizTalk.
Mi experiencia con BizTalk y haciendo integraciones B2B es que la mayoría de las organizaciones realmente no diseñan primero ni comprenden por completo los estándares xml. La mayoría tiende a tejer objetos y esperan que se materialicen en esquemas ambiguos. En un entorno empresarial, esto es al revés.
BizTalk tiene una curva de aprendizaje, pero una vez que la obtiene, se le recompensa con durabilidad, rendimiento, escalabilidad real y extensibilidad. Sin embargo, como muchos han dicho, lo mejor es asegurarse de que satisfaga sus necesidades y contorsionar sus necesidades con BizTalk.
En el pasado, he trabajado con BizTalk 2004 hasta 2009, y otro producto llamado webMethods.
Siempre existe el marco OpenESB de Sun (ahora Oracle). En general, es una versión más pequeña y ligera de Biztalk pero con más o menos las mismas características.
Sin embargo, puedes escribir más código con él.
Su código abierto también.
El beneficio clave de BizTalk Server es que proporciona una gran cantidad de "fontanería" en torno a la implementación, la administración, el rendimiento y la escalabilidad. A través de Visual Studio, también proporciona un marco completo para desarrollar soluciones, a menudo con relativamente poco código.
La frustración y la pronunciada curva de aprendizaje que otros mencionan a menudo proviene del uso de BizTalk con el propósito equivocado y de un malentendido acerca de cómo trabajar con BizTalk y los sistemas orientados a mensajes en general. La curva de aprendizaje no es tan pronunciada como sugiere la mayoría de la gente: la parte esencial del aprendizaje subyacente se centra realmente en cambiar el pensamiento desde un enfoque de procedimiento a un enfoque basado en mensajes sin estado.
Un inconveniente que la gente suele citar es el costo. El precio de la etiqueta puede parecer bastante alto; sin embargo, esto es barato en comparación con el monto que gastaría en desarrollar y soportar funciones por su cuenta.
Antes de considerar alternativas, o incluso considerar el servidor BizTalk, debe considerar el enfoque de integración de su organización y sus objetivos a largo plazo. BizTalk Server es excelente en los casos en que desea integrar sistemas utilizando un modelo de hub y spoke donde BizTalk organiza las actividades de muchas aplicaciones.
También hay otros modelos de integración, uno de los más populares es un bus distribuido (no confunda esto con el término "Enterprise Service Bus" o ESB). También puede hacer que BizTalk funcione como un bus distribuido y existen soluciones alternativas que brindan un soporte más directo. Una de las soluciones alternativas es una solución de código abierto llamada nServiceBus.
Al considerar si utilizar un producto comercial como BizTalk, versos de otra cosa (de código abierto o desarrollado en casa), también considere el mantenimiento y las mejoras y la disponibilidad del conjunto de habilidades necesarias en el mercado.
Escribí algunos artículos que detallan más sobre los puntos que discutí aquí: aquí están los enlaces: