Integração de sistema .

JavaChild Membro desde: 17/03/2010 09:24:42 Mensagens: 107 Offline

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

Olá

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

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

JavaChild Membro desde: 21/10/2008 20:57:22 Mensagens: 103 Offline

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

Olá

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

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

GUJ Ranger Membro desde: 21/07/2005 08:51:27 Mensagens: 807 Offline

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

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.

JavaChild Membro desde: 17/03/2010 09:24:42 Mensagens: 107 Offline

deniswsrosa wrote:

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

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.

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

Thread.start() Membro desde: 19/03/2007 16:06:20 Mensagens: 26 Offline

Zaperjava wrote:
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...

Valeu pelos exemplos, galera!

JavaChild Membro desde: 17/03/2010 09:24:42 Mensagens: 107 Offline

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

GUJ Ranger Membro desde: 21/07/2005 08:51:27 Mensagens: 807 Offline

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

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.

JavaEvangelist Membro desde: 30/04/2007 07:43:01 Mensagens: 424 Offline

deniswsrosa wrote:

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

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.

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

GUJ Ranger Membro desde: 21/07/2005 08:51:27 Mensagens: 807 Offline

Daniel_MV wrote:...

[]'s

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.

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

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

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.

JavaTeenager Membro desde: 12/12/2009 14:07:01 Mensagens: 150 Offline

@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.

Notícias, artigos e o maior fórum brasileiro sobre Java