Como se atreve a oferecer uma solução simples que funciona?! 
A frase correta seria :
“Integração via banco, é o que todo mundo, sem noção, faz.”
Esse é o pior tipo de integração de todos os tempos. Nunca, nunca o utilize. Hoje não ha mais razão para isso.
[/quote]
Acho que você está confundindo integração via banco com “modelar todos os sistemas da empresa em um único banco”.
Integração via banco é um padrão bastante comum e continua sendo a solução ideal quando os dados precisam estar sincronizados em tempo real.
A frase correta seria :
“Integração via banco, é o que todo mundo, sem noção, faz.”
Esse é o pior tipo de integração de todos os tempos. Nunca, nunca o utilize. Hoje não ha mais razão para isso.
[/quote]
Acho que você está confundindo integração via banco com “modelar todos os sistemas da empresa em um único banco”.
Integração via banco é um padrão bastante comum e continua sendo a solução ideal quando os dados precisam estar sincronizados em tempo real.[/quote]
Então, sabe porque eu coloquei um “double” facepalm ao invés de um “single”? Pra ficar de crédito. Você acabou de gastar esse crédito :roll:
EDIT: Tá bom, deixa eu ser menos cruel: integração via banco deve ser sua última opção, não a primeira. Tá bom assim?
A frase correta seria :
“Integração via banco, é o que todo mundo, sem noção, faz.”
Esse é o pior tipo de integração de todos os tempos. Nunca, nunca o utilize. Hoje não ha mais razão para isso.
[/quote]
Acho que você está confundindo integração via banco com “modelar todos os sistemas da empresa em um único banco”.
[/quote]
Não. É bom que modele no mesmo mesmo banco, ou via virar uma zona.
Integração via banco de dados é uma aplicação ler e a outra escrever e vice-versa. Ou coisas mais esdruxulas como o trigger do bano de dados chamar um webservice. …
Não. Banco de dados é isso mesmo “repositorio de dados” , dados, não lógicas.
Esse mecanismo é coisa dos anos 80…
[quote]
Integração via banco é um padrão bastante comum e continua sendo a solução ideal quando os dados precisam estar sincronizados em tempo real.[/quote]
O fato de ser comum não a torna boa. E para cosias novas não deve ser usada. O Saudate falou que seria a ultima. Seria condescendência. Na minha concepção nem sequer é um candidato.
Em legados (q são feitos nos anos 80 , lol ) é a única opção. Mas isso é porque os arquitetos da época não sabiam melhor, e a emprea nas investiu numa arqutetura moderna nestes anos todos.
E então gambiarra por gambiarra… mas para sistemas novos é completamente inaceitável. Se houve uma licença para desenvolver, seria caso de cassa-la. :lol: :lol:
A frase correta seria :
“Integração via banco, é o que todo mundo, sem noção, faz.”
Esse é o pior tipo de integração de todos os tempos. Nunca, nunca o utilize. Hoje não ha mais razão para isso.
[/quote]
Acho que você está confundindo integração via banco com “modelar todos os sistemas da empresa em um único banco”.
Integração via banco é um padrão bastante comum e continua sendo a solução ideal quando os dados precisam estar sincronizados em tempo real.[/quote]
Então, sabe porque eu coloquei um “double” facepalm ao invés de um “single”? Pra ficar de crédito. Você acabou de gastar esse crédito :roll:
EDIT: Tá bom, deixa eu ser menos cruel: integração via banco deve ser sua última opção, não a primeira. Tá bom assim?[/quote]
Sem problemas, é apenas sua opinião. 
Sergiotaborda,
Digamos que eu tenho um sistema que precisa periodicamente escrever numa tabela, e outro sistema precisa somente ler as informações dessa mesma tabela.
Neste caso eles não podem acessar o banco diretamente e o correto, na sua opinião, é usar um web service?
[quote=msato]Sergiotaborda,
Digamos que eu tenho um sistema que precisa periodicamente escrever numa tabela, e outro sistema precisa somente ler as informações dessa mesma tabela.
Neste caso eles não podem acessar o banco diretamente e o correto, na sua opinião, é usar um web service?[/quote]
Na verdade, esse tipo de problema não requer, necessariamente, um web service. Mas o problema dos bancos de dados comuns entre app’s é bem sério: locks de dados, “afogamento” da rede, pouca flexibilidade para mudanças, alto acoplamento, etc.
Ou seja… é uma opção que deve ser evitada sempre.
EDIT: Suas opções são aquilo que nós chamamos, em SOA, de serviços: EJB’s, JMS, web services (sejam eles REST ou WS-*), etc - sim, em detrimento a coisas como escrita em bancos de dados e/ou filesystem.
[]'s
[quote=Alexandre Saudate]
Na verdade, esse tipo de problema não requer, necessariamente, um web service.[/quote]
Ah ta, não diga.
locks - se não existem atualizações concorrentes não há necessidade de locks.
afogamento da rede - não entendi, poderia explicar?
pouca flexibilidade para mudanças - não é diferente com o webservice, se ele muda o cliente precisa ser alterado.
alto acoplamento - vc trocou acoplamento do sistema com o banco, por acoplamento entre o sistema e o webservice. Além de ter aumentado a complexidade da solução sem nenhum benefício aparente.
Aguardo seus esclarecimentos pra decidir se webservice é de fato uma opção neste caso
[quote=msato][quote=Alexandre Saudate]
Na verdade, esse tipo de problema não requer, necessariamente, um web service.[/quote]
Ah ta, não diga.
locks - se não existem atualizações concorrentes não há necessidade de locks.
afogamento da rede - não entendi, poderia explicar?
pouca flexibilidade para mudanças - não é diferente com o webservice, se ele muda o cliente precisa ser alterado.
alto acoplamento - vc trocou acoplamento do sistema com o banco, por acoplamento entre o sistema e o webservice. Além de ter aumentado a complexidade da solução sem nenhum benefício aparente.
Aguardo seus esclarecimentos pra decidir se webservice é de fato uma opção neste caso[/quote]
locks - existem desde que haja uma única operação de escrita existente, seja concorrente ou não.
afogamento da rede - concentração de várias requisições numa única interface de rede (a do SGBD)
pouca flexibilidade - um web service não necessariamente quebra um cliente em caso de alterações, desde que estas alterações não sejam sobre campos existentes, i.e., se você acrescentar um campo, os clientes já existentes permanecem operantes sem problemas. Inclusive, dependendo da mudança, você pode inclusive mudar os tipos de dados sem problemas. Este último caso não é verdadeiro em se tratando de tipos de dados em SGBD’s.
alto acoplamento - se você quiser trocar o banco de dados de um dos sistemas, o outro está preso… moral da história, você tem grandes chances de não conseguir, nunca, promover seu sistema para trabalhar com volumes maiores do que os estimados inicialmente.
bônus vendor lock-in - web services não estão presos a nenhum vendor em particular. SGBD’s, sim .
[]'s
P.S: Se você viu meu “EDIT” no post anterior, viu que as opções não são necessariamente web services, mas sim, serviços - JMS, EJB, web services WS-* ou REST, etc.
[quote=Alexandre Saudate]
locks - existem desde que haja uma única operação de escrita existente, seja concorrente ou não.
afogamento da rede - concentração de várias requisições numa única interface de rede (a do SGBD)
pouca flexibilidade - um web service não necessariamente quebra um cliente em caso de alterações, desde que estas alterações não sejam sobre campos existentes, i.e., se você acrescentar um campo, os clientes já existentes permanecem operantes sem problemas. Inclusive, dependendo da mudança, você pode inclusive mudar os tipos de dados sem problemas. Este último caso não é verdadeiro em se tratando de tipos de dados em SGBD’s.
alto acoplamento - se você quiser trocar o banco de dados de um dos sistemas, o outro está preso… moral da história, você tem grandes chances de não conseguir, nunca, promover seu sistema para trabalhar com volumes maiores do que os estimados inicialmente.[/quote]
locks - se não ha potencial de abuso qual o problema então?
afogamento de rede - não há vários conexões visto que apenas dois sistemas, no máximo, conectam com o banco em um dado momento.
flexibilidade - como o novo campo aparece no sistema cliente se ele não for alterado?
acoplamento - não estamos falando de grande volume de dados, e sim de sincronizar os dados entre dois sistemas, de preferência no menor tempo possível. Mas por curiosidade, quantas vezes precisou trocar de banco?
Onde está aquele link do facepalm duplo?
Tem razão. Já está merecendo facepalm TRIPLO pelo “nível” das afirmações.
Quando você tem dois sistemas, isso não significa que você tem duas conexões para o mesmo banco. Significa que você tem PELO MENOS duas conexões (e isso pode tender a N de acordo com quantas conexões as aplicações estabelecerem ou quantas o SGBD suportar - o que vier primeiro). Corolário: quando você tem sistemas de alta performance, você precisa de várias conexões - logo, esse número tende a ser rapidamente esgotado. Não enxergar isso é ser ou muito ingênuo ou não ter experiência. Ou as duas coisas.
Quanto à troca de banco, já ouviu falar de NoSQL? Big Data? Acredite, não é tão raro quanto você quer acreditar.
E, pra encerrar minha participação nesse tópico, só digo o seguinte: largue a mão de ser ingênuo. Se alguém (bem intencionado) estiver lendo este tópico, com curiosidade sincera, saiba que a última coisa que você deve fazer em TI, SEMPRE, é projetar o sistema para suportar a demanda que você tem hoje, sem se preocupar com as consequências amanhã. Se tiver que projetar uma integração entre sistemas, saiba o seguinte: um sistema sempre cresce mais que o outro. Para suportar essas diferenças, é fundamental conhecer conceitos como escalabilidade horizontal e vertical, particionamento de bancos de dados, clusters, e outras coisas que se tornam mais ou menos corriqueiras conforme um sistema envelhece (em termos de idade, mesmo).
[quote=Alexandre Saudate]Tem razão. Já está merecendo facepalm TRIPLO pelo “nível” das afirmações.
Quando você tem dois sistemas, isso não significa que você tem duas conexões para o mesmo banco. Significa que você tem PELO MENOS duas conexões (e isso pode tender a N de acordo com quantas conexões as aplicações estabelecerem ou quantas o SGBD suportar - o que vier primeiro). Corolário: quando você tem sistemas de alta performance, você precisa de várias conexões - logo, esse número tende a ser rapidamente esgotado. Não enxergar isso é ser ou muito ingênuo ou não ter experiência. Ou as duas coisas.
[/quote]
Se dois processos conseguem “afogar” seu banco de dados, você esta fazendo errado.
[quote=Alexandre Saudate]
E, pra encerrar minha participação nesse tópico, só digo o seguinte: largue a mão de ser ingênuo. Se alguém (bem intencionado) estiver lendo este tópico, com curiosidade sincera, saiba que a última coisa que você deve fazer em TI, SEMPRE, é projetar o sistema para suportar a demanda que você tem hoje, sem se preocupar com as consequências amanhã. Se tiver que projetar uma integração entre sistemas, saiba o seguinte: um sistema sempre cresce mais que o outro. Para suportar essas diferenças, é fundamental conhecer conceitos como escalabilidade horizontal e vertical, particionamento de bancos de dados, clusters, e outras coisas que se tornam mais ou menos corriqueiras conforme um sistema envelhece (em termos de idade, mesmo).[/quote]
Esse papo de projetar para o futuro é muito bonito e tudo, mas ainda não explicou de que maneira webservice resolve os “problemas sérios” que você levantou.
[quote=msato]Sergiotaborda,
Digamos que eu tenho um sistema que precisa periodicamente escrever numa tabela, e outro sistema precisa somente ler as informações dessa mesma tabela.
Neste caso eles não podem acessar o banco diretamente e o correto, na sua opinião, é usar um web service?[/quote]
Não. é muito provavelmente usar uma fila (JMS). Isso é o padrão Produtor-Consumidor que se resolve com filas. Mas para mais detalhes teriamos que saber exactamente o que é necessario.
[quote=sergiotaborda]
Não. é muito provavelmente usar uma fila (JMS). Isso é o padrão Produtor-Consumidor que se resolve com filas. Mas para mais detalhes teriamos que saber exactamente o que é necessario.[/quote]
Legal. Porque integração via banco nada mais é do que implementar produtor-consumidor usando o banco de dados como buffer.
[quote=sergiotaborda][quote=msato]Sergiotaborda,
Digamos que eu tenho um sistema que precisa periodicamente escrever numa tabela, e outro sistema precisa somente ler as informações dessa mesma tabela.
Neste caso eles não podem acessar o banco diretamente e o correto, na sua opinião, é usar um web service?[/quote]
Não. é muito provavelmente usar uma fila (JMS). Isso é o padrão Produtor-Consumidor que se resolve com filas. Mas para mais detalhes teriamos que saber exactamente o que é necessario.[/quote]
Quanto a questão de utilizar integração via banco, é a mesma questão de usar regra de negócio no banco, é estar acoplado a um fornecedor só, em casos de problemas de escalabilidade voce só possui a possiblidade de escalabilidade vertical e não horizontal.
É confortável delegar esse tipo de responsabilidade a terceiros, é confortável colocar toda a regra de forma estruturada sob um paradigma funcional em um banco e só criar interfaces pra ele, porém a história da área de TI vem nos provando que nem sempre o mais confortável é o melhor, existem detalhes que fazem os web services serem uma vantagem:
- Baixo acoplamento, poss trocar qualquer um dos sistmas mantendo a mesma interface de serviço.
- Segurança, não exponho acesso direto aos dados, podendo portanto porcessar estes antes de enviar eles.
- Reuso, um web service bem projetado pode ser fonte de integração para outros sistemas.
- Coesão, não é coeso delegar acesso ao repositório de dados de uam determinada aplicação a outra, isso porque o modelo de dados é fortemente acoplado a regra de negócio de uma determinada aplicaçao, então a outra precisa se adaptar a este modelo.
Basicamente o grande problema que temos é o fato de eu perder controle sobre o ponto de integração sendo portando um fator de baixa maleabilidade, oque pode vir a se tornar um grande problema, além de ser é claro uma má prática.
Quanto a questão da integração eu lhe recomendo fortemente implementar um Web service como servidor da aplicação desktop e tornar a loja virtual um cliente desse WS, dessa forma voce delega a responsabilidade ao sistema e mantém o e-commerce como sistema satélite.
[quote=cleciusjm]
Quanto a questão da integração eu lhe recomendo fortemente implementar um Web service como servidor da aplicação desktop e tornar a loja virtual um cliente desse WS, dessa forma voce delega a responsabilidade ao sistema e mantém o e-commerce como sistema satélite.[/quote]
É exatamente isso que vou fazer. Já estou procurando material sobre estes assuntos.
Obrigado a todos que me ajudaram.
[quote=cleciusjm]
Quanto a questão de utilizar integração via banco, é a mesma questão de usar regra de negócio no banco, é estar acoplado a um fornecedor só, em casos de problemas de escalabilidade voce só possui a possiblidade de escalabilidade vertical e não horizontal.
É confortável delegar esse tipo de responsabilidade a terceiros, é confortável colocar toda a regra de forma estruturada sob um paradigma funcional em um banco e só criar interfaces pra ele, porém a história da área de TI vem nos provando que nem sempre o mais confortável é o melhor, existem detalhes que fazem os web services serem uma vantagem:
- Baixo acoplamento, poss trocar qualquer um dos sistmas mantendo a mesma interface de serviço.
- Segurança, não exponho acesso direto aos dados, podendo portanto porcessar estes antes de enviar eles.
- Reuso, um web service bem projetado pode ser fonte de integração para outros sistemas.
- Coesão, não é coeso delegar acesso ao repositório de dados de uam determinada aplicação a outra, isso porque o modelo de dados é fortemente acoplado a regra de negócio de uma determinada aplicaçao, então a outra precisa se adaptar a este modelo.
Basicamente o grande problema que temos é o fato de eu perder controle sobre o ponto de integração sendo portando um fator de baixa maleabilidade, oque pode vir a se tornar um grande problema, além de ser é claro uma má prática.
Quanto a questão da integração eu lhe recomendo fortemente implementar um Web service como servidor da aplicação desktop e tornar a loja virtual um cliente desse WS, dessa forma voce delega a responsabilidade ao sistema e mantém o e-commerce como sistema satélite.[/quote]
Entendo que as pessoas estão ansiosas por usarem seu conhecimento de webservices em projetos reais, mas faça um favor a você mesmo e aprenda quando usar uma determinada técnica.
Criar webservice pra compartilhar dados entre parceiros ou clientes é na verdade uma boa idéia, mas ai você está fazendo o papel de integrador.
Se você controla ambos os sistemas você pode liga-los sem intermediários, neste caso não faz sentido usar webservices pra sincronização de dados entre processos.
[quote=msato][quote=cleciusjm]
Quanto a questão de utilizar integração via banco, é a mesma questão de usar regra de negócio no banco, é estar acoplado a um fornecedor só, em casos de problemas de escalabilidade voce só possui a possiblidade de escalabilidade vertical e não horizontal.
É confortável delegar esse tipo de responsabilidade a terceiros, é confortável colocar toda a regra de forma estruturada sob um paradigma funcional em um banco e só criar interfaces pra ele, porém a história da área de TI vem nos provando que nem sempre o mais confortável é o melhor, existem detalhes que fazem os web services serem uma vantagem:
- Baixo acoplamento, poss trocar qualquer um dos sistmas mantendo a mesma interface de serviço.
- Segurança, não exponho acesso direto aos dados, podendo portanto porcessar estes antes de enviar eles.
- Reuso, um web service bem projetado pode ser fonte de integração para outros sistemas.
- Coesão, não é coeso delegar acesso ao repositório de dados de uam determinada aplicação a outra, isso porque o modelo de dados é fortemente acoplado a regra de negócio de uma determinada aplicaçao, então a outra precisa se adaptar a este modelo.
Basicamente o grande problema que temos é o fato de eu perder controle sobre o ponto de integração sendo portando um fator de baixa maleabilidade, oque pode vir a se tornar um grande problema, além de ser é claro uma má prática.
Quanto a questão da integração eu lhe recomendo fortemente implementar um Web service como servidor da aplicação desktop e tornar a loja virtual um cliente desse WS, dessa forma voce delega a responsabilidade ao sistema e mantém o e-commerce como sistema satélite.[/quote]
Entendo que as pessoas estão ansiosas por usarem seu conhecimento de webservices em projetos reais, mas faça um favor a você mesmo e aprenda quando usar uma determinada técnica.
Criar webservice pra compartilhar dados entre parceiros ou clientes é na verdade uma boa idéia, mas ai você está fazendo o papel de integrador.
Se você controla ambos os sistemas você pode liga-los sem intermediários, neste caso não faz sentido usar webservices pra sincronização de dados entre processos.
[/quote]
Então segundo sua declaração SOA é besteira?
Me desculpe, mas compartilhar o repositório de dados é no minimo absurdo no tempos atuais. Já que tá dificil de entender vamos desenhar:
Imagine que o processo de execução de venda dentro do controle de estoque executa algum processamento que tange a alguma peculiaridade dele, como gravar em outras tabelas e atualizar alguns outros detalhes, dessa forma quando uma venda fosse executada pra que o processamento ocorresse de forma coesa o outro sistema voce teria que replicar a regra de negócio, sendo portando algo ilógico, visto que qualquer manutenção teria que ser executada nos dois sistemas, além do fato que esse intermediário na verdade só seria a conversão de um layer para uma tier de forma que ficasse fisicamente acessível para outros.
A propósito, falar que não faz sentido é facil, porém acho que o minimo que voce pode fazer é argumentar
[quote=cleciusjm]
Me desculpe, mas compartilhar o repositório de dados é no minimo absurdo no tempos atuais.[/quote]
Acho que já apresentei meus argumentos sobre porque penso que compartilhar recursos (seja uma fila ou banco de dados) é apropriado em certos casos.
[quote=cleciusjm]
A propósito, falar que não faz sentido é facil, porém acho que o minimo que voce pode fazer é argumentar[/quote]
Argumentum ad nauseam não é um argumento válido pra mim.
Ad nauseam é quando após refutados os argumentos são reutilizados, o que não é o caso aqui, a não ser que o guj esteja ocultando seus posts eu não vi nada que contrariasse pontualmente meus argumentos.