Integração de sistemas

Programação Arquitetura
#41

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.

#42

[quote=Marck]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.

[/quote]

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

[quote=Marck]
Minha dica seria para fugir de integração pelo banco de dados.[/quote]

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. :wink:

#43

Pergunta do autor do tópico:

[quote=djavali]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.
[/quote]

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:

#44

[quote=Marck]Pergunta do autor do tópico:

[quote=djavali]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.
[/quote]

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: [/quote]

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.

#45

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

#46

[quote=Marck]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.[/quote]

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.

[quote=Marck]
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.[/quote]

Pode ser. Mas neste caso é uma integração de dados, portanto não há nenhum lógica envolvida.

[quote=Marck]
E é isso que uma integração tem que ser mesmo: “um serviço anemico”.[/quote]

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.

#47

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.

#48

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.

[quote=msato]
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.[/quote]

Em outras palavras, você está dizendo que enviar dados de estoque para o meu e-commerce é irrelevante.

#49

[quote=Marck]
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.[/quote]

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.

[quote=Marck]
Em outras palavras, você está dizendo que enviar dados de estoque para o meu e-commerce é irrelevante.[/quote]

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.

#50