Qual é a melhor maneira de sincronizar dados entre sistemas dissociados?

Question

Eu tenho digamos 2 (mas eles vão tornar-se mais no futuro) sistemas totalmente dissociados:. Um sistema e sistema de B

Digamos cada pedaço de informação em cada sistema tem um informationID. Não há nada que impeça o informationID ser o mesmo em sistemas diferentes. O que univocamente identifica um pedaço de informação em todos os sistemas é um par Fonte-informationID.

Digamos que eu preciso exportar um pedaço de informação de Sistema A para o sistema B. Eu, então, deseja exportar o mesmo pedaço de informações do System B e importe-a novamente no Sistema A e eu preciso ser capaz de reconhecer que é o mesmo pedaço de informação.

Qual é a melhor maneira de fazer isso na experiência das pessoas?

Este é o que eu estou pensando em fazer:

1. Configuração de um barramento de mensagens entre o sistemas com filas de mensagens.
2. endpoints de configuração para cada sistema que irá monitorar as mudanças e gerar comandos em embrulhadas mensagens que serão bombeados em filas (por exemplo quando um pedaço de informação é criado / excluídos / atualizados).
3. Atribuir classifica os endpoints em relação ao criar / update / delete comandos em ordem sem contar com nomes do sistema, mas apenas em um general hierarquia - de modo que cada sistema não precisa saber sobre o outros.
4. Atribua um limiar de update / delete / criar comando para cada ponto final para que os comandos não satisfazer o requisito treshold serão filtradas e não processados ??

Isso não vai resolver o fato de que eu ainda preciso levar em torno de originalSource + originalSourceID embora.

Qualquer ajuda apreciado.

Answer 1

Este problema tem sido abordado por EAI (Enterprise Application Integration) fornecedores como Tibco e webMethods (agora parte da Software AG). Eu nunca usei Tibco antes, mas eu usei webMethods para resolver este tipo de problemas, então eu vou apenas focar webmethods. Por exemplo, em uma empresa, os dados sobre os funcionários poderiam residir no Active Directory e PeopleSoft. webMethods poderiam ser usadas para garantir que as alterações, adições, eliminações em um sistema (aplicação) vai ser reflectida no outro em tempo real. Em alguma outra organização, os dados sobre os funcionários também poderia ser em um banco de dados Oracle ou SQL Server. Novamente, não é um problema. Estas ferramentas de EAI como webMethods pode falar com uma ampla variedade de back-ends. webMethods não se limita a uma única fonte e um único alvo, mas porque tem uma arquitetura de publicação-assinatura, os dados de uma única fonte pode fluir para alvos múltiplos interessados ??que se inscrevem em uma determinada peça de informação. entrega garantidos e podem outras características podem ser encontradas nestes produtos. Voltar para o exemplo empregado, em última análise, se alguém faz isso direito, a qualquer momento, todos os sistemas e aplicações em uma empresa pode conter a mesma informação sobre os empregados sem qualquer discrepância.

Assim, em vez de fazer a programação em C # ou Java, você estará fazendo webMethods de programação que é muito parecido com uma linguagem 4GL. Eu chamo-lhe a programação porque ainda há lógica envolvida, loop, se, em seguida, outra pessoa, ramo, variáveis, pacotes, etc, mas é muito processo orientado, ou seja, nenhum conceito de OOP em tudo.

Estas ferramentas EAI são construídas com fins limitados em mente e um dos propósitos é Sincronizar dados entre diferentes sistemas em uma empresa com facilidade. E eles fazem seu trabalho muito bem.

A desvantagem é essas ferramentas custar muito dinheiro. As empresas muitas vezes têm uma estratégia de longo prazo antes de investir nessas ferramentas.

Answer 2

Como alguém já escreveu, isso soa como um problema típico EAI. Mesmo se ferramentas EAI costumava ser caro, agora há uma grande variedade de livre, ferramentas open-source. Abaixo uma lista dos que eu como a maioria

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

O meu favorito é OpenESB, eu sei que é melhor, tem um IDE completo (Netbeans), suporte opcional a partir de um grande fornecedor e um enorme quantidade de componentes adicionais . Por sua simplicidade e eficácia então eu amo Apache Camel, mas você pode tentar alguns daqueles e decidir qual delas funciona melhor para você. Então você pode até decidir comprar serviços de apoio para todos aqueles.

Answer 3

Estamos fazendo muito bonito exatamente o tipo de A -> B -> A coisa que você descreve. Inicialmente considerado tentando ter todo o A, B, sendo pares C etcs, mas que era muito difícil, por isso um agora designado como o mestre, e os outros escravos. Ainda é bastante fácil de obter material de um escravo para outro, mas via o mestre.

É tudo feito sobre serviços web - conjuntos de dados ir para cima e para baixo de escravo a mestre e vice-versa, e o escravo é executado a exportação em si, e chama a importação no master. Ele, então, diz o mestre para fazer uma exportação, e corre a importação sobre si mesmo.

Assim, o código é idêntico em cada sistema. É apenas os escravos que chamam de casa.

Os processos de exportação e importação dizer o negócio relevante objetos para fazer toda a sua lista e poupando o material, uma vez que já sabe como instanciar e persistem-se de DataRows.

Não é uma arquitetura de muitos-dezenas de transações por segundo, mas funciona, e pode alcançar a sincronização de tempo quase real.

Nós não melhoraram na singularidade Fonte / Id, pela maneira:)

Answer 4

Este é extremamente simplificado se você atribuir a cada pedaço de informação que um GUID. Se você precisa manter o controle de fonte e outros IDs, tudo bem, mas a informação shuold sempre viajar com o seu atribuído GUID.

Quando uma máquina vê aquele pedaço de informações novamente, ele verá o GUID e associá-lo com os dados existentes, e então você pode decidir o que fazer. Mas você já sabe que é o mesmo pedaço de dados -. Apenas melhor viajou

Tenha em mente que GUIDs são criados de tal maneira a que cada máquina irá criar o seu próprio e eles não entrarão em conflito (para todos os fins e propósitos práticos) com os GUIDs criado em outra máquina, ou a mesma máquina em um diferente tempo.

Esta é uma das razões maiores GUIDs foram criadas.

-Adam

Answer 5

A menos que haja alguma limitação específica no projeto do sistema impedindo isso, eu sugiro factoring as informações compartilhadas / compartilhável em um DB separado que os outros dois podem referência ou apenas replicar localmente. Então você não precisa a chave de elemento duplo, nem qualquer elaborado ESB engenhoca ...