Integração de sistema

Pessoal quais são as vantagens e desvantagens de integrar sistemas por meio de Banco de Dados ?

Olá

Impossível dizer. Pode ser bom em alguns casos é péssimo em outros.

Pelo menos não é tão ruim quanto usar RPC, RMI e outras tecnologias acopladoras e intrusivas do milênio passado.

[]s
Luca

Trabalhar sobre um socket é coisa do século passado? hmm #not [/minhaopniao]

Olá

Também depende. Se for para engrunvinhar os sistemas a serem integrados como em geral ocorre com RPC, acho ruim.

Se for para trocar mensagens sem que um sistema precise saber como o outro trata as mensagens, então pode ser bom.

É como eu disse antes, não há bala de prata. Há que analisar caso a caso. Algumas vezes um arquivo do tipo CSV gravado no file system á mais do que suficiente apesar de ser técnica dos primórdios da computação.

[]s
Luca

[quote=Zaperjava]Pessoal quais são as vantagens e desvantagens de integrar sistemas por meio de Banco de Dados ?

[/quote]

De cara eu diria: desempenho, durabilidade e suporte a grande volume de dados, desempenho pq geralmente uma consulta ao banco é menos custosa do que outros tipos de integração que exigem parsings extensos, durabilidade pq como os dados estão persistidos eles sobrevivem a um eventual crash do servidor e por fim, suporte a grande volume de dados, pq outras tecnologias integradoras como web services tem um péssimo desempenho com dados > 10Mgb, enquanto com banco de dados esse volume é teoricamente ilimitado.

[quote=deniswsrosa][quote=Zaperjava]Pessoal quais são as vantagens e desvantagens de integrar sistemas por meio de Banco de Dados ?

[/quote]

De cara eu diria: desempenho, durabilidade e suporte a grande volume de dados, desempenho pq geralmente uma consulta ao banco é menos custosa do que outros tipos de integração que exigem parsings extensos, durabilidade pq como os dados estão persistidos eles sobrevivem a um eventual crash do servidor e por fim, suporte a grande volume de dados, pq outras tecnologias integradoras como web services tem um péssimo desempenho com dados > 10Mgb, enquanto com banco de dados esse volume é teoricamente ilimitado.[/quote]

Mas por exemplo , duas aplicações acessando o mesmo Banco de Dados faz cair o desempenho do SGBD . Não?

Muito relativo. Você pode ter 2 pessoas realizando consultas monstruosas gerando uma visualização em tempo de execução de um DM grande, ou 200 pessoas visualizando dados e realizando poucas alterações.

Pode levar em conta o link de comunicação. Acessar uma base de dados através de uma rede 100mb ou uma adsl 1mb.

E por fim, a própria qualidade do sgbd e o do hardware. Um Oracle sobre 64 núcleos de vários GHz só fica lento quanto tiver alguns Teras de dados, ainda assim provendo serviço adequadamente.

Só fiquei um pouco em dúvida sobre essa integração… seriam apenas dados? Ou lógica de negócio? A aplicação integrada sendo distribuída ou local, nesse caso, também poderia influenciar na tal integração.

E eu achando que integrar pelo banco era sempre ruim… :slight_smile:

Valeu pelos exemplos, galera!

Acho entao que a grande desvantagem e talvez a unica seria re-implementar a logica de Negocio certo ?

[quote=Zaperjava]Acho entao que a grande desvantagem e talvez a unica seria re-implementar a logica de Negocio certo ?

[/quote]

Concordo em partes, pq se sua lógica de negócio está carimbada na sua aplicação então você tem um claro problema de arquitetura. Imagine uma requisição para modificar uma de suas regras, vc terá de alterar isso em N outros sistemas.

Um cenário possível por exemplo seria o de vc colocar todas as suas regras de negócio em EJBs, dessa forma vc pode usar as mesmas regras para N aplicações, sem contar as vantagens de Escalabilidade e outros que todo mundo já sabe de cor e salteado.

Pode-se tb fazer uma integração mista, ou seja… tudo que exigir lógicas de negócio vc integra via EJB, tudo que for somente visualização por exemplo vc busca direto do banco.

Mas no geral é difícil mostrar um caminho sem saber o cenário que vc pretende aplicá-la, como vc já deve estar cansado de ouvir, cada caso é um caso.

[quote=deniswsrosa][quote=Zaperjava]Acho entao que a grande desvantagem e talvez a unica seria re-implementar a logica de Negocio certo ?

[/quote]

Concordo em partes, pq se sua lógica de negócio está carimbada na sua aplicação então você tem um claro problema de arquitetura. Imagine uma requisição para modificar uma de suas regras, vc terá de alterar isso em N outros sistemas.

Um cenário possível por exemplo seria o de vc colocar todas as suas regras de negócio em EJBs, dessa forma vc pode usar as mesmas regras para N aplicações, sem contar as vantagens de Escalabilidade e outros que todo mundo já sabe de cor e salteado.

Pode-se tb fazer uma integração mista, ou seja… tudo que exigir lógicas de negócio vc integra via EJB, tudo que for somente visualização por exemplo vc busca direto do banco.

Mas no geral é difícil mostrar um caminho sem saber o cenário que vc pretende aplicá-la, como vc já deve estar cansado de ouvir, cada caso é um caso.[/quote]

Em relação a parte negritada, não sei se você está afirmando isso de maneira geral ou em cima do problema do autor do tópico.

Pois não dá para afirmar isso de maneira generalista pois existem inúmeros sistemas que concentram a lógica de negócio na aplicação e usam o BD apenas como repositório de dados.

[]'s

[quote=Daniel_MV]…

[]'s[/quote]

Olá!

Citei isso com base no possível problema do autor, pois se na integração de duas aplicações através de banco de dados você precisar “replicar a lógica de negócios” , então deve-se na verdade ter uma única lógica de negócio que é acessada por ambas.

Agora se tiver um sistema isolado ( leia-se, “Ninguém mais mexe no meu queijo”). Você pode sem problema nenhum carimbar sua lógica dentro da sua aplicação. Que na prática é o que acontece em 90% dos casos, senão mais.

Eu só recomendaria em casos muito específicos, não como primeira opção.

Grande desvantagem é apelido. Nessas horas você acaba usando o mesmo sistema para ser leão-de-chácara do BD, e fazendo integração por ele, o que deixaria de ser integração por BD.

A grande questão é se você consegue fazer essa integração e ainda manter os dados consistentes, durante todas as dezenas de anos que os sistemas que se integrarem com este banco se mantiverem funcionando.

As vantagens são reais, tem muita velocidade, mas pra isso precisa ter rédeas curtas e controle absoluto.

@Zaperjava,
Os colegas já levantaram alguns aspectos críticos a serem levados em conta na definição de 1 Arquitetura p/ Integração.
Gostaria de apenas deixar minha opinião: defendo fortemente a centralização do Fluxo, Lógica e Regras de Negócio em um (tipo de) Business-Core / Servidor de Aplicações.
Mas, tb depende: se sua Organização estiver pensando em Governança de Serviços (SOA), aí já seria mais indicado uma Engine de Orquestração BPM: um BPMS.
Ou seja, vai depender muito de seu Cenário e seus Requisitos.

[quote=derlon]@Zaperjava,
Engine de Orquestração BPM: um BPMS.
Ou seja, vai depender muito de seu Cenário e seus Requisitos.[/quote]

Cara, o que é “Engine de Orquestração BPM”?

Já que BPM é o gerenciamento dos processos, esse engine centralizaria as regras de negócio?

Exatamente xdraculax!!
Não só as Regras, mas tb o Fluxo e a Lógica de Negócio!
Aliás, existem BPMSs q oferecem/permitem a implementação de 1 Módulo ‘Gerenciamento de Regras de Negócio’, no qual o Analista de Negócio/Gerente/DomainExpert (ou seja, 1 cara não tecnico, q não é programador, etc.) alterar as Regras de Negócio sem q seja preciso alterar 1 linha de código do Fonte. 8)

Eu tenho péssima experiências com integração via banco de dados! Depende de cara projeto, mas eu geralmente sou contra.

Eu acho muito problemático ter várias aplicações lendo uma mesma base de dados, pior ainda várias aplicações alterando a mesma base de dados. É muito fácil a situação ficar caótica e você não conseguir enchergar que aplicação altera que dado em que tabela. Sem falar na duplicação de códigos entre aplicações para interpretar o que cada dado significa, validações, etc e todos so problemas que essa duplicação de código traz.

O pior é tratar os eventos que devem acontecer quando um dado é inserido ou alterado… numa aplicação que eu trabalhei no ano retrasado, várias aplicações liam e alteravam os dados dos funcionários. Isso era um problema por que existia uma necessidade de executar um processo de uma das aplicação cada vez que um funcionário era demitido ou entrava de férias… No fim acabamos fazendo uma aplicação só pra cuidar do cadastro dos funcionários, todas as outras aplicações que precisavam acessar ou alterar dados dos funcionários passaram a utilizar essa aplicação e tinhamos mecanismos que permitiam trabalhar melhor com notificações de eventos (nada muito sofisticado, tinha muito espaço para melhoras, mas é melhor que usar trigger).

Enfim, acho que o banco de dados deve ser utilizado por apenas um sistema, os outros sistemas não devem acessar direto o banco de dados e sim usar algum outro mecanismo de integração (queue, WS, EJB…)

Concordo plenamente o o Rubem Azenha! :thumbup: Além de essa abordagem só trazer transtornos, como o de Inconsistência nos Dados, Sou totalmente contra usar “artifícios” de BD, como Triggers, Stored Procedures, Fuctions, Views, etc. Só se for para melhorar performance -> e se não tiver outro jeito mesmo! :hunf:

Ah, xdraculax: Opa, eu não tinha visto a sua pergunta[quote=xdraculax]Cara, o que é “Engine de Orquestração BPM”?
[/quote]É uma Ferramenta q permite o Mapeamento de Processos de Negócios -> WebServices, via BPEL (ou JDPL) e oferece uma ferramenta Gráfica q permite alterar a ordem q os Processo são executados (adicionar ou remover Processos) de forma muito facilitada.
1 ex. é o jBPM da JBoss (ah, p/ os fãs da dupla netBeans/Glassfish tem tb o OpenESB)!

[quote=Rubem Azenha]Eu tenho péssima experiências com integração via banco de dados! Depende de cara projeto, mas eu geralmente sou contra.

Eu acho muito problemático ter várias aplicações lendo uma mesma base de dados, pior ainda várias aplicações alterando a mesma base de dados. É muito fácil a situação ficar caótica e você não conseguir enchergar que aplicação altera que dado em que tabela. Sem falar na duplicação de códigos entre aplicações para interpretar o que cada dado significa, validações, etc e todos so problemas que essa duplicação de código traz.

O pior é tratar os eventos que devem acontecer quando um dado é inserido ou alterado… numa aplicação que eu trabalhei no ano retrasado, várias aplicações liam e alteravam os dados dos funcionários. Isso era um problema por que existia uma necessidade de executar um processo de uma das aplicação cada vez que um funcionário era demitido ou entrava de férias… No fim acabamos fazendo uma aplicação só pra cuidar do cadastro dos funcionários, todas as outras aplicações que precisavam acessar ou alterar dados dos funcionários passaram a utilizar essa aplicação e tinhamos mecanismos que permitiam trabalhar melhor com notificações de eventos (nada muito sofisticado, tinha muito espaço para melhoras, mas é melhor que usar trigger).

Enfim, acho que o banco de dados deve ser utilizado por apenas um sistema, os outros sistemas não devem acessar direto o banco de dados e sim usar algum outro mecanismo de integração (queue, WS, EJB…)[/quote]
Exato. A parte de eventos é uma das piores. Geralmente o banco fica cheio de triggers e vira um inferno dar manutenção.

Como disse no início, é claro que cada caso é um caso, mas só usaria se não houvesse outra opção.

[]s