Qual a melhor forma de integrar vários sistemas?

Question

Ok onde eu trabalho temos um número bastante substancial de sistemas escritos ao longo do último par de décadas que mantemos.

Os sistemas são diferentes em que vários sistemas operacionais (Linux, Solaris, Windows), vários bancos de dados (várias versões do Oracle, Sybase e MySQL), e até mesmo várias línguas (C, C ++, JSP, PHP, e uma série de outros) são utilizados.

Cada sistema é bastante autônomo, mesmo à custa de inserir os mesmos dados em múltiplos sistemas.

Administração decidiu recentemente que devemos investigar o que vai demorar para obter todos os sistemas feliz conversando entre si e compartilhamento de dados.

Tenha em mente que, enquanto nós podemos fazer mudanças de software a qualquer um dos sistemas individuais, uma reescrita completa de qualquer sistema de um (ou mais) não é gestão de algo é provável que entreter.

O primeiro pensamento de vários dos desenvolvedores aqui foi a frente: Se o sistema Um precisa de dados do sistema B deve apenas conectar ao banco de dados do sistema do B e obtê-lo. Da mesma forma, se ele precisa dar dados B deve basta inseri-lo no banco de dados de B.

Devido à confusão de bancos de dados (e versões) utilizados, outros desenvolvedores eram da opinião de que devemos ter um novo banco de dados, combinando as tabelas de todos os outros sistemas para evitar ter que lidar com várias conexões. Ao fazer isso eles esperam que sejamos capazes de consolidar algumas tabelas e livrar-se da entrada de dados redundantes.

Isto é sobre o tempo que foi trazido para a minha opinião sobre toda a confusão.

A idéia de usar o banco de dados como um meio de comunicação sistema cheira engraçado para mim. A lógica de negócios terá de ser colocado em vários sistemas (se o sistema A quer adicionar dados ao Sistema de B-lo a entender melhor as regras do B relativas aos dados antes de fazer a inserção), vários sistemas provavelmente terá que fazer algum tipo de sondagem de banco de dados para encontrar quaisquer alterações em seus dados, manutenção contínua será uma dor de cabeça, como qualquer mudança para um esquema de banco de dados agora propaga vários sistemas.

Meu primeiro pensamento foi para tomar o tempo e APIs de gravação / Serviços para os diferentes sistemas, que uma vez escrito poderia ser facilmente usado para passar / recuperar dados e para trás. Um monte de outros desenvolvedores acham que é excessivo e muito mais trabalho do que apenas usando o banco de dados.

Então, o que seria a melhor maneira de ir sobre a obtenção desses sistemas para falar uns com os outros?

Answer 1

A integração de sistemas díspares é o meu trabalho do dia.

Se eu fosse você, eu iria para um grande esforço para evitar o acesso a dados do Sistema A partir diretamente no Sistema B. Atualização banco de dados do Sistema A partir do sistema B é extremamente imprudente. É exatamente o oposto de boas práticas para tornar a sua lógica de negócios de modo difuso. Você vai acabar lamentando-lo.

A ideia de base de dados central não é necessariamente ruim ... mas a quantidade de esforço envolvido é provavelmente dentro de uma ordem de grandeza de reescrever os sistemas a partir do zero. Ela certamente não é algo que eu iria tentar, pelo menos na forma que você descreve. Ele pode ter sucesso, mas é muito, muito mais difícil e é preciso muito mais disciplina do que a abordagem de integração ponto-a-ponto. É engraçado ouvir isso sugeriu no mesmo fôlego como a abordagem 'cowboy' de apenas empurrando dados diretamente em outros sistemas.

No geral seus instintos parecem muito bom. Há um par de abordagens. Você menciona um: serviços de execução. Isso não é um mau caminho a percorrer, especialmente se você precisar de atualizações em tempo real. O outro é um aplicativo de integração separado que é responsável por embaralhar os dados ao redor. Essa é a abordagem que eu costumo tomar, mas geralmente porque eu não posso mudar os sistemas Estou integrando a pedir os dados de que necessita; Eu tenho que empurrar os dados. Em seu caso, a abordagem de serviços não é um mau.

Uma coisa que eu gostaria de dizer que pode não ser óbvio para alguém que vem para a integração do sistema pela primeira vez é que cada pedaço de dados em seu sistema deve ter um único ponto, autoridade da verdade. Se os dados são duplicados (e ele é duplicado), e as cópias em desacordo uns com os outros, a cópia no ponto da verdade para que os dados devem ser tomados para ser correto. Simplesmente não há outra maneira de integrar sistemas sem ter a complexidade grito para o céu a uma taxa exponencial. integração Spaghetti é como código espaguete, e deve ser evitado a todo custo.

Boa sorte.

EDIT:

Middleware aborda o problema do transporte, mas isso não é o problema central na integração. Se os sistemas estão perto o suficiente para que um aplicativo pode empurrar os dados diretamente para outra, eles são provavelmente perto o suficiente para que um serviço oferecido por um pode ser chamado diretamente por um outro. Eu não recomendaria middleware no seu caso. Você pode obter algum benefício a partir dele, mas que seria compensado pelo aumento da complexidade. Você precisa resolver um problema de cada vez.

Answer 2

Parece que você pode querer investigar Message Queuing e orientado a mensagem middleware .

MSMQ e noreferrer sendo exemplos Java Message Service .

Answer 3

Parece que você está procurando opiniões, por isso vou dar o meu.

Eu concordo com os outros desenvolvedores que escrever uma API para todos os diferentes sistemas é excessivo. Você provavelmente iria fazê-lo mais rápido e tem muito mais controle sobre ele se você tomar apenas a outra sugestão de criação de um único banco de dados.

Answer 4

Um dos desafios que você terá é alinhar os dados de cada um dos diferentes sistemas de modo que ele pode ser integrado em primeiro lugar. Pode ser que cada um dos sistemas que deseja integrar detém inteiramente diferentes conjuntos de dados, mas mais provável é os dados que são sobrepostas. Antes de mergulhar na escrita API: s (que é a rota que eu levaria bem dada sua descrição) Eu recomendaria que você tentar chegar a um modelo lógico de dados para os dados que precisa ser integrado. Este modelo de dados, então, ajudá-lo a alavancar os dados que você está tendo nos diferentes sistemas e torná-lo mais útil para os outros bancos de dados.

Eu também recomendo uma abordagem iterativa para a integração. Com sistemas legados há tanta incerteza que tentar projetar e implementar tudo de uma só vez é muito arriscado. Comece pequeno e trabalhar seu caminho para um sistema razoavelmente integrado. "Totalmente integrado" é quase nunca vale a pena buscando.

Answer 5

Diretamente interface via bases de dados empurrando / cutucando expõe um monte de detalhes interna de um sistema para outro. Existem desvantagens óbvias: atualizar um sistema pode quebrar o outro. Além disso, pode haver limitações técnicas como um sistema pode acessar o banco de dados do outro (considerar como um aplicativo escrito em C no Unix irá interagir com um banco de dados SQL Server 2005 em execução no Windows 2003 Server).

A primeira coisa que você tem que decidir é a plataforma onde o "banco de dados mestre" irá residir, e o mesmo para o middleware fornecendo a cola muito exigido. Em vez de ir para o nível API middleware-integração (como CORBA), gostaria de sugerir que você considere Message Oriented Middleware. MS Biztalk, eGate da Sun e Fusion da Oracle pode ser algumas das opções.

A sua ideia de um novo banco de dados é um passo na direção certa. Você pode gostar de ler um pouco mais sobre Entidade Empreendimento Agregação padrão.

A combinação de "integração de dados" com um middleware é o caminho a percorrer.

Answer 6

Se você estiver indo para a estratégia de banco de dados Middleware + Individual Central, você pode querer considerar a realização deste em várias fases. Aqui está um processo passo lógico que pode ser considerado:

1. Implementação de serviços / APIs para sistemas diferentes, que expõe a funcionalidade para cada sistema
2. Implementação de Middleware que acessa essas APIs e fornece uma interface para todos os sistemas para acessar os dados / serviços de outros sistemas (acessa os dados da fonte central, se disponível, mais recebe-lo de outro sistema)
3. Implantação de Banco de Dados Central só, sem dados
4. Implementação de Cache / serviços de dados de armazenamento no nível Middleware que pode armazenar / cache de dados na base de dados central, sempre que os dados são acessados ??a partir de qualquer um dos sistemas, por exemplo, registros de se o sistema A 1-5 são buscadas pelo Sistema B através Middleware, os dados de cache serviços de middleware pode armazenar esses registros no banco de dados centralizado e da próxima vez que esses registros será buscada a partir do banco de dados central
5. Os dados Cleansing pode acontecer em paralelo
6. Também é possível criar um mecanismo de importação para enviar dados a partir de múltiplos sistemas à base de dados central numa base diária (automatizado ou manual)

Desta forma, o esforço é distribuído em vários marcos e dados está gradualmente armazenados no banco de dados central na primeira acessada primeira-armazenados base.