Pregunta

Tengo digamos 2 (pero habrá más en el futuro) sistemas completamente desacoplados:sistema A y sistema B.

Digamos que cada pieza de información en cada sistema tiene un ID de información.No hay nada que impida que el ID de información sea el mismo en diferentes sistemas.Lo que identifica unívocamente una pieza de información en todos los sistemas es un par Fuente-ID de información.

Digamos que necesito exportar una información del sistema A al sistema B.Luego quiero exportar la misma información del Sistema B y volver a importarla al Sistema A y necesito poder reconocer que es la misma información.

¿Cuál es la mejor manera de hacer esto según la experiencia de la gente?

Esto es lo que estoy pensando hacer:

  1. Configure un bus de mensajes entre el sistemas con colas de mensajes.
  2. Configuración de puntos de conexión para cada sistema que supervisará los cambios y generar comandos encapsulados en Mensajes que serán bombeados en colas (por ejemplo, Cuando un dato es creado/eliminado/actualizado).
  3. Asignación de rangos a los puntos de conexión en relación con la creación/eliminación/actualización comandos para no depender de nombres de sistemas, pero solo de forma general jerarquía, de modo que cada sistema no necesita saber acerca de la otros.
  4. Asignar un allanamiento de morada update/delete/create a cada uno endpoint para que los comandos no Cumplir con el requisito de allanamiento de morada se filtrará y no se Procesado

Sin embargo, esto no resolverá el hecho de que todavía necesito llevar consigo originalSource+originalSourceID.

Cualquier ayuda se agradece.

¿Fue útil?

Solución

Este problema ha sido abordado por proveedores de EAI (Enterprise Application Integration) como tibco y webMétodos (ahora parte de Software AG).Nunca antes había usado Tibco, pero sí webMethods para resolver este tipo de problemas, así que me centraré únicamente en webmethods.Por ejemplo, en una empresa, los datos sobre los empleados podrían residir tanto en Active Directory como en PeopleSoft.webMethods podría usarse para garantizar que los cambios, adiciones y eliminaciones en un sistema (aplicación) se reflejen en el otro en tiempo real.En alguna otra organización, los datos sobre los empleados también podrían estar en una base de datos Oracle o SQL Server.De nuevo, no hay problema.Estas herramientas de EAI, como webMethods, pueden comunicarse con una amplia variedad de servidores.webMethods no se limita a una única fuente y un único destino, sino que debido a que tiene una arquitectura de publicación-suscripción, los datos de una única fuente pueden fluir a múltiples objetivos interesados ​​que se suscriben a una determinada información.Entrega garantizada y muchas otras características se pueden encontrar en estos productos.Volviendo al ejemplo de los empleados, en última instancia, si se hace bien, en un momento dado, todos los sistemas y aplicaciones de una empresa pueden contener la misma información sobre los empleados sin ninguna discrepancia.

Entonces, en lugar de programar en C# o Java, realizarás programación webMethods, que es muy parecida a un lenguaje 4GL.Lo llamo programación porque todavía hay lógica involucrada, bucle, if then else, rama, variables, paquetes, etc., pero está muy orientado a procedimientos, es decir.ningún concepto de programación orientada a objetos en absoluto.

Estas herramientas de EAI se crean con propósitos limitados en mente y uno de ellos es sincronizar fácilmente los datos entre sistemas dispares en una empresa.Y hacen muy bien su trabajo.

El inconveniente es que estas herramientas cuestan mucho dinero.Las empresas suelen tener una estrategia a largo plazo antes de invertir en estas herramientas.

Otros consejos

Como alguien ya escribió, esto suena como un problema típico de EAI. Incluso si las herramientas de EAI solían ser caros, ahora hay una amplia variedad de herramientas libres, de código abierto. A continuación una lista de los que más me gustan

  1. OpenESB
  2. mula
  3. Apache ServiceMix
  4. Apache Camel

Mi favorito es OpenESB, sé que es mejor, tiene un IDE completo (Netbeans), soporte opcional de un gran vendedor y un enorme cantidad de componentes adicionales . Por su simplicidad y eficacia a continuación, Me encanta Apache Camel, pero se puede probar algunos de estos y decidir cuál funciona mejor para usted. Después, se puede decidir comprar servicios de apoyo para todos aquellos.

Estamos haciendo prácticamente exactamente el tipo de A -> B -> A que usted describe.Inicialmente consideramos intentar que todos los A, B, C, etc. fueran pares, pero eso fue demasiado difícil, por lo que ahora designamos a uno como maestro y a los demás como esclavos.Todavía es bastante fácil pasar cosas de un esclavo a otro, pero a través del maestro.

Todo se hace a través de servicios web: los conjuntos de datos suben y bajan del esclavo al maestro y viceversa, y el esclavo ejecuta la exportación sobre sí mismo y solicita la importación en el maestro.Luego le dice al maestro que realice una exportación y ejecuta la importación por sí mismo.

Entonces el código es idéntico en cada sistema.Sólo los esclavos llaman a casa.

Los procesos de exportación e importación le dicen a los objetos comerciales relevantes que hagan todos sus listados y guarden cosas, ya que ya saben cómo crear instancias y persistir desde DataRows.

No es una arquitectura de muchas decenas de transacciones por segundo, pero funciona y puede lograr una sincronización casi en tiempo real.

Por cierto, no hemos mejorado la unicidad de Fuente/Id. :)

Esto es enormemente simplificada si se asigna cada pieza de información que un GUID. Si necesita hacer un seguimiento de la fuente y otros identificadores, eso está bien, pero la información siempre shuold viajar con su GUID asignado.

Cuando una máquina ve que parte de la información de nuevo, que va a ver el GUID y asociarlo con los datos existentes, y entonces usted puede decidir qué hacer. Pero usted ya sabe que es la misma pieza de datos - sólo mejor viajó

.

Tenga en cuenta que los GUID son creados de tal manera que cada máquina creará su propio y que no entren en conflicto (para todos los efectos prácticos) con los GUID creados en otra máquina, o la misma máquina en una diferente tiempo.

Esta es una de las razones más grandes GUID fueron creados.

-Adán

A menos que exista alguna limitación específica en el diseño del sistema de prevención de esto, me gustaría sugerir factorización de la información compartida / compartible en una base de datos independiente que los otros dos pueden referencia o simplemente replicar localmente. A continuación, usted no necesita la clave de elemento dual ni ningún artefacto elaborado ESB ...

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top