Arquivo Discussoes de Programacao e Tecnologia Oi!
Estou estudando sobre integração de sistemas para implementar em um trabalho da faculdade.
Imagine o seguinte ambiente com tecnologias diferentes:
Site e-commerce em um servidor na web qualquer.
Sistema local de estoque.
Como integrar esses dois caras? A fim de, uma venda dar baixa no sistema de estoque, e por ai vai…
Eu li sobre:
Web services
Spring integration
Apache Camel
REST
Afinal, alguém tem alguma idéia, ou já fez algo do tipo? Utilizou algum framework?
Obrigado.
depende de qual tecnologia vc tem nas pontas.
se seu servidor web roda C# e seu cliente é baseado em WPF, o natural seria utilizar WS* (SOAP);
por outro lado, se você tem uma aplicação Rails, Grails, VRaptor… no web server e swing ou jafafx no cliente, o mais natural seria optar por REST;
e entre esses 2 cenários existem outras dezenas de possibilidades. Qual é especificamente o seu caso?
Integração via banco, é o que todo mundo faz.
isso não é mais realidade a pelo menos 10 anos.
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.
Desculpem colegas, sem querer causar polêmica… mas todo chinelo velho encontra seu pé torto. Veja um caso que temos por aqui onde trabalho: dois sistemas rodando independentemente, mas no mesmo servidor e ambos com banco Oracle. Conseguimos integra-los sem colocar nenhum “terceiro” entre eles. Um caso desses dá pra resolver com um simples database link…
Cada caso é um caso…para fazer a integralção é preciso saber (dentre outras coisas):
etc…etc…etc…
Mil possibilidades… A mais evidente (que, com certeza, é o que os seus professores de faculdade esperam) é que você utilize web services. Nisso, entra tanto web services clássicos (SOAP/WS-*) quanto REST.
Agora, quanto às possibilidades, entram várias variáveis. Só acrescentando às que o Giulliano falou, ainda tem o tamanho dos arquivos e criticidade dos dados (neste último caso, uma integração com Camel sobre JMS, por exemplo, seria mais “resistente” do que uma baseada somente em web services).
Para dar uma sugestão mais próxima do que você precisa, seria mesmo bastante interessante que você fornecesse esses dados.
[]'s
Cada caso é um caso…para fazer a integralção é preciso saber (dentre outras coisas):
etc…etc…etc…
Mil possibilidades… A mais evidente (que, com certeza, é o que os seus professores de faculdade esperam) é que você utilize web services. Nisso, entra tanto web services clássicos (SOAP/WS-*) quanto REST.Agora, quanto às possibilidades, entram várias variáveis. Só acrescentando às que o Giulliano falou, ainda tem o tamanho dos arquivos e criticidade dos dados (neste último caso, uma integração com Camel sobre JMS, por exemplo, seria mais “resistente” do que uma baseada somente em web services).
Para dar uma sugestão mais próxima do que você precisa, seria mesmo bastante interessante que você fornecesse esses dados.
[]'s
Olá, senhores. Obrigado pelas respostas.
Na sincronização dos dados, funcionaria assim: é cadastrado um produto que tenha no estoque no e-commerce. Ai é feito uma venda deste produto.
Se for sincronização a cada hora ou diária, teria o risco de vender algo que já não tem mais no estoque, né? Acho que teria de ser “em tempo real”, tem como?
Ou na hora de fechar a conta, fazer a busca lá no estoque e se tiver fecha. O que acham?
Cada caso é um caso…para fazer a integralção é preciso saber (dentre outras coisas):
etc…etc…etc…
Mil possibilidades… A mais evidente (que, com certeza, é o que os seus professores de faculdade esperam) é que você utilize web services. Nisso, entra tanto web services clássicos (SOAP/WS-*) quanto REST.Agora, quanto às possibilidades, entram várias variáveis. Só acrescentando às que o Giulliano falou, ainda tem o tamanho dos arquivos e criticidade dos dados (neste último caso, uma integração com Camel sobre JMS, por exemplo, seria mais “resistente” do que uma baseada somente em web services).
Para dar uma sugestão mais próxima do que você precisa, seria mesmo bastante interessante que você fornecesse esses dados.
[]'s
Olá, senhores. Obrigado pelas respostas.
Na sincronização dos dados, funcionaria assim: é cadastrado um produto que tenha no estoque no e-commerce. Ai é feito uma venda deste produto.
Se for sincronização a cada hora ou diária, teria o risco de vender algo que já não tem mais no estoque, né? Acho que teria de ser “em tempo real”, tem como?
Ou na hora de fechar a conta, fazer a busca lá no estoque e se tiver fecha. O que acham?
Web services e orientação a serviços cairiam como uma luva no seu caso.
Porque?
[]'s
Também acho que o webservice é ideal…
Oi!Estou estudando sobre integração de sistemas para implementar em um trabalho da faculdade.
Imagine o seguinte ambiente com tecnologias diferentes:Site e-commerce em um servidor na web qualquer.
Sistema local de estoque.Como integrar esses dois caras? A fim de, uma venda dar baixa no sistema de estoque, e por ai vai…
Eu li sobre:
Web services
Spring integration
Apache Camel
RESTAfinal, alguém tem alguma idéia, ou já fez algo do tipo? Utilizou algum framework?
Obrigado.
Cara, você está no caminho certo, dê uma olhada em ESB também. Mas a primeira coisa a se fazer, antes de integrar sistemas, é entender os sistemas e suas limitações. Em casos de sistemas pré-existentes: Como eles são? Rodam em mainframes, console, desktop, web? É um serviço? Depois, a forma de saida gerada por um software, precisa de transformação? São de terceiros ou de vocês?
Agora, se estiverem em produção, pode-se já planejar a integração usando webservices(soap ou rest)… fácil consumir, praticamente qualquer linguagem consegue acessar, de praticamente qualquer plataforma.
Sobre integração via banco: já foi muito usado no passado, mas é um tiro no pé, praticamente só funciona com softwares da mesma softhouse e se alguém muda algo… nem precisa falar mais, né?
Cara, você está no caminho certo, dê uma olhada em ESB também. Mas a primeira coisa a se fazer, antes de integrar sistemas, é entender os sistemas e suas limitações. Em casos de sistemas pré-existentes: Como eles são? Rodam em mainframes, console, desktop, web? É um serviço? Depois, a forma de saida gerada por um software, precisa de transformação? São de terceiros ou de vocês?
Agora, se estiverem em produção, pode-se já planejar a integração usando webservices(soap ou rest)… fácil consumir, praticamente qualquer linguagem consegue acessar, de praticamente qualquer plataforma.
Sobre integração via banco: já foi muito usado no passado, mas é um tiro no pé, praticamente só funciona com softwares da mesma softhouse e se alguém muda algo… nem precisa falar mais, né?
Obrigado pela resposta. Os sistemas estão em produção, portanto posso planejar a integração sem stress. 
Vou seguir as dicas dada por vcs, que é, usar Webservice + SOA. Ai vem a questão do soap ou rest. Qual melhor neste caso? Ou é apenas questão de se adaptar a uma delas?
Diferença principal entre as duas é que em soap, o contrato é explícito: vc precisa montar um wsdl, e em rest fica implícito, podendo-se em alguns casos até ter vários formatos (xml, jason, etc), mas sem o stress de ter que montar um documento descritivo. Além disso, no primeiro vc teria que usar para a segurança usar a especificação ws-* security, enquanto na outra vc vai aproveitar o http… sinceramente gosto muito da idéia do rest, mas é legal conhecer a soap também… cada uma tem vantagens e desvantagens, e cada projeto, dependendo das características, pode exigir um em detrimento de outro… as vezes as próprias políticas da empresa já delimitam qual utilizar.
[]'s
Cara, você está no caminho certo, dê uma olhada em ESB também. Mas a primeira coisa a se fazer, antes de integrar sistemas, é entender os sistemas e suas limitações. Em casos de sistemas pré-existentes: Como eles são? Rodam em mainframes, console, desktop, web? É um serviço? Depois, a forma de saida gerada por um software, precisa de transformação? São de terceiros ou de vocês?
Agora, se estiverem em produção, pode-se já planejar a integração usando webservices(soap ou rest)… fácil consumir, praticamente qualquer linguagem consegue acessar, de praticamente qualquer plataforma.
Sobre integração via banco: já foi muito usado no passado, mas é um tiro no pé, praticamente só funciona com softwares da mesma softhouse e se alguém muda algo… nem precisa falar mais, né?
Obrigado pela resposta. Os sistemas estão em produção, portanto posso planejar a integração sem stress.
Vou seguir as dicas dada por vcs, que é, usar Webservice + SOA. Ai vem a questão do soap ou rest. Qual melhor neste caso? Ou é apenas questão de se adaptar a uma delas?
Costumo dizer para os meus alunos que a diferença entre REST e SOAP está no ponto de complexidade. Ao passo que SOAP é complicado tecnicamente falando (por possuir o WSDL, ter a questão das especificações WS-*, etc.), é fácil realizar a modelagem dos serviços usando SOAP, já que o formato RPC emula um que já estamos acostumados, que é a chamada de métodos dentro da nossa própria linguagem.
Já REST é simples, tecnicamente falando, porém é mais complexo de modelar. Existem várias técnicas em REST que são desconhecidas pela maior parte dos desenvolvedores desse tipo de serviço que são essenciais para um projeto de sucesso desse tipo.
Você também deve levar em consideração que existem capacidades presentes em SOAP que REST simplesmente não tem (ou não padroniza). Para citar alguns exemplos: orquestração utilizando ferramentas (ou seja, BPEL), estabelecimento de transações, serviços assíncronos, Single Sign-On, etc.
[]'s
Obrigado Alexandre Saudate e luizalbsilva pela ajuda. Tenho 4 meses pra desenvolver esses caras e integrá-los. Claro que não precisa ser um submarino, mais é interessante eu ter bastante coisa e, como tenho pouco tempo, acho que vou dar uma olhada mais a fundo em REST já que pelo o que vcs me disseram é mais simples.
web service pra integrar dois sistemas que você mesmo criou? :shock:
web service pra integrar dois sistemas que você mesmo criou? :shock:
Sistemas que vou criar. Os dois sistemas estarão em ambientes diferentes, um local e outro web, conforme 1º post. Que outra forma vc sugere?
web service pra integrar dois sistemas que você mesmo criou? :shock:
Sistemas que vou criar. Os dois sistemas estarão em ambientes diferentes, um local e outro web, conforme 1º post. Que outra forma vc sugere?
Se vc vai criar os dois sistemas pode compartilhar a mesma base e não há necessidade de webservices.
web service pra integrar dois sistemas que você mesmo criou? :shock:
Sistemas que vou criar. Os dois sistemas estarão em ambientes diferentes, um local e outro web, conforme 1º post. Que outra forma vc sugere?
Se vc vai criar os dois sistemas pode compartilhar a mesma base e não há necessidade de webservices.
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.
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.
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.
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.
Acho que você está confundindo integração via banco com “modelar todos os sistemas da empresa em um único banco”.
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…
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.
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.
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.
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?
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?
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?
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
Na verdade, esse tipo de problema não requer, necessariamente, um web service.
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
Na verdade, esse tipo de problema não requer, necessariamente, um web service.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
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.
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.
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).
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.
Se dois processos conseguem “afogar” seu banco de dados, você esta fazendo errado.
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).
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.
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?
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.
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.
Legal. Porque integração via banco nada mais é do que implementar produtor-consumidor usando o banco de dados como buffer.
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?
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.
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:
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.
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.
É exatamente isso que vou fazer. Já estou procurando material sobre estes assuntos.
Obrigado a todos que me ajudaram.
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.
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.
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.
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.
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
Me desculpe, mas compartilhar o repositório de dados é no minimo absurdo no tempos atuais.
Acho que já apresentei meus argumentos sobre porque penso que compartilhar recursos (seja uma fila ou banco de dados) é apropriado em certos casos.
A propósito, falar que não faz sentido é facil, porém acho que o minimo que voce pode fazer é argumentar
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.
Aqui na empresa, temos como produto uma Loja online, onde temos integração com a retaguarda, pois precisamos de informações de estoque, clientes e etc.
Tinhamos uma integração direta com o Banco de dados. 1 sqlserver de cada lado. A integração era feita por banco de dados, com procs, utilizando uma data para saber o que já foi enviado. Tinhamos vários problemas referentes a estoque e outros bem conhecidos, além de ter que usar linkedserver, o que particularmente não gosto muito.
Neste cenário, eu preciso de regras de negócio no site e no banco de dados.
Mudamos algumas coisas no banco e comecamos a utilizar WS para a integração. O resultado foi que não temos mais nenhum problema de integração, e ainda podemos utilizar as próprias classes de negocio e dados do próprio site dentro do WS.
Minha dica seria para fugir de integração pelo banco de dados.
Aqui na empresa, temos como produto uma Loja online, onde temos integração com a retaguarda, pois precisamos de informações de estoque, clientes e etc.
Tinhamos uma integração direta com o Banco de dados. 1 sqlserver de cada lado. A integração era feita por banco de dados, com procs, utilizando uma data para saber o que já foi enviado. Tinhamos vários problemas referentes a estoque e outros bem conhecidos, além de ter que usar linkedserver, o que particularmente não gosto muito.Neste cenário, eu preciso de regras de negócio no site e no banco de dados.
Mudamos algumas coisas no banco e comecamos a utilizar WS para a integração. O resultado foi que não temos mais nenhum problema de integração, e ainda podemos utilizar as próprias classes de negocio e dados do próprio site dentro do WS.
Acho que todos já devem estar cientes que não é uma boa idéia rodar regras de negócio no banco de dados. Dito isso, ninguém está falando de regras.
O autor do tópico está querendo saber como lidar com a possibilidade de dados defasados no sistema. Até onde sei, aqui você só tem duas escolhas, colocá-los no mesmo lugar (ideal em alguns casos) ou criar dois sistemas e usar um terceiro pra sincronizar os dados a uma frequência previamente programada (ideal em outros).
Minha dica seria para fugir de integração pelo banco de dados.
Curioso é que as pessoas que hoje dizem que web services é solução pra tudo são as mesmas, que há um tempo atrás, falavam o mesmo do banco de dados.
O fato é quem não pára pra entender qual o problema, vai achar que tudo é prego e que martelo é tudo o que precisa.
Pergunta do autor do tópico:
Oi!Estou estudando sobre integração de sistemas para implementar em um trabalho da faculdade.
Imagine o seguinte ambiente com tecnologias diferentes:Site e-commerce em um servidor na web qualquer.
Sistema local de estoque.Como integrar esses dois caras? A fim de, uma venda dar baixa no sistema de estoque, e por ai vai…
Eu li sobre:
Web services
Spring integration
Apache Camel
RESTAfinal, alguém tem alguma idéia, ou já fez algo do tipo? Utilizou algum framework?
Obrigado.
Se ler novamente minha resposta, verá que está totalmente condizente com a pergunta.
Sem analisar o cenário, acredito que integrar pelo banco, nunca, nunca, nunca é algo bom.
Banco é para guardar dados, só.
Mas se você insiste que é uma boa, vá em frente. :lol:
Pergunta do autor do tópico:Oi!Estou estudando sobre integração de sistemas para implementar em um trabalho da faculdade.
Imagine o seguinte ambiente com tecnologias diferentes:Site e-commerce em um servidor na web qualquer.
Sistema local de estoque.Como integrar esses dois caras? A fim de, uma venda dar baixa no sistema de estoque, e por ai vai…
Eu li sobre:
Web services
Spring integration
Apache Camel
RESTAfinal, alguém tem alguma idéia, ou já fez algo do tipo? Utilizou algum framework?
Obrigado.
Se ler novamente minha resposta, verá que está totalmente condizente com a pergunta.
Sem analisar o cenário, acredito que integrar pelo banco, nunca, nunca, nunca é algo bom.
Banco é para guardar dados, só.
Mas se você insiste que é uma boa, vá em frente. :lol:
Sim, você não deve usar banco para lógica de negócio, mas quem falou que toda integração é de processos?
Esse é o problema de reaproveitar soluções sem analisar o problema em questão. Há alguns casos em que os dados de duas aplicações precisam estar atualizados e não é viável criar um processo só pra isso, por isso você compartilha o mesmo lugar no banco. Me parece ser o caso de um controle de estoque.
Infelizmente alguns blogueiros perpetuaram o mito de que integração via banco nunca deve ser usado, mas no mundo real você precisa ser melhor que isso ou vai terminar com um monte de services anêmicos que não fazem outra coisa a não ser sincronizar dados de um lado pro outro.
Mas se você compartilha o mesmo lugar no banco não existe a necessidade de integração.
Digo integraçao no sentido de pegar um dado de um banco e enviar para outro banco que você nem sabe o que é: oracle, mysql, xml, arquivo texto.
Quanto a lógica, se você está enviando o cadastro de clientes ou um pedido de venda para outro sistema, este deve fazer ao menos alguma validação. Se voce faz a integração por banco, terá que reescrever estas validações. Se faz por WS, por exemplo, consegue reaproveitar os objectos que estão por trás do seu sistema.
E é isso que uma integração tem que ser mesmo: “um serviço anemico”.
Mas se você compartilha o mesmo lugar no banco não existe a necessidade de integração.
Digo integraçao no sentido de pegar um dado de um banco e enviar para outro banco que você nem sabe o que é: oracle, mysql, xml, arquivo texto.
Integração via banco é quando um ou mais aplicativos compartilham o mesmo dado. Fazer cópia dos dados e enviar para outro banco é chamado replicação.
Quanto a lógica, se você está enviando o cadastro de clientes ou um pedido de venda para outro sistema, este deve fazer ao menos alguma validação. Se voce faz a integração por banco, terá que reescrever estas validações. Se faz por WS, por exemplo, consegue reaproveitar os objectos que estão por trás do seu sistema.
Pode ser. Mas neste caso é uma integração de dados, portanto não há nenhum lógica envolvida.
E é isso que uma integração tem que ser mesmo: “um serviço anemico”.
Na verdade isso é um anti-pattern. Serviços deveriam modelar processo de negócio relevantes para a empresa e não ficar replicando dados soltos entre sistemas.
Bem vamos lá:
Seria bom qualquer um que tivesse em projeto de integração, desse uma lida no ivro do Gregor e Bob, assim conhecendo os patterns específicos ao problema de integração - http://eaipatterns.com
Quanto mais nós conhecemos, mais opções temos de fazer um bom trabalho.
Realmente como disseram, há inúmeras formas, diversas certas e erradas. O melhor caminho vai de encontro à necessidade, débito técnico, curvatura de aprendizagem, custo etc.
Com relação à discussão, o Banco de Dados relacional é a fotografia do instante do objeto. Ele deve armazenar o estado da representação e não lidar com troca de mensagens ou ter regras de negócio. Aprendemos isso tomando muita porrada na última década.
Poderíamos até tentar utilizar um Banco para troca de mensagens, mas seria algo como um Key Value (noSQL) como o Redis - http://redis.io. O banco relacional como disse acima serve a outro propósito.
Um outro aspecto que deve ser analisado é o tamanho do problema. Pelo que vi, são apenas 2 sistemas, sem característica de altíssima performance, protocolos específicos etc. Não precisamos de um ESB.
Seria bom você começar pelo básico, modelagem de domínio entre os dois sistemas e criar um modelo comum - ( modelo canônico), isso ajudará a não ter problemas de compatibilidade entre os objetos e ficar criando transformações. Feito isso, pode desenhar sua API Rest e enviar o mesmo objeto para ambos os lados.
Aqui não estou considerando se você está sob a mesma base ou não, pois um bom desenho de APIs desconhece o mecanismo de persistência. Hoje você pode fazê-la no Mysql hoje, amanhã poderia ser um MongoDB e isso é transparente ao sistema parceiro.
Sistemas tendem a evoluir de forma separada, talvez o e-commerce exiga mais throughput e os dados do estoque você pode os consultar através de um Grid via Rest, como Infinispan. O importante é que independente da tecnologia, você modelou sua API, URI e Modelo de representação e conseguirá evoluir sem quebrar os sistemas usuários, aliás essa deve ser uma preocupação de design quando falamos em integração.
Não concordo.
Integrado que dizer que os sistemas estão vendo “a mesma coisa”. Daí ou os dois sistemas estão vendo o mesmo banco de dados, ou essa integração pode ser via Replicação de dados, que no meu entendimento é o que estamos discutindo.
Este pode ser um banco enviando os dados para outro, que pelo meu entendimento é o que você sugere, ou utilizando um WS, que é o que estou sugerindo.
Na verdade isso é um anti-pattern. Serviços deveriam modelar processo de negócio relevantes para a empresa e não ficar replicando dados soltos entre sistemas.
Em outras palavras, você está dizendo que enviar dados de estoque para o meu e-commerce é irrelevante.
Não concordo.Integrado que dizer que os sistemas estão vendo “a mesma coisa”. Daí ou os dois sistemas estão vendo o mesmo banco de dados, ou essa integração pode ser via Replicação de dados, que no meu entendimento é o que estamos discutindo.
Este pode ser um banco enviando os dados para outro, que pelo meu entendimento é o que você sugere, ou utilizando um WS, que é o que estou sugerindo.
Se integração quer dizer que são a mesma coisa, não faz sentido dizer que estou sugerindo enviar “para outro”, porque logicamente não existe outro quando eles são o mesmo.
Em outras palavras, você está dizendo que enviar dados de estoque para o meu e-commerce é irrelevante.
O processo de envio e recebimento dessa informação é irrelevante do ponto de vista do negócio.
Tudo o que importa para o negócio neste caso é a informação sobre disponibilidade no estoque, e não como esse dado foi obtido.
